Can a non-sg scsi write command be more than PAGE_SIZE length?

Can a non-sg scsi write command be more than PAGE_SIZE length?

[Olivier Galibert]

...or more importantly, is it allowed.  Kernel is FC3 2.6.10-1.766.

The latest iscsi driver[1] blows on a 32K-long request for a tape write
which followed this path:

 [<f8cef985>] iscsi_queuecommand+0x161/0x2f1 [iscsi_tcp]
 [<f883f724>] scsi_dispatch_cmd+0x1e9/0x24f [scsi_mod]
 [<f88440ff>] scsi_request_fn+0x29a/0x310 [scsi_mod]
 [<c0217487>] blk_insert_request+0x8b/0x9e
 [<f88430b8>] scsi_insert_special_req+0x20/0x26 [scsi_mod]
 [<f8cc043e>] st_do_scsi+0x111/0x147 [st]
 [<f8cc026c>] st_sleep_done+0x0/0xc1 [st]
 [<f8cc189b>] st_write+0x3eb/0x671 [st]
 [<c0152484>] vfs_write+0xb6/0xe2
 [<c015254e>] sys_write+0x3c/0x62
 [<c0103c97>] syscall_call+0x7/0xb

The command is not using scatter-gather (sc->use_sg is 0) but is more
than PAGE_SIZE, and the driver hates that.  So my question is whether
it's allowed (then I'll have to fix the driver, not sure many people
have virtual tapes over iscsi) or whether st_write has to be fixed.

  OG.

[1] 5.0.0.2.

Re: Can a non-sg scsi write command be more than PAGE_SIZE length?

[Christoph Hellwig]

On Tue, Apr 19, 2005 at 10:47:30AM +0200, Olivier Galibert wrote:
> ...or more importantly, is it allowed.  Kernel is FC3 2.6.10-1.766.

Yes, it's allowed.

Re: Can a non-sg scsi write command be more than PAGE_SIZE length?

[Olivier Galibert]

On Tue, Apr 19, 2005 at 09:50:08AM +0100, Christoph Hellwig wrote:
> On Tue, Apr 19, 2005 at 10:47:30AM +0200, Olivier Galibert wrote:
> > ...or more importantly, is it allowed.  Kernel is FC3 2.6.10-1.766.
> 
> Yes, it's allowed.

Thanks.  Pages in that case are continuous then, right?

  OG.

Re: Can a non-sg scsi write command be more than PAGE_SIZE length?

[Christoph Hellwig]

On Tue, Apr 19, 2005 at 11:24:31AM +0200, Olivier Galibert wrote:
> > Yes, it's allowed.
> 
> Thanks.  Pages in that case are continuous then, right?

Good question actually.  I know XFS does passed vmalloc'ed memory down
the block I/O path, but that's as a scatter/gather request.  All non-s/g
request should be contingous I think.

We really need to write down the rules about what memory can be passed
down the block I/O path - XFS for example sends kmalloced memory down
which all the iSCSI implementations don't like at all.

Re: Can a non-sg scsi write command be more than PAGE_SIZE length?

[James Bottomley]

On Tue, 2005-04-19 at 10:29 +0100, Christoph Hellwig wrote:
> Good question actually.  I know XFS does passed vmalloc'ed memory down
> the block I/O path, but that's as a scatter/gather request.  All non-s/g
> request should be contingous I think.
> 
> We really need to write down the rules about what memory can be passed
> down the block I/O path - XFS for example sends kmalloced memory down
> which all the iSCSI implementations don't like at all.

We have two rules and two cases in every driver: sg and non-sg.  (i.e.
use_sg == 0)  this is where we do the distinction between dma_map_sg and
dma_map_single.

If someone wants a project, it should be possible to eject our non-sg
path.  This would mean that all requests go as sg through the block
layer.  The advantages would be

1) internally we would no longer care about kmalloc vs vmalloc memory
2) we wouldn't need to know the gfp flag when allocating internal
requests (block would bounce for us if necessary) thus we could kill the
scsi isa dma flag
3) We could strip the special casing out of every driver ...
4) it should simplify the I/O traversal paths

James