netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Nivedita Singhvi <niv@us.ibm.com>
Cc: niv@us.ibm.com, jmorris@intercode.com.au, netdev@oss.sgi.com,
	christophe@saout.de, mjbligh@us.ibm.com
Subject: Re: [Fwd: [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP]
Date: Fri, 2 Jul 2004 14:39:49 -0700	[thread overview]
Message-ID: <20040702143949.21a50b74.akpm@osdl.org> (raw)
In-Reply-To: <40E5D326.5000509@us.ibm.com>

Nivedita Singhvi <niv@us.ibm.com> wrote:
>
> Nivedita Singhvi wrote:
> 
> > James, Andrew,
> > 
> > Looks like deflate_comp_init() is not calling
> > __vmalloc in a kosher way.
> 
> > Jul  2 18:39:04 websrv Debug: sleeping function called from invalid 
> > context at
> > mm/slab.c:1994
> > Jul  2 18:39:04 websrv in_atomic():1, irqs_disabled():0
> > Jul  2 18:39:04 websrv [<c0106c37>] dump_stack+0x17/0x20
> > Jul  2 18:39:04 websrv [<c0118fb4>] __might_sleep+0xb4/0xe0
> > Jul  2 18:39:04 websrv [<c0139fbc>] kmem_cache_alloc+0x5c/0x60
> > Jul  2 18:39:04 websrv [<c0147bc0>] __get_vm_area+0x20/0xf0
> > Jul  2 18:39:04 websrv [<c0147cb4>] get_vm_area+0x24/0x30
> > Jul  2 18:39:04 websrv [<c0147f1c>] __vmalloc+0x3c/0x100
> > Jul  2 18:39:04 websrv [<c01ecdca>] deflate_comp_init+0x4a/0xf0
> > Jul  2 18:39:04 websrv [<c01ecf44>] deflate_compress+0x24/0x80
> > Jul  2 18:39:04 websrv [<c01e8a84>] crypto_compress+0x24/0x30
> > Jul  2 18:39:04 websrv [<c031744c>] ipcomp_compress+0x6c/0x110
> > Jul  2 18:39:04 websrv [<c0317681>] ipcomp_output+0xc1/0x370
> 
> 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, that is the issue.

>From a design point-of-view, it is not idiomatic for deflate_compress() to
be doing this magical lazy initialisation.  It would be better if the
client of the deflate.c code were to explicitly initialise the context
before diving in and using it.

	/*
	 * Lazy initialization to make interface simple without allocating
	 * un-needed workspaces.  Thus can be called in softirq context.
	 */
	static int deflate_comp_init(struct deflate_ctx *ctx)

Well no.  Those games with deflate_gfp() really need to go away. 
in_atomic() works OK if CONFIG_PREEMPT is enabled.  But with
CONFIG_PREEMPT=n, in_atomic() returns false inside spinlock.  And
in_atomic()'s return value is unaffected by local_irq_disable().

This all needs to be redesigned, sorry.

  parent reply	other threads:[~2004-07-02 21:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-02 17:56 [Fwd: [Bug 3003] New: might_sleep warning when setting up IPSec with IPCOMP] Nivedita Singhvi
2004-07-02 17:58 ` Christophe Saout
2004-07-02 21:27 ` Nivedita Singhvi
2004-07-02 21:35   ` Christophe Saout
2004-07-02 21:39   ` Andrew Morton [this message]
2004-07-09  4:20     ` James Morris
2004-07-09 23:58       ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040702143949.21a50b74.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=christophe@saout.de \
    --cc=jmorris@intercode.com.au \
    --cc=mjbligh@us.ibm.com \
    --cc=netdev@oss.sgi.com \
    --cc=niv@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).