Trying to understand alloc_skb()

Trying to understand alloc_skb()

[Daniel Ann]

Hiya folks,

I'm wondering if anyone could help me out with problem I have in alloc_skb().

My problem is that, kernel dies with "alloc_skb called nonatomically
from interrupt c00ba718" message. After browsing mailing list, I think
its to do with not providing it with enough locks prior.

Question is, what kind of lock should I be providing ?

Since I have no clue as to which lock does what, I really need some
good advise as to where to start looking.

Could someone tell me the inside story on this ?

-- 
Daniel

Re: Trying to understand alloc_skb()

[Daniel Ann]

In addition,

Im running 2.4.21 kernel.

Just then, I was looking at the 2.6.11 kernel source
(net/core/skbuff.c) and found out that large chunk of the alloc_skb()
has been thrown out.

Can this be removed from 2.4.21 also ? I might go and check out why
its been removed.

Still waiting for some good answer tho .. :)

Cheers,


On Apr 12, 2005 5:38 PM, Daniel Ann <ktdann@gmail.com> wrote:
> Hiya folks,
> 
> I'm wondering if anyone could help me out with problem I have in alloc_skb().
> 
> My problem is that, kernel dies with "alloc_skb called nonatomically
> from interrupt c00ba718" message. After browsing mailing list, I think
> its to do with not providing it with enough locks prior.
> 
> Question is, what kind of lock should I be providing ?
> 
> Since I have no clue as to which lock does what, I really need some
> good advise as to where to start looking.
> 
> Could someone tell me the inside story on this ?
> 
> --
> Daniel
> 


-- 
Daniel

Re: Trying to understand alloc_skb()

[John W. Linville]

On Tue, Apr 12, 2005 at 05:38:01PM +0900, Daniel Ann wrote:

> My problem is that, kernel dies with "alloc_skb called nonatomically
> from interrupt c00ba718" message. After browsing mailing list, I think
> its to do with not providing it with enough locks prior.

You may want to consider dev_alloc_skb...
-- 
John W. Linville
linville@tuxdriver.com

Re: Trying to understand alloc_skb()

[Daniel Ann]

On Apr 12, 2005 9:24 PM, John W. Linville <linville@tuxdriver.com> wrote:
> You may want to consider dev_alloc_skb...

Ahh that's right. I remember reading a little comment on top dev_alloc_skb().
Thank you so much. At least that inspired me :)

Thing is, I got this error during a call to notifier_call_chain. So..
I would have to go thru the functions who is responsible for issueing
alloc_skb directly. Gonna take a little while :P

Cheers,

-- 
Daniel

Re: Trying to understand alloc_skb()

[John W. Linville]

On Tue, Apr 12, 2005 at 10:05:14PM +0900, Daniel Ann wrote:
> On Apr 12, 2005 9:24 PM, John W. Linville <linville@tuxdriver.com> wrote:
> > You may want to consider dev_alloc_skb...
> 
> Ahh that's right. I remember reading a little comment on top dev_alloc_skb().
> Thank you so much. At least that inspired me :)
> 
> Thing is, I got this error during a call to notifier_call_chain. So..

My guess would be that your best bet is to move your call to
notifier_call_chain off to a workqueue.  notifier_call_chain (and/or
one or more of the functions it is calling) is likely written to
expect to be in process context.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: Trying to understand alloc_skb()

[Eugene Surovegin]

On Tue, Apr 12, 2005 at 05:38:01PM +0900, Daniel Ann wrote:
> My problem is that, kernel dies with "alloc_skb called nonatomically
> from interrupt c00ba718" message. After browsing mailing list, I think
> its to do with not providing it with enough locks prior.
> 
> Question is, what kind of lock should I be providing ?

You don't need any locks, just pass correct gfp_mask parameter to 
alloc_skb when it's called from IRQ context, e.g. GFP_ATOMIC.

--
Eugene

Re: Trying to understand alloc_skb()

[Daniel Ann]

On 4/12/05, John W. Linville <linville@tuxdriver.com> wrote:
> My guess would be that your best bet is to move your call to
> notifier_call_chain off to a workqueue.  notifier_call_chain (and/or
> one or more of the functions it is calling) is likely written to
> expect to be in process context.

