Re: QUESTION: block layer ->request and tasklets

[Maxim Levitsky <maximlevitsky@gmail.com>]

On Thu, 2010-09-30 at 19:52 +0200, Maxim Levitsky wrote:
> Hi,
> 
> I have an issue that is possible related to my lack of understanding of
> the block system, that really drives me nuts.
> 
> Here is the short description:
> 
> A 'perfect' block driver is supposed to start a sector transfer right in
> the ->request.
> 
> An IRQ will cause the driver to end this request (or part of it), and
> try to fetch another one and submit it to the hardware, effectively
> doing the same thing the ->request does.
> This is not easy to implement in stand alone block driver, and it is
> even harder to so in a common layer.
> Yet, Alex's memorystick subsystem does implement this style of a driver,
> and it works quite well
> 
> A memory stick low level driver is designed after the block driver.
> It also has a ->request function and a 'queue' of requests, even though
> this is an illusion, because every time a request is 'fetched' from
> upper layer, it is created on the fly by a state machine.
> An upper level driver is a block driver.
> 
> Now the problem:
> The jmb38x_ms ->request function doesn't set the hardware, but rather it
> queues a tasklet, which does the work.
> It seems to be redundant, and yet if I remove the tasklet, the system
> randomly freezes, and worse that that, none of lockup detecters catch
> it, so I am unable to get a backtrace.
> This is a time I am really mad at hardware vendors for removing the
> reset button....
> 
> On the other hand my ms_block.c, an upper level driver for old
> MemorySticks, works OK.
> But it contains a thread that does the IO. Its ->request only wakes it
> up.
> 
> So in both cases, the block layer calls the ->request of the high level
> block driver, and then execution context switches (to thread or tasklet)
> which setups the IO.
> I have a bad feeling that this is a race/deadlock somewhere, but I
> triple checked everything.
> 
> 
> Any ideas?
Please disregard this.
The spinlock debugging saved me. I got a backtrace, and of course found
what I expected, a spin on already taken spinlock.

I really didn't expect memstick_next_request (and state machines it
calls) to call the memstick_new_request and therefore jmicron's
->request.
I fixed mspro_block.c not to so (don't call memstick_new_request from
state machine handlers, and problem went away. 
Now I can happily remove that tasklet :-)

Jens Axboe, sorry for noise.

Best regards,
	Maxim Levitsky