Memory allocation inside target handler

Hi there,

I'm currently debugging a memory allocation issue in
ipt_ACCOUNT running on 
2.6.21.7. The module allocates memory using
get_zeroed_page(GFP_ATOMIC) 
inside the target handler code (interrupt context).

This worked so far without problems. After upgrading from
2.4.32
to 2.6.21.7, I get a kernel oops after 15 to 30 minutes.
Attached you'll
find a picture of the oops (sorry, no serial console
available).

You can see the kernel is allocating memory when an
interrupt is fired.
It then enters netfilter and ends up in ipt_ACCOUNT
which also tries to allocate memory -> Boom.

My question is now:
- Is it ok to use get_zeroed_page(GFP_ATOMIC) in interrupt
context?
- Do I need some special locking before I can allocate
memory inside
  the target handler? Is f.e. kmalloc protected by some
special locking?

In addition ipt_ACCOUNT allocates some memory during the
module init code
with kmalloc(GFP_KERNEL), but I guess this is not an issue
here.

Thanks in advance for any help,
Thomas Jarosch

... and now the picture of the oops 

On Friday, 17. August 2007, Thomas Jarosch wrote:
> ... and now the picture of the oops 

Looks like JPEGs get filtered, so here's a link to the
oops:

http://img529.imageshack.us/img529/6681/kerneloopsey1.j
pg

Thomas

On Aug 17 2007 17:17, Thomas Jarosch wrote:
>
>My question is now:
>- Is it ok to use get_zeroed_page(GFP_ATOMIC) in
interrupt context?

I suppose so. There is code that checks for __GFP_WAIT.
(GFP_ATOMIC has __GFP_WAIT _cleared_)

>- Do I need some special locking before I can allocate
memory inside
>  the target handler? Is f.e. kmalloc protected by some
special locking?

Only locking for your own structures, if needed.
kmalloc alone does not. (You can write a memory leak without
any locks, so to
speak.)


	Jan
-- 

Hello Carl-Daniel,

On Friday, 17. August 2007, you wrote:
> > Looks like JPEGs get filtered, so here's a link to
the oops:
> >
> > http://img529.imageshack.us/img529/6681/kerneloopsey1.j
pg
>
> You might want to retry with an untainted kernel.

Good point, unfortunately it didn't make a difference.

Thanks,
Thomas

On Friday, 17. August 2007, Jan Engelhardt wrote:
> On Aug 17 2007 17:17, Thomas Jarosch wrote:
> >My question is now:
> >- Is it ok to use get_zeroed_page(GFP_ATOMIC) in
interrupt context?
>
> I suppose so. There is code that checks for
__GFP_WAIT.
> (GFP_ATOMIC has __GFP_WAIT _cleared_)
>
> >- Do I need some special locking before I can
allocate memory inside
> >  the target handler? Is f.e. kmalloc protected by
some special locking?
>
> Only locking for your own structures, if needed.
> kmalloc alone does not. (You can write a memory leak
without any locks, so
> to speak.)

ipt_ACCOUNT spinlocks the internal data structures, so that
should be ok.

I've changed the code to allocate and free memory for every
packet instead of 
every read from userpace, now the machine survives only 10
seconds. To me it 
looks like a missing locking in the kernel memory handler,
I'll try to get a backtrace via serial console.

Thomas