I was thinking that this might have something to do with BH stuff that
I've left out from reading. (rather complicated :P)
Forgive me for trying to take an easy way, but moving things to
workqueue, do you mean putting it in bottom half? (Im sorta guessing
bottom half is like something you do after finishing high priority
tasks)

(I guess you had this coming) How do you move it to the workqueue?

--=20
Daniel

Re: Trying to understand alloc_skb()

[Daniel Ann]

On 4/13/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> You don't need any locks, just pass correct gfp_mask parameter to
> alloc_skb when it's called from IRQ context, e.g. GFP_ATOMIC.

Thing is, I'm not actually calling alloc_skb directly from my
function. I'm calling notifier_call_chain() and somehow inadvertently
it is getting called. If I was to give GFP_ATOMIC, then I'd have to
first find the code that is responsible.

Reading what John said earlier, rather than trying to find the code
that is calling alloc_skb, I should be moving the calls to my
fnuctions into process context.

So.. I'm gonna go ahead with John's suggestion.. but only problem now
is how do I move it to process context :P (May be more importantly,
how do I know that the code needs to be in process context or not?
which will prevent further headaches and possible coding a time bomb
:) )

--=20
Daniel

Re: Trying to understand alloc_skb()

[Eugene Surovegin]

On Wed, Apr 13, 2005 at 01:50:05PM +0900, Daniel Ann wrote:
> On 4/13/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> > You don't need any locks, just pass correct gfp_mask parameter to
> > alloc_skb when it's called from IRQ context, e.g. GFP_ATOMIC.
> 
> Thing is, I'm not actually calling alloc_skb directly from my
> function. I'm calling notifier_call_chain() and somehow inadvertently
> it is getting called. If I was to give GFP_ATOMIC, then I'd have to
> first find the code that is responsible.

Then do it. It should be trivial to unwind the stack and much simpler 
than moving this code to process context.

> Reading what John said earlier, rather than trying to find the code
> that is calling alloc_skb, I should be moving the calls to my
> fnuctions into process context.

I think it's a bad idea. You are trying to workaround a problem 
instead of fixing it. My experience shows that sooner or later it'll 
come back and hit you anyway :).

-- 
Eugene

Re: Trying to understand alloc_skb()

[Donald White]

Maybe reading LINUX DEVICE DRIVERS would help.  The third edition is 
just out.  While x86 centric, the book does explain the Linux driver 
model, the kernel API, workqueues and such.

Don

Re: Trying to understand alloc_skb()

[Daniel Ann]

On 4/13/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> Then do it. It should be trivial to unwind the stack and much simpler
> than moving this code to process context.

Actually, Im not too sure what is required to put something in kernel
in process context. Maybe its alot harder than I think it is...

> I think it's a bad idea. You are trying to workaround a problem
> instead of fixing it. My experience shows that sooner or later it'll
> come back and hit you anyway :).

I'm with you on this. It just that I didnt think putting my code in
process context would be regarded as workaround. Since kernel itself
ran fine, only after putting in my change it caused problem, I simply
thought that putting changes to code that was already there is more
severe than making further changes to what I've done. At least this
way, change is still within my domain.

But again, if putting my function in process context is that hard..
okay I better think otherwise :)

--=20
Daniel

Re: Trying to understand alloc_skb()

[Daniel Ann]

On 4/13/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> Then do it. It should be trivial to unwind the stack and much simpler
> than moving this code to process context.

You know what ?? You were right about it being trivial. Didnt take me
to too long to find the line and saw what was going on.
Initially I started reading on how to put the line in process context,
but soon I realised its not something you want to spend your afternoon
on :P (Currently I dont have too many afternoons for this)

Anyway, thanks for the pointer.

Actual problem came from rtnetlink.c file where it called
rtmsg_ifinfo(). This in turn, called alloc_skb with GFP_KERNEL, rather
an GFP_ATOMIC. I guess GFP_KERNEL is right, but what's the difference
?

--=20
Daniel