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