Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S261228AbSJYGJX>; Fri, 25 Oct 2002 02:09:23 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S261238AbSJYGJX>; Fri, 25 Oct 2002 02:09:23 -0400
Received: from moutvdom.kundenserver.de ([195.20.224.149]:56033 "EHLO
	moutvdom.kundenserver.de") by vger.kernel.org with ESMTP
	id <S261228AbSJYGJW>; Fri, 25 Oct 2002 02:09:22 -0400
Date: Fri, 25 Oct 2002 08:15:05 +0200 (MEST)
From: Armin Schindler <mac@melware.de>
To: Kai Germaschewski <kai-germaschewski@uiowa.edu>
cc: Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: module_init in interrupt context ?
In-Reply-To: <Pine.LNX.4.44.0210241208130.6574-100000@chaos.physics.uiowa.edu>
Message-ID: <Pine.LNX.4.31.0210250806470.24067-100000@phoenix.one.melware.de>
Organization: Cytronics & Melware
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1658
Lines: 43

On Thu, 24 Oct 2002, Kai Germaschewski wrote:
> On Thu, 24 Oct 2002, Armin Schindler wrote:
>
> > Yes, you are right, it is something else.
> > The problem is, that in_interrupt() is true if local_bh_count()
> > is != 0, which basically sounds correct, but if we are in
> > spin_lock_bh(), local_bh_count() is also != 0.
> >
> > This means, in_interrupt() is always true when called inside
> > spin_[un]lock_bh() region.
> >
> > So, it is not allowed to call create_proc_entry after
> > spin_lock_bh(), because sub-function proc_create()
> > calles kmalloc() with GFP_KERNEL and then in_interrupt()
> > is tested again, which gives the wrong status and
> > causes BUG() in kmem_cache_grow().
> >
> > Was this done on purpose ?
>
> You are never allowed to sleep with a spinlock held, no matter if it's
> _bh, _irq or just a plain spin_lock(). Doing so creates the possibility of
> deadlock (assuming your lock actually is necessary and you're not
> serialized already), current 2.5 btw has debugging code which checks for
> this bug.
>
> So this code was buggy in earlier 2.4 as well, you'll have to create your
> proc entry outside the protected region or use a semaphore instead of a
> spinlock.

Okay, I wasn't aware of create_proc_entry() must to be called
from user-context and outside any locks.

But anyway, isn't the statement "in_interrupt() != 0" somehow wrong
when just the bh's are disabled ?

Armin


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/