Messages in this thread | | | Date | Fri, 15 Mar 2002 18:57:47 +0100 | From | Andrea Arcangeli <> | Subject | Re: 2.4.19pre3aa2 |
| |
On Fri, Mar 15, 2002 at 07:35:02PM +0200, Jari Ruusu wrote: > Jens Axboe wrote: > > On Fri, Mar 15 2002, Jari Ruusu wrote: > > > - No more illegal sleeping in generic_make_request(). > > > > I've told you this before -- sleeping in make_request is not illegal, > > heck it happens _all the time_. Safely sleeping requires a reserved pool > > of the units you wish to allocate, of course. In fact I think that would > > be much nicer than the path you are following here by delaying > > allocations to the loop thread (and still not using a reserved pool). > > Yes, I know you have told me that before, but I'm being overcareful. See: > > <quote> from device drivers book by Alessandro Rubini, chapter 12, page 331 > The request function has one very important constraint: it must be atomic. > request is not usually called in direct response to user requests, and it is > not running in the context of any particular process. It can be called at > interrupt time, from tasklets, or from any number of other places. Thus, it > must not sleep while carrying out its tasks. > </quote>
loop isn't implement via ->request_fn anymore. Loop since 2.4 is only driven by the ->make_request_fn, that for the other more normal devices just means the old legacy __make_request. request_fn is subject to the rules pointed out by Alessandro, but ->make_request_fn can sleep just like ll_rw_block can sleep. ->make_request_fn and in turn loop_make_request can only run in normal context with irq enabled and they're both allowed to sleep just like ll_rw_block and submit_bh.
Nevertheless as Jens said the infinite-loop-allocation in the ->make_request_fn path are deadlock prone at the moment, not because they sleeps but because they need a reserved mempool to guarantee operations can go ahead slowly without deadlocks even if dynamic allocation fails, but this is not a very pratical problem, it's very unlikely to deadlock there (it's not worse than the other infinite loop in getblk() that affects not just loop).
Andrea - 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/
| |