Messages in this thread | | | Date | Wed, 9 Aug 2006 16:44:59 +0200 (CEST) | From | Paolo Giarrusso <> | Subject | Re: [PATCH 2/3] uml: fix proc-vs-interrupt context spinlock deadlock |
| |
Jeff Dike <jdike@addtoit.com> ha scritto:
> 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.
Guess I'll put it in Documentation and reference it.
> The locking, as it stands, looks consistent and conservative. Yes, it is. > However, there are some places where critical sections are too big > and > the locking should be narrowed.
Yes, in particular we cannot hold a spinlock for the whole _open since it must call sleeping functions.
> > 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.
I'll try then to finish the patches soon and merge them; the main problem is splitting (including the use of different locks) normal locking from our peculiar locking of _open/_close against mconsole changes.
Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - 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/
| |