Date: Thu, 5 Jan 2006 17:27:37 -0500
From: Jeff Dike <jdike@addtoit.com>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: + uml-sigwinch-handling-cleanup.patch added to -mm tree
Message-ID: <20060105222737.GA10369@ccure.user-mode-linux.org>
References: <200601042323.k04NNti4021942@shell0.pdx.osdl.net> <200601052054.37512.blaisorblade@yahoo.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200601052054.37512.blaisorblade@yahoo.it>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1325
Lines: 29

On Thu, Jan 05, 2006 at 08:54:37PM +0100, Blaisorblade wrote:
> Meanwhile, the whole content of the new free_winch(), including some syscalls
> on the host, and various other stuff, is brought back under the 
> winch_handler_lock.

And?  There's no particular problem with host system calls being under
a lock.  And the various other stuff is a kfree and a free_irq, which
I don't think have a problem being called under a spinlock.

> I had carefully brought that stuff out keeping only the list access under the
> lock, probably while fixing some "scheduling while atomic" warnings - once 
> the element is out of the list it's unreachable thus (IMHO) safely 
> accessible.

Probably?  What in there is sensitive to being called under a lock?

> So, list_del should be brought out from free_winch, which would then become 
> callable without the spinlock held.

That would increase the amount of code, with no gain that I can see.
The list_del would be duplicated, and the loop in winch_cleanup would
have to drop and reacquire the lock around each call to free_winch.

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