public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* can block drivers get non-fs requests?
@ 2008-08-14 11:38 Pierre Ossman
  2008-08-14 11:42 ` Jens Axboe
  0 siblings, 1 reply; 4+ messages in thread
From: Pierre Ossman @ 2008-08-14 11:38 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Alex Dubov, LKML

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: can block drivers get non-fs requests?
  2008-08-14 11:38 can block drivers get non-fs requests? Pierre Ossman
@ 2008-08-14 11:42 ` Jens Axboe
  2008-08-14 12:39   ` Pierre Ossman
  0 siblings, 1 reply; 4+ messages in thread
From: Jens Axboe @ 2008-08-14 11:42 UTC (permalink / raw)
  To: Pierre Ossman; +Cc: Alex Dubov, LKML

On Thu, Aug 14 2008, Pierre Ossman wrote:
> 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:

You should check in the driver whether the request type is supported. So
if you can only handle fs requests, you should do a check for
!blk_fs_request() after elv_next_request() and call
end_(de)queued_request() appropriately.

> 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.

Yes, that is correct. A PC request is essentially a SCSI command sent
directly.

> 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.

Normal IO activity will only produce fs requests. However, if someone
uses eg SG_IO on your block device, you will be sent pc requests. There
are no checks for this, it is left to the driver.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: can block drivers get non-fs requests?
  2008-08-14 11:42 ` Jens Axboe
@ 2008-08-14 12:39   ` Pierre Ossman
  2008-08-14 14:06     ` Jens Axboe
  0 siblings, 1 reply; 4+ messages in thread
From: Pierre Ossman @ 2008-08-14 12:39 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Alex Dubov, LKML

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On Thu, 14 Aug 2008 13:42:09 +0200
Jens Axboe <jens.axboe@oracle.com> wrote:

> 
> You should check in the driver whether the request type is supported. So
> if you can only handle fs requests, you should do a check for
> !blk_fs_request() after elv_next_request() and call
> end_(de)queued_request() appropriately.
> 

So killing off the request with -EOPNOTSUPP is preferred over having a
prepare function and stopping it there?

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: can block drivers get non-fs requests?
  2008-08-14 12:39   ` Pierre Ossman
@ 2008-08-14 14:06     ` Jens Axboe
  0 siblings, 0 replies; 4+ messages in thread
From: Jens Axboe @ 2008-08-14 14:06 UTC (permalink / raw)
  To: Pierre Ossman; +Cc: Alex Dubov, LKML

On Thu, Aug 14 2008, Pierre Ossman wrote:
> On Thu, 14 Aug 2008 13:42:09 +0200
> Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > 
> > You should check in the driver whether the request type is supported. So
> > if you can only handle fs requests, you should do a check for
> > !blk_fs_request() after elv_next_request() and call
> > end_(de)queued_request() appropriately.
> > 
> 
> So killing off the request with -EOPNOTSUPP is preferred over having a
> prepare function and stopping it there?

Nope, that doesn't matter. If you already have a prep function, using
BLKPREP_KILL is the easiest solution.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-08-14 14:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-14 11:38 can block drivers get non-fs requests? Pierre Ossman
2008-08-14 11:42 ` Jens Axboe
2008-08-14 12:39   ` Pierre Ossman
2008-08-14 14:06     ` Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox