should networkdevice_ioctl() always be called from a thread context?

Hi,

while analyzing, writing, and reparing kern/34521, I
wondered:

- should interface_ioctl() always be called by a thread
context?

Background:

IPv6 neighbour/router/prefix discovery can trigger an
interface
address addition from the (soft) network interupt when an
ICMPv6
router advertizement comes in. THe ICMPv6 code eventally
calls
the driver's foo_ioctl(... SIOCADDMULTI ...) call to
register the
multicast address the interface needs to listen to for the
IPv6 
neigbbour discovery to work.

Now, the aue_ioctl() eventually calls usb code that is not
interupt
safe.

You may have noticed that I fixed this for netbsd-4 and
later by
activating a workqueue(9) [which is a kernel thread in
disguise].
However, I wonder whether foo_ioctl() should be able to
expect that
it's called from a thread context, that is, whether the
ICMPv6 code
(and other code that calls ..._ioctl() entry points) should
create
a work thread itself if necessary.

[Others have already mentioned that we're doing too much
stuff in
interupt context...]

What do you think?

Regards,
	-is

On Sep 25, 2006, at 4:35 AM, Ignatios Souvatzis wrote:

> Hi,
>
> while analyzing, writing, and reparing kern/34521, I
wondered:
>
> - should interface_ioctl() always be called by a thread
context?

Yes.

-- thorpej

On Mon, Sep 25, 2006 at 02:31:49PM -0700, Jason Thorpe
wrote:
> 
> On Sep 25, 2006, at 4:35 AM, Ignatios Souvatzis wrote:
> 
> >while analyzing, writing, and reparing kern/34521,
I wondered:
> >- should interface_ioctl() always be called by a
thread context?
> 
> Yes.

Sounds like a project for the 2nd half of my vacation.

	-is
-- 
seal your e-mail: http://www.gnupg.org/