* Re: [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup [not found] <200610292023.12980.blaisorblade@yahoo.it> @ 2006-10-30 8:26 ` Jens Axboe 0 siblings, 0 replies; 2+ messages in thread From: Jens Axboe @ 2006-10-30 8:26 UTC (permalink / raw) To: Blaisorblade; +Cc: akpm, jdike, user-mode-linux-devel, linux-kernel On Sun, Oct 29 2006, Blaisorblade wrote: > Add some comments about requirements for ubd_io_lock and expand its use. > > When an irq signals that the "controller" (i.e. another thread on the host, > which does the actual requests and is the only one blocked on I/O on the > host) has done some work, we call again the request function ourselves > (do_ubd_request). > > We now do that with ubd_io_lock held - that's useful to protect against > concurrent calls to elv_next_request and so on. Not only useful, required, as I think I complained about a year or more ago :-) > XXX: Maybe we shouldn't call at all the request function. Input needed on > this. Are we supposed to plug and unplug the queue? That code "indirectly" > does that by setting a flag, called do_ubd, which makes the request function > return (it's a residual of 2.4 block layer interface). Sometimes you need to. I'd probably just remove the do_ubd check and always recall the request function when handling completions, it's easier and safe. -- Jens Axboe ^ permalink raw reply [flat|nested] 2+ messages in thread
* [PATCH 00/11] UBD driver little cleanups for 2.6.19 @ 2006-10-29 19:17 Paolo 'Blaisorblade' Giarrusso 2006-10-29 19:20 ` [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup Paolo 'Blaisorblade' Giarrusso 0 siblings, 1 reply; 2+ messages in thread From: Paolo 'Blaisorblade' Giarrusso @ 2006-10-29 19:17 UTC (permalink / raw) To: Andrew Morton; +Cc: Jeff Dike, user-mode-linux-devel, linux-kernel Many cleanups for the UBD driver; these are mostly microfixes, I was waiting to finish and reorder also locking fixes (the code works, it is only to resplit, reproof-read and changelogs must be written) but I decided to send these ones for now. The rest will maybe be merged for 2.6.20. The only locking change is a conversion of a spinlock to a mutex, but it is correct anyway, and it has been tested (which is enough since it relates just to the setup/teardown path) with all debugging options active; I did boot-test and hotplug/hotunplug test. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ^ permalink raw reply [flat|nested] 2+ messages in thread
* [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup 2006-10-29 19:17 [PATCH 00/11] UBD driver little cleanups for 2.6.19 Paolo 'Blaisorblade' Giarrusso @ 2006-10-29 19:20 ` Paolo 'Blaisorblade' Giarrusso 0 siblings, 0 replies; 2+ messages in thread From: Paolo 'Blaisorblade' Giarrusso @ 2006-10-29 19:20 UTC (permalink / raw) To: Andrew Morton; +Cc: Jeff Dike, user-mode-linux-devel, linux-kernel From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Add some comments about requirements for ubd_io_lock and expand its use. When an irq signals that the "controller" (i.e. another thread on the host, which does the actual requests and is the only one blocked on I/O on the host) has done some work, we call again the request function ourselves (do_ubd_request). We now do that with ubd_io_lock held - that's useful to protect against concurrent calls to elv_next_request and so on. XXX: Maybe we shouldn't call at all the request function. Input needed on this. Are we supposed to plug and unplug the queue? That code "indirectly" does that by setting a flag, called do_ubd, which makes the request function return (it's a residual of 2.4 block layer interface). Meanwhile, however, merge this patch, which improves things. Cc: Jens Axboe <axboe@suse.de> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> --- arch/um/drivers/ubd_kern.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c index e4fd29a..1202592 100644 --- a/arch/um/drivers/ubd_kern.c +++ b/arch/um/drivers/ubd_kern.c @@ -106,6 +106,8 @@ static inline void ubd_set_bit(__u64 bit #define DRIVER_NAME "uml-blkdev" +/* Can be taken in interrupt context, and is passed to the block layer to lock + * the request queue. Kernel side code knows that. */ static DEFINE_SPINLOCK(ubd_io_lock); static DEFINE_MUTEX(ubd_lock); @@ -497,6 +499,8 @@ static void __ubd_finish(struct request end_request(req, 1); } +/* Callable only from interrupt context - otherwise you need to do + * spin_lock_irq()/spin_lock_irqsave() */ static inline void ubd_finish(struct request *req, int error) { spin_lock(&ubd_io_lock); @@ -504,7 +508,7 @@ static inline void ubd_finish(struct req spin_unlock(&ubd_io_lock); } -/* Called without ubd_io_lock held */ +/* Called without ubd_io_lock held, and only in interrupt context. */ static void ubd_handler(void) { struct io_thread_req req; @@ -525,7 +529,9 @@ static void ubd_handler(void) ubd_finish(rq, req.error); reactivate_fd(thread_fd, UBD_IRQ); + spin_lock(&ubd_io_lock); do_ubd_request(ubd_queue); + spin_unlock(&ubd_io_lock); } static irqreturn_t ubd_intr(int irq, void *dev) Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-10-30 8:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200610292023.12980.blaisorblade@yahoo.it>
2006-10-30 8:26 ` [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup Jens Axboe
2006-10-29 19:17 [PATCH 00/11] UBD driver little cleanups for 2.6.19 Paolo 'Blaisorblade' Giarrusso
2006-10-29 19:20 ` [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup Paolo 'Blaisorblade' Giarrusso
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox