Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Apr 2014 16:15:54 -0600
From:      Chris Torek <torek@torek.net>
To:        freebsd-hackers@freebsd.org
Subject:   MAXPHYS in md(4)
Message-ID:  <201404212215.s3LMFstd045652@elf.torek.net>

next in thread | raw e-mail | index | archive | help
In svn commit: r264504 - head/sys/geom/uzip we have:

  Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause
  problems in our providers, such as a KASSERT in md(4). ...

That would be this one:

	KASSERT(bp->bio_length <= MAXPHYS, ("bio_length %jd",
	    (uintmax_t)bp->bio_length));
	if ((bp->bio_flags & BIO_UNMAPPED) == 0) {
		pb = NULL;
		aiov.iov_base = bp->bio_data;
	} else {
		pb = getpbuf(&md_vnode_pbuf_freecnt);
		...

As it happens, the KASSERT is really only required for the
pb != NULL case, which uses one of the reserved getpbuf() buffers
that only map MAXPHYS bytes at a time.  If bp->bio_flags says that
the bio is mapped, we just use the existing KVA, and VOP_READ() and
VOP_WRITE() must already break up arbitrarily large transfers.

So, it seems like the md(4) KASSERT can be moved into the "else".
Is this a good idea?  (It might not help r264504 much since it
looks like r264504 wants to handle short-read results anyway, but
it seems overly restrictive to require <= MAXPHYS for the mapped
cases.)

Chris



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404212215.s3LMFstd045652>