From: Jeff Dike <jdike@addtoit.com>
To: Paolo Giarrusso <blaisorblade@yahoo.it>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org,
user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] [PATCH 2/3] uml: fix proc-vs-interrupt context spinlock deadlock
Date: Tue, 8 Aug 2006 16:02:31 -0400 [thread overview]
Message-ID: <20060808200231.GA6463@ccure.user-mode-linux.org> (raw)
In-Reply-To: <20060808105905.10762.qmail@web25224.mail.ukl.yahoo.com>
On Tue, Aug 08, 2006 at 12:59:05PM +0200, Paolo Giarrusso wrote:
> I could be wrong, but I trust that thanks to deep and good work by
> who designed locking in the network layer, this patch is correct. And
> indeed I addressed your issues below.
OK, but there will need to be comments explaining why it is OK that
this data only looks half-locked.
The locking, as it stands, looks consistent and conservative.
However, there are some places where critical sections are too big and
the locking should be narrowed.
> This is also true of char/block devices (you don't need to lock
> against write/read in open/close; UBD doesn't know that but I have
> unfinished patches for it), but there it's simpler: if userspace you
> call close while a read is executing, thanks to refcounting (sys_read
> does fget) the ->close (or ->release) is only called after the end of
> ->read.
In my current patchset, there is a per-queue lock which is mostly
managed by the block layer.
Jeff
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Dike <jdike@addtoit.com>
To: Paolo Giarrusso <blaisorblade@yahoo.it>
Cc: Andrew Morton <akpm@osdl.org>,
user-mode-linux-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] uml: fix proc-vs-interrupt context spinlock deadlock
Date: Tue, 8 Aug 2006 16:02:31 -0400 [thread overview]
Message-ID: <20060808200231.GA6463@ccure.user-mode-linux.org> (raw)
In-Reply-To: <20060808105905.10762.qmail@web25224.mail.ukl.yahoo.com>
On Tue, Aug 08, 2006 at 12:59:05PM +0200, Paolo Giarrusso wrote:
> I could be wrong, but I trust that thanks to deep and good work by
> who designed locking in the network layer, this patch is correct. And
> indeed I addressed your issues below.
OK, but there will need to be comments explaining why it is OK that
this data only looks half-locked.
The locking, as it stands, looks consistent and conservative.
However, there are some places where critical sections are too big and
the locking should be narrowed.
> This is also true of char/block devices (you don't need to lock
> against write/read in open/close; UBD doesn't know that but I have
> unfinished patches for it), but there it's simpler: if userspace you
> call close while a read is executing, thanks to refcounting (sys_read
> does fget) the ->close (or ->release) is only called after the end of
> ->read.
In my current patchset, there is a per-queue lock which is mostly
managed by the block layer.
Jeff
next prev parent reply other threads:[~2006-08-08 20:02 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-06 15:47 [uml-devel] [PATCH 1/3] uml: use -mcmodel=kernel for x86_64 Paolo 'Blaisorblade' Giarrusso
2006-08-06 15:47 ` Paolo 'Blaisorblade' Giarrusso
2006-08-06 15:47 ` [uml-devel] [PATCH 2/3] uml: fix proc-vs-interrupt context spinlock deadlock Paolo 'Blaisorblade' Giarrusso
2006-08-06 15:47 ` Paolo 'Blaisorblade' Giarrusso
2006-08-07 22:14 ` [uml-devel] " Jeff Dike
2006-08-07 22:14 ` Jeff Dike
2006-08-08 10:59 ` [uml-devel] " Paolo Giarrusso
2006-08-08 10:59 ` Paolo Giarrusso
2006-08-08 20:02 ` Jeff Dike [this message]
2006-08-08 20:02 ` Jeff Dike
2006-08-09 14:44 ` [uml-devel] " Paolo Giarrusso
2006-08-09 14:44 ` Paolo Giarrusso
2006-08-06 15:47 ` [uml-devel] [PATCH 3/3] uml: clean our set_ether_mac Paolo 'Blaisorblade' Giarrusso
2006-08-06 15:47 ` Paolo 'Blaisorblade' Giarrusso
2006-08-07 22:17 ` [uml-devel] " Jeff Dike
2006-08-07 22:17 ` Jeff Dike
2006-08-07 21:18 ` [uml-devel] [PATCH 1/3] uml: use -mcmodel=kernel for x86_64 Jeff Dike
2006-08-07 21:18 ` Jeff Dike
2006-08-08 10:46 ` [uml-devel] " Paolo Giarrusso
2006-08-08 10:46 ` Paolo Giarrusso
2006-08-08 11:22 ` [uml-devel] " Andi Kleen
2006-08-08 11:22 ` Andi Kleen
2006-08-08 14:03 ` [uml-devel] " Paolo Giarrusso
2006-08-08 14:03 ` Paolo Giarrusso
2006-08-08 14:14 ` [uml-devel] " Andi Kleen
2006-08-08 14:14 ` Andi Kleen
2006-08-08 14:47 ` [uml-devel] " Daniel Gryniewicz
2006-08-08 14:47 ` Daniel Gryniewicz
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=20060808200231.GA6463@ccure.user-mode-linux.org \
--to=jdike@addtoit.com \
--cc=akpm@osdl.org \
--cc=blaisorblade@yahoo.it \
--cc=linux-kernel@vger.kernel.org \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.