MAXPHYS in md(4)
John-Mark Gurney
jmg at funkthat.com
Mon Apr 21 22:22:12 UTC 2014
Chris Torek wrote this message on Mon, Apr 21, 2014 at 16:15 -0600:
> 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.)
This really should be moved up into the generic GEOM layer so geom
module ever sees IO that is larger than MAXPHYS...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the freebsd-hackers
mailing list