Because of the way that ptrace() now calls procfs routines to read/write

the process's memory, it was possible for the procfs_domem() call to
return a residual leftover, but with no errno.  Since this is no good for
ptrace which ignored the the residual, remap a leftover amount into an
errno rather than fooling the caller into thinking it was successful when
in fact it was not.

Submitted by: bde (a very long time ago :-)
This commit is contained in:
Peter Wemm 1996-03-30 15:02:58 +00:00
parent 6386a7e079
commit 2eb80d36fe
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=14925

View File

@ -28,7 +28,7 @@
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $Id: sys_process.c,v 1.20 1996/01/19 03:58:04 dyson Exp $
* $Id: sys_process.c,v 1.21 1996/01/24 18:29:00 peter Exp $
*/
#include <sys/param.h>
@ -396,7 +396,21 @@ ptrace(curp, uap, retval)
uio.uio_segflg = UIO_SYSSPACE; /* ie: the uap */
uio.uio_rw = write ? UIO_WRITE : UIO_READ;
uio.uio_procp = p;
return(procfs_domem(curp, p, NULL, &uio));
error = procfs_domem(curp, p, NULL, &uio);
if (uio.uio_resid != 0) {
/*
* XXX procfs_domem() doesn't currently return ENOSPC,
* so I think write() can bogusly return 0.
* XXX what happens for short writes? We don't want
* to write partial data.
* XXX procfs_domem() returns EPERM for other invalid
* addresses. Convert this to EINVAL. Does this
* clobber returns of EPERM for other reasons?
*/
if (error == 0 || error == ENOSPC || error == EPERM)
error = EINVAL; /* EOF */
}
return (error);
case PT_READ_U:
if ((u_int)uap->addr > (UPAGES * NBPG - sizeof(int))) {