sleeping in irq context in match()

sleeping in irq context in match()

[Arjan van de Ven]

Hi,

the backtrace below is popping up in kerneloops.org stats pretty
quickly; I don't know if it's been discussed here before but
just wanted to mention it in case it hasn't been..
(it's rank 13 right now, out of nowhere)

http://www.kerneloops.org/searchweek.php?search=match  for more info


__might_sleep
mutex_lock_nested
rtnl_lock
*match
ipt_do_table
ipt_local_in_hook
nf_iterate
nf_hook_slow
ip_local_deliver
ip_rcv_finish
ip_rcv
netif_receive_skb
tg3_poll


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: sleeping in irq context in match()

[Ben Hutchings]

Arjan van de Ven wrote:
> Hi,
> 
> the backtrace below is popping up in kerneloops.org stats pretty
> quickly; I don't know if it's been discussed here before but
> just wanted to mention it in case it hasn't been..
> (it's rank 13 right now, out of nowhere)
> 
> http://www.kerneloops.org/searchweek.php?search=match  for more info
> 
> 
> __might_sleep
> mutex_lock_nested
> rtnl_lock
> *match
[...]

Looking at the "more info", I see that that function is in xt_ipisforif,
which is an out-of-tree module.  The author appears to be
Alex Davis <alex14641@yahoo.com>.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.

Re: sleeping in irq context in match()

[Alex Davis]

--- On Wed, 7/23/08, Ben Hutchings <bhutchings@solarflare.com> wrote:

> From: Ben Hutchings <bhutchings@solarflare.com>
> Subject: Re: sleeping in irq context in match()
> To: "Arjan van de Ven" <arjan@infradead.org>
> Cc: "Alex Davis" <alex14641@yahoo.com>, netdev@vger.kernel.org
> Date: Wednesday, July 23, 2008, 3:14 PM
> Arjan van de Ven wrote:
> > Hi,
> > 
> > the backtrace below is popping up in kerneloops.org
> stats pretty
> > quickly; I don't know if it's been discussed
> here before but
> > just wanted to mention it in case it hasn't been..
> > (it's rank 13 right now, out of nowhere)
> > 
> > http://www.kerneloops.org/searchweek.php?search=match 
> for more info
> > 
> > 
> > __might_sleep
> > mutex_lock_nested
> > rtnl_lock
> > *match
> [...]
> 
> Looking at the "more info", I see that that
> function is in xt_ipisforif,
> which is an out-of-tree module.  The author appears to be
> Alex Davis <alex14641@yahoo.com>.
> 
> Ben.
> 
> -- 
> Ben Hutchings, Senior Software Engineer, Solarflare
> Communications
> Not speaking for my employer; that's the marketing
> department's job.
My goodness!! Someone is actually using it?? I sumbitted the code back in June '06, but it was rejected by Patrick McHardy. I think his words 
were something along the lines of 'I don't want to create a new match 
just for this'. Anyway, I'm still using it on a 2.6.18 kernel. Since
people are using it, I'll consider fixing it to work on later kernels.

Is this something the netfilter team would have an interest in?

I code, therefore I am


      

Possible coding error in ./drivers/net/wan/dlci.c

[Alex Davis]

In the 2.6.25.10 version of this file, function dlci_del, the function __dev_get_by_name is called with neither the RTNL semaphore or dev_base_lock being held. According to the documentation for __dev_get_by_name, one of the aforementioned locks must be held. Am I missing something?


I code, therefore I am