Re: GFP_KERNEL i checkentry

[Tobias DiPasquale <codeslinger@gmail.com>]

On 6/17/05, Joakim Axelsson <gozem@gozem.se> wrote:
> I have during my developing of some new modules be running into some
> problem which I need help with. Since im running my routers on old
> 2.4.23-kernel i have been developing for it. However i will most probably
> convert to 2.6 soon.
> 
> Anyway, in "ipt_checkentry" that is executed everytime a new rule is added
> which uses the module (or acutally whenever ANY rule is changed, added or
> removed) it would seem that the kernel (atleast 2.4) considers this to be
> inside an interupt-handler. I guess this is the softinterupt syscall that
> get/setsockopt() refers to. However, i was using GFP_KERNEL to allocate
> memory here. This seems to be wrong and needs to be GTP_ATOMIC. In _very_
> rare occations this will trigger the BUG() on line 1130 in mm/slab.c (in
> kernel 2.4.23) whenever the general fiting slabs needs to be grown.
> 
> Now to the problem. As far as i can see, vanilla 2.6.11.9 has this problem
> in ipt_SAME. Possbile ipt_connlimit and ipt_recent. However i don't think
> proc fs punctions need to be GFP_ATOMIC. Possbily this problem exists in other
> modules in patch-o-magic. I havn't had a time to check it. However, among
> those patches i use from an about 1 year old pom in my 2.4.23 routing kernel
> there are several occations of this.
> 
> Again, this is a very very rare bug to trigger. I had to load ALOT of
> instances using iptables-restore of my module before the bug was triggered.
> 
> Question is: Should it really be GFP_ATOMIC in all of the modules hook
> functions?

No, this is definitely in process context. The bug you are
experiencing is not due to being in interrupt context when you think
you're in process: if that were the case, the bug would manifest
itself a lot more often than you claim. This sounds to me like some
kind of locking problem; I would check the locks used in my module and
see if they conflict with the locks used elsewhere up the call stack.
Failing that, look for a bug in the locking of the calling functions.

-- 
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d