BSD 4.2 minphys() < 64K

[hosking at convexs.UUCP]

We've been running with a NOP version of minphys on Convex C-1s
for several years with very few problems.  I won't guarantee anything about
VAX hardware, but there doesn't seem to be any reason why the software
can't hack the large transfer sizes, except for the possible memory deadlocks
if you get REALLY abusive.  We made a few changes to reduce the chance of
such deadlocks when doing huge transfers.  (We run a modified 4.2 BSD based
version of UNIX.)

In sys_generic.c, rwuio() was changed:
	for (i = 0; i < uio->uio_iovcnt; i++) {

		/*
		 * This check is really two checks in one.  It catches negative
		 * sizes AND requests to transfer too large a chunk at once,
		 * such as "dd if=/dev/rda0c of=/dev/rmt20 bs=100000000" on
		 * a system with only 16 MB of physical memory.  Lack of such
		 * checks can result in hangs or panics in vslock(), and other
		 * nasties.  This won't catch some pathological cases of
		 * vslock() hangs, but it should prevent the vast majority of
		 * potential hangs/panics in vslock() without being too
		 * unfriendly.  DRH 7/23/86.
		 */

+		if ((unsigned) iov->iov_len > (unsigned) (ctob(maxmem) / 2)) {
+			u.u_error = EINVAL;
+			return;
+		}
		uio->uio_resid += iov->iov_len;
		if (uio->uio_resid < 0) {
			u.u_error = EINVAL;
			return;
		}
		iov++;
	}

In vm_mem.c, vslock() was changed:

    /*
     * We should "never" fail the test that follows, but we do it anyway to
     * prevent hangs when brain damaged callers make unreasonable
     * requests on system memory.  This won't prevent *all* deadlocks,
     * but it should catch all but the pathological cases.  It's better
     * to get info on what's broken (and be able to sync the disks) than
     * to just hang forever, and it's a cheap check, so why not ?  DRH 7/23/86
     */
    if ((unsigned) count > (unsigned) (ctob(maxmem) / 2))
	panic("vslock: trying to wire too much memory");