linux-kernel - QUESTION: block layer ->request and tasklets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1285869154.26846.44.camel@maxim-laptop>
Date:	Thu, 30 Sep 2010 19:52:34 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Cc:	Jens Axboe <axboe@...nel.dk>, Alex Dubov <oakad@...oo.com>
Subject: QUESTION: block layer ->request and tasklets

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/