linux-kernel - can block drivers get non-fs requests?

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 14 Aug 2008 13:38:10 +0200
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	Jens Axboe <axboe@...nel.dk>
Cc:	Alex Dubov <oakad@...oo.com>, LKML <linux-kernel@...r.kernel.org>
Subject: can block drivers get non-fs requests?

Hi Jens,

There is one part of the block layer I'm having trouble completely
understanding (well there are loads really, but right now there's one in
particular :)):

Do block drivers need to watch out for requests that aren't "normal"
reads and writes? The MMC block driver has a funky prepare function
that checks for FS and PC requests and discards anything else. I
believe this is wrong in two regards:

a) PC requests seem to be prepared SCSI cmds, and the MMC driver just
expects normal transfer requests. Therefore, such requests should not
be accepted by this driver.

b) The block layer won't throw weird stuff at us unless explicitly told
so. I.e. a normal block queue will only produce normal FS requests.

Please educate the masses. :)

(I've cc:d Alex as he copied the MMC block driver for the MemoryStick
code, so he's probably also interested in this)

Rgds

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, core developer          http://www.rdesktop.org

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)