netdev
[Top] [All Lists]

Re: [Fwd: [Bug 3003] New: might_sleep warning when setting up IPSec with

To: Nivedita Singhvi <niv@xxxxxxxxxx>
Subject: Re: [Fwd: [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP]
From: Christophe Saout <christophe@xxxxxxxx>
Date: Fri, 02 Jul 2004 23:35:59 +0200
Cc: James Morris <jmorris@xxxxxxxxxxxxxxxx>, akpm@xxxxxxxx, netdev <netdev@xxxxxxxxxxx>, mjbligh@xxxxxxxxxx
In-reply-to: <40E5D326.5000509@xxxxxxxxxx>
References: <40E5A1B3.2020202@xxxxxxxxxx> <40E5D326.5000509@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
Am Fr, den 02.07.2004 um 14:27 Uhr -0700 schrieb Nivedita Singhvi:

> We are grabbing dst->xfrm lock in ipcomp_output(),
> and have it held when we call ipcomp_compress().
> 
> Is that the issue? I don't have the crypto module
> code, but in_atomic() will be true.

Yes. But the code might also be called from softirq context, when a
packed from the NIC gets handled or when a slot in the queue becomes
free. (I've also got warnings from those two cases in my logs)

The compress/decompress calls should be able to be run from softirq
(atomic) context just like encrypt/decrypt.

I'm just wondering, why does deflate_compress call deflate_comp_init
when it is called the first time, but deflate_init is a noop? Shouldn't
the deflate_comp_init call just be moved to deflate_init?

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

<Prev in Thread] Current Thread [Next in Thread>