[quagga-dev 3871] Re: Kernel Panic in memory allocationforRFC2385patch

Simon Talbot simont at nse.co.uk
Tue Dec 6 23:22:42 GMT 2005


Hi All,

I have not had any feedback as to whether my fix for the kernel panic in
slab.c (by making the crypto routines interrupt safe) worked and/or
caused any problems in other areas. So far since implementing the patch
on a couple of our core routers, I have not seen a single kernel panic
and they seem to be operating normally with so fair activity levels.

I would be most grateful to the others of you who are testing if you
could sum up and let me have your feedback,

Thanks,

Simon 


Simon Talbot MEng, ACGI
(Chief Engineer)
Tel: 0845 6440972
Fax: 0845 6440971


-----Original Message-----
From: quagga-dev-bounces at lists.quagga.net
[mailto:quagga-dev-bounces at lists.quagga.net] On Behalf Of Simon Talbot
Sent: 08 November 2005 23:49
To: quagga-dev at lists.quagga.net
Cc: Sylvain Vittecoq; Andreas John; Christian Ehrhardt
Subject: [quagga-dev 3819] Re: Kernel Panic in memory
allocationforRFC2385patch

Attached to this post you will find my patch to make the kernel crypto
functions interrupt safe, and hopefully cure the Kernel Panic we have
been experiencing during memory allocation with the RFC2385 patch.

The diff is against kernel 2.4.32-pre3 (although should be very easy to
apply to other kernel versions) 

As anyone experiencing this problem knows only too well, it is very hard
to re-create in the lab, so my hope is that by opening this patch to a
wider audience for testing we might be able to ascertain whether it
helps, hinders or simply does nothing !

Please report findings back to the list,

Thanks,

Simon

Simon Talbot MEng, ACGI
(Chief Engineer)
The Voice over Broadband People
Tel: 0845 6440972
Fax: 0845 6440971

*** Voxige - The Voice over Broadband People http://www.voxige.com ***

The information contained in this e-mail and any attachments are private
and confidential and may be legally privileged.

It is intended for the named addressee(s) only. If you are not the
intended recipient(s), you must not read, copy or use the information
contained in any way. If you receive this email or any attachments in
error, please notify us immediately by e-mail and destroy any copy you
have of it.

We accept no responsibility for any loss or damages whatsoever arising
in any way from receipt or use of this e-mail or any attachments. This
e-mail is not intended to create legally binding commitments on our
behalf, nor do its comments reflect our corporate views or policies.


-----Original Message-----
From: quagga-dev-bounces at lists.quagga.net
[mailto:quagga-dev-bounces at lists.quagga.net] On Behalf Of Simon Talbot
Sent: 07 November 2005 21:28
To: Sylvain Vittecoq; Christian Ehrhardt
Cc: quagga-dev at lists.quagga.net
Subject: [quagga-dev 3817] Re: Kernel Panic in memory allocation
forRFC2385patch

I have implemented this now and am about to put it into our test
environment, has anyone else tried it ? Any feedback/problems ?

Simon 


Simon Talbot MEng, ACGI
(Chief Engineer)
Net Solutions Europe Limited
Tel: 0845 6440972
Fax: 0845 6440971

-----Original Message-----
From: quagga-dev-bounces at lists.quagga.net
[mailto:quagga-dev-bounces at lists.quagga.net] On Behalf Of Sylvain
Vittecoq
Sent: 01 November 2005 04:04
To: Christian Ehrhardt; Sylvain Vittecoq
Cc: quagga-dev at lists.quagga.net
Subject: [quagga-dev 3781] Re: Kernel Panic in memory allocation for
RFC2385patch

Hi,

The allocation of MD5 Digest for BGP Sessions is done inside the crypto
module which is not interrupt safe (Most allocations are performed with
GFP_KERNEL).

So let me know if I should not consider fixing the crypto module to make
it interrupt safe:

I would like to replace all GFP_KERNEL references in the crypto module
with a static to make sure we use GFP_ATOMIC whenever we are allocating
some memory in the context of an interrupt:

static inline int gfp_flag(void)
{
    return in_interrupt() ? GFP_ATOMIC : GFP_KERNEL; }

By the way, is in_interrupt() an expensive call ?

Thanks,

Sylvain.


On 10/28/05, Christian Ehrhardt <quagga at c--e.de> wrote:
>
> Hi,
>
> On Thu, Oct 27, 2005 at 02:48:56PM -0400, Sylvain Vittecoq wrote:
> > If flags is GFP_KERNEL and in_interrupt() is true which I assume 
> > could be the case when we process some TCP Packets then we will hit 
> > the BUG because the allocation should only be performed for flags 
> > __GFP_HIGH ...
> >
> > Am I missing anything here ?
>
> I don't know how much of the tcp-stack is done in interrupt context 
> but doing GFP_KERNEL allocations from an interrupt is definitely a bug

> und the code doing this must be fixed.
>
> > Should this test be relaxed or should we force a different type of
>
> No the BUG test is ok.
>
> > allocation in the
> > computation of Md5 keys for TCP Packets ?
>
> Probably. Try to use GFP_ATOMIC but keep in mind that GFP_ATOMIC 
> allocation may return NULL if there is no memory availiable.
>
>     regards   Christian
>
>


--
Sylvain Vittecoq
1151 North 3rd Street Apt 408
Philadelphia, 19123 PA USA
Cell : 1 215 290 2632

_______________________________________________
Quagga-dev mailing list
Quagga-dev at lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

_______________________________________________
Quagga-dev mailing list
Quagga-dev at lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev




More information about the Quagga-dev mailing list