QUESTION: block layer ->request and tasklets

[Maxim Levitsky <maximlevitsky@gmail.com>]

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