Date: Tue, 22 Apr 2014 01:18:30 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Chris Torek <torek@torek.net> Cc: freebsd-hackers@freebsd.org Subject: Re: MAXPHYS in md(4) Message-ID: <20140421221830.GV4016@kib.kiev.ua> In-Reply-To: <201404212215.s3LMFstd045652@elf.torek.net> References: <201404212215.s3LMFstd045652@elf.torek.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--pnwJnpr18esoRWH7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Apr 21, 2014 at 04:15:54PM -0600, Chris Torek wrote:
> In svn commit: r264504 - head/sys/geom/uzip we have:
>=20
> 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). ...
>=20
> That would be this one:
>=20
> KASSERT(bp->bio_length <=3D MAXPHYS, ("bio_length %jd",
> (uintmax_t)bp->bio_length));
> if ((bp->bio_flags & BIO_UNMAPPED) =3D=3D 0) {
> pb =3D NULL;
> aiov.iov_base =3D bp->bio_data;
> } else {
> pb =3D getpbuf(&md_vnode_pbuf_freecnt);
> ...
>=20
> As it happens, the KASSERT is really only required for the
> pb !=3D 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.
>=20
> 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 <=3D MAXPHYS for the mapped
> cases.)
See r259198. In fact, I considered reverting this after the r264504.
--pnwJnpr18esoRWH7
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQIcBAEBAgAGBQJTVZk1AAoJEJDCuSvBvK1BHKkP/1c8M1w4eLAWqhJXEbcku2Ka
+IVGS+sCWUhoGthN1BMT3lFW2jyybK4ZetivvWSM+7G0UaqrxXV617mbTg9jjFGc
0tw2WObk1+psVZJqETenZFn3znvYf5h64Zu9l31lUQkmzHxQpNB1Toe3L2t3+wjX
U8ijIPZQsT4ZozgYTqjSn3eAKj8mbAK5wVwLozkrDWtkSUlrmPXQ99NzYusgHRsY
w+euTj4mxsu7pUI49YAUiafHIueZFaC0jFiflX+2j4OuB5XZ+Yv87AWSklMRZjBz
Pv6hUlTTZ6cZ9cltVP2lV1oMYQG0b3ZtowqDjY9qTvgvvt31uEvGqXsuAe5S2EIK
7AgVQuwrz0yTunn6U3lGZQyRWHFi2udnyNV2RD68jZM0zclNa8QBoeOoh1wUoyRi
xqOEyL5CinfmqXc1mLmUdXmlbyNdpKqN6zoEozDMMpqPS1DizpVjXLNf9zUF0aS7
+21VwmDaI3binXujmSisMlxhqswKLigs5aH8n/cHa6p3Mj63hsbrmqGAtPjRO8/U
GSAmZ/Z92vlmXaFJsCrGE5thICh6S0w2jIBvUjtUtTDSCskcI/E4zMlvX2rGmnR3
pXZxm+76F6/+zCb75woScGbFRyu2vUlhP9o3rnOghwTidKT5pOsFQqceDWTSTSlJ
Tq24TRutB5EaEEeE/87m
=bvsV
-----END PGP SIGNATURE-----
--pnwJnpr18esoRWH7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140421221830.GV4016>