MAXPHYS in md(4)

Konstantin Belousov kostikbel at gmail.com
Mon Apr 21 22:18:35 UTC 2014


On Mon, Apr 21, 2014 at 04:15:54PM -0600, Chris Torek wrote:
> 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.)

See r259198.  In fact, I considered reverting this after the r264504.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20140422/ae637b81/attachment.sig>


More information about the freebsd-hackers mailing list