QUESTION: block layer ->request and tasklets

QUESTION: block layer ->request and tasklets

[Maxim Levitsky]

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?

Best regards,
	Maxim Levitsky

Re: QUESTION: block layer ->request and tasklets

[Maxim Levitsky]

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