Subject: Re: uvm_km_alloc/free from interrupt in netbsd-3
To: Manuel Bouyer <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 07/28/2006 11:55:27
Content-Type: text/plain; charset=us-ascii
On Fri, Jul 28, 2006 at 01:03:59PM +0200, Manuel Bouyer wrote:
> 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=
Also, you might want to chat w/ Jordan Rhody (jordanr at wasabisystems dot=
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=
> 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);
> I translated this in netbsd-3 to:
> 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_data =3D (void *)
> (((u_long)tr->tr_copy_data + 511UL) & ~511UL);
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----