Are you confusing generic_make_request() and __make_request().
generic_make_request() doesn't itself grab any locks or sleep. It mostly
sets some stuff up and calls the make_request function that was registered
for the given queue. If the driver hasn't done anything special for its
make_request() function then __make_request() will be that function,
in which case your statements about locking and sleeping are correct.
I suppose that either way you're triggering stuff to run which might
sleep so you shouldn't be holding locks.
You bring up an interresting point though aside from locking.
What I've read has given me the indication that a person writing
a b_end_io() function should assume that they could be called from
interrupt context. If that is the case then any b_end_io() wanting to
call generic_make_request() would need to defer that call until it was
outside of interrupt context. Otherwise the b_end_io() could sleep
within interrupt context. Drivers at the "md" level tend to call
generic_make_request() after b_end_io(), but in the kernel proper I
don't see any others. I haven't traced through the md drivers enough
to know but it does look like they do defer.
I think this may be something I'm doing wrong in a driver on which I'm
working...
Tim
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:23 EST