Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: iptables: Devel

Memory allocation inside target handler

 

 

iptables devel RSS feed   Index | Next | Previous | View Threaded


thomas.jarosch at intra2net

Aug 17, 2007, 8:17 AM

Post #1 of 7 (1526 views)
Permalink
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


thomas.jarosch at intra2net

Aug 17, 2007, 8:22 AM

Post #2 of 7 (1488 views)
Permalink
Re: Memory allocation inside target handler [In reply to]

... and now the picture of the oops ;-)


thomas.jarosch at intra2net

Aug 17, 2007, 8:25 AM

Post #3 of 7 (1470 views)
Permalink
Re: Memory allocation inside target handler [In reply to]

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.jpg

Thomas


jengelh at computergmbh

Aug 17, 2007, 8:42 AM

Post #4 of 7 (1467 views)
Permalink
Re: Memory allocation inside target handler [In reply to]

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
--


c-d.hailfinger.devel.2006 at gmx

Aug 17, 2007, 1:39 PM

Post #5 of 7 (1467 views)
Permalink
Re: Memory allocation inside target handler [In reply to]

Hi Thomas,

On 17.08.2007 17:25, Thomas Jarosch wrote:
> 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.jpg

You might want to retry with an untainted kernel.

Regards,
Carl-Daniel


thomas.jarosch at intra2net

Aug 20, 2007, 2:29 AM

Post #6 of 7 (1456 views)
Permalink
Re: Memory allocation inside target handler [In reply to]

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.jpg
>
> You might want to retry with an untainted kernel.

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

Thanks,
Thomas


thomas.jarosch at intra2net

Aug 20, 2007, 2:46 AM

Post #7 of 7 (1455 views)
Permalink
Re: Memory allocation inside target handler [In reply to]

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

iptables devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.