On Sun, 2007-03-04 at 00:36 -0700, Dachepalli, Sudhir wrote:
> Our driver gets called in with the following fashion through the
> queuecommand.
>
> scsi_request_fn() -> scsi_dispatch_cmd() -> rtn =
> host->hostt->queuecommand(cmd, scsi_done);
>
> We are using the "cmd" ( scsi_cmnd) as a pass thro
James Bottomley wrote:
> On Sun, 2007-03-04 at 00:36 -0700, Dachepalli, Sudhir wrote:
>> Our driver gets called in with the following fashion through the
>> queuecommand.
>>
>> scsi_request_fn() -> scsi_dispatch_cmd() -> rtn =
>> host->hostt->queuecommand(cmd, scsi_done);
>>
>> We are using the "cm
On Sun, 2007-03-04 at 09:43 -0600, Mike Christie wrote:
> There are trying to do a scsi level multipath driver for RDAC support.
> And they are trying to do something similar to request based multipath
> (route requests instead of bios but in their case they are routing
> scsi_cmnds instead of requ
James Bottomley wrote:
> On Sun, 2007-03-04 at 09:43 -0600, Mike Christie wrote:
>> There are trying to do a scsi level multipath driver for RDAC support.
>> And they are trying to do something similar to request based multipath
>> (route requests instead of bios but in their case they are routing
On Sun, 2007-03-04 at 10:21 -0600, Mike Christie wrote:
> I think they get around this and other request settings that need
> resetting by using scsi_execute_async. They will take the command, data
> direction and buffer fields from the original scsi_cmnd, then pass those
> on to scsi_ececute_async
James Bottomley wrote:
> On Sun, 2007-03-04 at 10:21 -0600, Mike Christie wrote:
>> I think they get around this and other request settings that need
>> resetting by using scsi_execute_async. They will take the command, data
>> direction and buffer fields from the original scsi_cmnd, then pass thos
Mike Christie wrote:
> James Bottomley wrote:
>> On Sun, 2007-03-04 at 10:21 -0600, Mike Christie wrote:
>>> I think they get around this and other request settings that need
>>> resetting by using scsi_execute_async. They will take the command, data
>>> direction and buffer fields from the origina
Do you think the following could work If I used blk layer functions
instead of "scsi_execute_async":
Blk_get_request()
Req->flags |= REQ_DONTPREP
Blk_rq_map_kern()
Blk_execute_req_nowait()
Blk_put_request()
Regards,
Sudhir
-Original Message-
From: Mike Christie [mailto:[EMAIL PROTECTED]
On Sun, 2007-03-04 at 11:00 -0700, Dachepalli, Sudhir wrote:
> Do you think the following could work If I used blk layer functions
> instead of "scsi_execute_async":
>
> Blk_get_request()
> Req->flags |= REQ_DONTPREP
There's additional complexity here: if the request isn't prepared, no
command i
There is no big changes between v4 and v5. I was able to fix
things in scsi tgt, so I could remove the weird arguements
the block helpers were taking for it. I also tried to break
up the patchset for easier viewing. The final patch also
takes care of the access_ok regression.
These patches were ma
From: Mike Christie <[EMAIL PROTECTED]>
scsi tgt breaks up a command into multple scatterlists
if we cannot fit all the data in one. This was because
the block rq helpers did not support large requests and
because we can get a command of any old size so it is
hard to preallocate pages for scatterl
From: Mike Christie <[EMAIL PROTECTED]>
Everyone is passing in NULL, so let's just
make it a little more simple and drop the
block device argument from the bio mapping
functions.
Signed-off-by: Mike Christie <[EMAIL PROTECTED]>
---
block/ll_rw_blk.c |4 ++--
fs/bio.c| 17 +
From: Mike Christie <[EMAIL PROTECTED]>
sg.c supports mmap, so this patch just move the code
to the block layer for others to share and converts it
to the bio reserved buffer.
The helpers are:
- blk_rq_mmap - does some checks to makre sure the reserved buf is
large enough.
- blk_rq_vma_nopage - t
From: Mike Christie <[EMAIL PROTECTED]>
sg and st use a reserve buffer so that they can always
gaurantee that they can execute IO of a certain size
which is larger than the worst case guess.
This patch adds a bio_reserved_buf structure, which holds mutlple
segments that can be mapped into BIOs. T
From: Mike Christie <[EMAIL PROTECTED]>
sg.c and st allocate large chunks of clustered pages
to try and make really large requests. The block
layer sg io code only allocates a page at a time,
so we can end up with lots of unclustered pages
and smaller requests.
This patch modifies the block layer
From: Mike Christie <[EMAIL PROTECTED]>
sg.c does a access_ok test on the user buffer when doing
indirect IO. bsg and scsi_ioctl.c did not, but it seems
like it would be ok to be common. This patch moves that
test to the block layer helpers.
Signed-off-by: Mike Christie <[EMAIL PROTECTED]>
---
bl
From: Mike Christie <[EMAIL PROTECTED]>
Convert sg to block layer helpers. I have tested with sg3_utils and
sg_utils. I have tested the mmap, iovec, dio and indirect IO paths,
by running those tools and the example programs against software
iscsi which does not support clustering, scsi_debug which
James,
How about the following:
1. Cmd= Scsi_get_command( on physical device )
2. Clone the scsi_cmnd fields of the virtual cmnd( command received by
failover driver) to physical cmnd (the command allocated by
scsi_get_command )
3. blk_get_request()
4. fill the request fields, req->special = Cm
[EMAIL PROTECTED] wrote:
> There is no big changes between v4 and v5. I was able to fix
> things in scsi tgt, so I could remove the weird arguements
> the block helpers were taking for it. I also tried to break
> up the patchset for easier viewing. The final patch also
> takes care of the access_ok
Douglas Gilbert wrote:
> Mike,
> I see you are removing the scatter_elem_sz parameter.
> What decides the scatter gather element size? Can it
> be greater than PAGE_SIZE?
Oh yeah, sorry I should have documented that.
I just made the code try to allocate as large a element as possible.
So the code
Mike Christie wrote:
> Douglas Gilbert wrote:
>> Mike,
>> I see you are removing the scatter_elem_sz parameter.
>> What decides the scatter gather element size? Can it
>> be greater than PAGE_SIZE?
>
> Oh yeah, sorry I should have documented that.
>
> I just made the code try to allocate as large
[EMAIL PROTECTED] wrote:
> + if (!access_ok(read ?
> +VERIFY_WRITE : VERIFY_READ,
> +p, iov_len))
> + return -EFAULT;
> }
>
From: Douglas Gilbert <[EMAIL PROTECTED]>
Subject: Re: [PATCH 3/3] tgt: fix scsi command leak
Date: Sat, 03 Mar 2007 11:58:19 -0500
> FUJITA Tomonori wrote:
> > The failure to map user-space pages leads to scsi command leak. It can
> > happens mostly because of user-space daemon bugs (or OOM). Thi
23 matches
Mail list logo
