Subject: Re: uvm_km_alloc/free from interrupt in netbsd-3
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 07/28/2006 11:55:27
--Y7xTucakfITjPcLV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jul 28, 2006 at 01:03:59PM +0200, Manuel Bouyer wrote:
> Hi,
> I'm trying to backport the twa driver to netbsd-3, and I'm running in
> issues with uvm_km_alloc/free.
I don't think this should be too hard. The driver started life on a 3.99.5=
=20
kernel.
Also, you might want to chat w/ Jordan Rhody (jordanr at wasabisystems dot=
=20
com) about the driver. He's its primary keeper.
> First, is it safe to use uvm_km_alloc()/free() on kmem_map from interrupt
> context in -current (I guess so because we have a UVM_KMF_NOWAIT flag) ?
It's questionable. If you aren't above splvm(), it's probably ok.
> Is it safe in netbsd-3, where we can't pass UVM_KMF_NOWAIT to uvm_km_allo=
c() ?
>=20
> Here is the code in current:
> s =3D splvm();
> tr->tr_data =3D (void *)uvm_km_alloc(kmem_map,=20
> tr->tr_length, 512, UVM_KMF_NOWAIT|UVM_KMF_WIRED);
> splx(s);
>=20
> I translated this in netbsd-3 to:
>=20
> tr->tr_copy_length =3D tr->tr_length + 511UL;
> s =3D splvm();
> tr->tr_copy_data =3D (void *)uvm_km_alloc(kmem_map,
> tr->tr_copy_length);
> splx(s);
> tr->tr_data =3D (void *)
> (((u_long)tr->tr_copy_data + 511UL) & ~511UL);
>=20
> but with this I get random panics apparently due to data corruption after
> doing some I/O to the twa. I suspect this is because of this alloc/free
> for unaligned requests, because I got panic only when working on the raw
> device (e.g. newfs, disklabel, etc ...). Once I get past this I can work
> on the mounted filesystem without troubles, but I think requests from
> a mounted filesystem are always aligned on 512 bytes.
Assuming that you mean that the data buffers are 512-byte aligned, yes.
Also, I don't see all of your changes, but you are freeing=20
tr->tr_copy_data, correct? Not tr->tr_data? And you're freeing the=20
increased length?
Take care,
Bill
--Y7xTucakfITjPcLV
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iD8DBQFEyl2fWz+3JHUci9cRAgPZAJ0c1USHlzaPNyLXJCCSMYJTEPItAQCgmBd2
hZ1iwCPAy1UvpGpv9GGE4Kg=
=j5Ld
-----END PGP SIGNATURE-----
--Y7xTucakfITjPcLV--