From: Boaz Harrosh <bharrosh@panasas.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: James.Bottomley@suse.de, jaxboe@fusionio.com,
linux-scsi@vger.kernel.org, Sathya.Prakash@lsi.com
Subject: Re: [PATCH] scsi: fix scsi_get_lba helper function for pc command
Date: Wed, 02 Jun 2010 11:54:25 +0300 [thread overview]
Message-ID: <4C061C41.2010104@panasas.com> (raw)
In-Reply-To: <20100602173925H.fujita.tomonori@lab.ntt.co.jp>
On 06/02/2010 11:39 AM, FUJITA Tomonori wrote:
> On Wed, 02 Jun 2010 11:14:04 +0300
> Boaz Harrosh <bharrosh@panasas.com> wrote:
>
>>> static void scsi_run_queue(struct request_queue *q);
>>>
>>> +int scsi_get_data_transfer_info(unsigned char *cmd, unsigned long long *lba,
>>> + unsigned int *num, unsigned int *ei_lba)
>>> +{
>>> + int ret = 0;
>>> +
>>> + switch (*cmd) {
>>> + case VARIABLE_LENGTH_CMD:
>>> + *lba = get_unaligned_be64(&cmd[12]);
>>> + *num = get_unaligned_be32(&cmd[28]);
>>> + *ei_lba = get_unaligned_be32(&cmd[20]);
>>
>> This is true for scsi_debug maybe but totally wrong
>> for any none disk command set.
>
> Ok, I can remove it.
>
>
>>> + break;
>>> + case WRITE_16:
>>> + case READ_16:
>>> + case VERIFY_16:
>>> + case WRITE_SAME_16:
>>> + *lba = get_unaligned_be64(&cmd[2]);
>>> + *num = get_unaligned_be32(&cmd[10]);
>>> + break;
>>> + case WRITE_12:
>>> + case READ_12:
>>> + case VERIFY_12:
>>> + *lba = get_unaligned_be32(&cmd[2]);
>>> + *num = get_unaligned_be32(&cmd[6]);
>>> + break;
>>> + case WRITE_10:
>>> + case READ_10:
>>> + case XDWRITEREAD_10:
>>> + case VERIFY:
>>> + case WRITE_SAME:
>>> + *lba = get_unaligned_be32(&cmd[2]);
>>> + *num = get_unaligned_be16(&cmd[7]);
>>> + break;
>>> + case WRITE_6:
>>> + case READ_6:
>>> + *lba = (u32)cmd[3] | (u32)cmd[2] << 8 |
>>> + (u32)(cmd[1] & 0x1f) << 16;
>>> + *num = (0 == cmd[4]) ? 256 : cmd[4];
>>> + break;
>>> + default:
>>> + ret = -1;
>>> + break;
>>> + }
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL(scsi_get_data_transfer_info);
>>> +
>>> /*
>>> * Function: scsi_unprep_request()
>>> *
>>> @@ -1046,6 +1093,8 @@ int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req)
>>> {
>>> struct scsi_cmnd *cmd;
>>> int ret = scsi_prep_state_check(sdev, req);
>>> + unsigned int num, ei_lba;
>>> + unsigned long long lba;
>>>
>>> if (ret != BLKPREP_OK)
>>> return ret;
>>> @@ -1082,7 +1131,10 @@ int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req)
>>> cmd->sc_data_direction = DMA_TO_DEVICE;
>>> else
>>> cmd->sc_data_direction = DMA_FROM_DEVICE;
>>> -
>>> +
>>> + scsi_get_data_transfer_info(cmd->cmnd, &lba, &num, &ei_lba);
>>> + req->__sector = lba;
>>> +
>>
>> Why do it for every command. Even if no one is using it?
>
> Some LLDs already use scsi_get_lba(). They don't know scsi command
> from pc or fs so they can't use scsi_get_lba() now. Well, they can see
> scsi_cmnd->request to know pc or fs but it's layer violation. They
> shouldn't access to the block layer stuff.
>
right, so hide it all under an API that is implemented at the right
level, and protect them. The driver should call a single simple
API the magic will be done at the generic level
if (blk_fs_rq(req))
return blk_rq_pos(req);
else
return scsi_somthing();
>
>> Only drivers/code that actually cares should call this member.
>>
>> It should be easy enough to search for __sector and change them
>> to a function call.
>
> I don't think that calling such function in LLDs is a clean design. We
> set request->__sector for fs requests. Why not for pc requests? Then
> we can use blk_rq_pos() cleanly.
>
Because "fs requests" have a defined blk_rq_pos(). But "pc requests"
don't necessarily have one. Pretending to invent one is stupid and
dangerous. Better keep a -1 for all "pc requests".
scsi LLDs can be pass-through for disks, as well as lots of other
type of devices. They should not assume the role of a disk. The use
of blk_rq_pos() at LLDs is probably wrong in the first place. Unless
it is some kind of scsi emulation driver like scsi_debug.
>
>> This is not accepted, for osd for instance, on the hot path like this.
>> The few users should be fixed.
>
> I'm not sure if this effects the performance notably.
>
> I'll think about something different if James doesn't like the
> approach.
NAK from me
Boaz
next prev parent reply other threads:[~2010-06-02 8:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-02 7:33 [PATCH] scsi: fix scsi_get_lba helper function for pc command FUJITA Tomonori
2010-06-02 8:14 ` Boaz Harrosh
2010-06-02 8:39 ` FUJITA Tomonori
2010-06-02 8:54 ` Boaz Harrosh [this message]
2010-06-02 9:05 ` FUJITA Tomonori
2010-06-02 9:23 ` Boaz Harrosh
2010-06-02 13:13 ` Martin K. Petersen
2010-06-03 10:59 ` FUJITA Tomonori
2010-06-03 11:03 ` Prakash, Sathya
2010-06-02 14:07 ` James Bottomley
2010-06-02 14:55 ` Douglas Gilbert
2010-06-03 11:18 ` FUJITA Tomonori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C061C41.2010104@panasas.com \
--to=bharrosh@panasas.com \
--cc=James.Bottomley@suse.de \
--cc=Sathya.Prakash@lsi.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=jaxboe@fusionio.com \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox