* [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
* 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
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