From: Tejun Heo <tj@kernel.org>
To: petkovbb@gmail.com
Cc: petkovbb@googlemail.com, bzolnier@gmail.com, axboe@kernel.dk,
linux-ide@vger.kernel.org,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: Re: [PATCH 12/15] ide-cd: convert to using generic sense request
Date: Sun, 19 Apr 2009 18:28:24 +0900 [thread overview]
Message-ID: <49EAEEB8.10300@kernel.org> (raw)
In-Reply-To: <20090419092254.GB2906@liondog.tnic>
Borislav Petkov wrote:
>> + /*
>> + * Sense is always read into drive->sense_data.
>> + * Copy back if the failed request has its
>> + * sense pointer set.
>> + */
>> + memcpy(failed->sense, sense, 18);
>
> shouldn't this line be:
>
> memcpy(failed->sense, sense, rq->sense);
>
> ?
>
> According to SFF8020i, Section 10.8.20 REQUEST SENSE Command, the sense
> length can be > 18:
It doesn't really matter in this patch. This patch shouldn't change
what number of bytes are considered by ide-cd for sense data. Before
the patch it was 18, so it should remain 18 after the patch.
> "ATAPI CD-ROM Drives shall be capable of returning at least 18 bytes of
> data in response to a REQUEST SENSE command. (...)
>
> Host Computers can determine how much sense data has been returned by
> examining the allocation length parameter in the Command Packet and the
> additional sense length in the sense data. ATAPI CD-ROM Drives shall
> not adjust the additional sense length to reflect truncation if the
> allocation length is less than the sense data available."
>
> So, a possible scenario might be:
>
> We issue a REQUEST_SENSE to a device and it returns more than 18 bytes
> of sense data which should normally fit in the request_sense buffer but
> we only copyback the first 18 bytes. Now, the error handling doesn't
> touch any members behind the 18th byte (sense->asb) but we still subtly
> carry stale data with us resulting in future bugs if one decides to
> touch the additional sense bytes (->asb).
>
> However, is there any reason for copying back the sense bytes at all?
> In other words, does the block layer code need sense data when ending a
> request or is it used only by LLDDs for error handling? Because if I'm
> not missing something, we could just as well use the drive->sense_data
> in the failed->sense case and thus alleviate the need for the copy.
> ide_cd_complete_failed_rq is called on the IRQ path so drive->sense_data
> has to be still valid for the current request is a sense request, no?
>
> As a result and if I'm reading the code correctly, we could simply do
> (pasting the whole function instead of a diff for more clarity) :
>
> static void ide_cd_complete_failed_rq(ide_drive_t *drive, struct request *rq)
> {
> /*
> * For REQ_TYPE_SENSE, "rq->special" points to the original
> * failed request
> */
> struct request *failed = (struct request *)rq->special;
> struct request_sense *sense = &drive->sense_data;
>
> if (failed) {
> if (failed->sense)
> /* Sense is always read into drive->sense_data. */
> failed->sense_len = rq->sense_len;
>
> cdrom_analyze_sense_data(drive, failed, sense);
>
> if (ide_end_rq(drive, failed, -EIO, blk_rq_bytes(failed)))
> BUG();
> } else
> cdrom_analyze_sense_data(drive, NULL, sense);
> }
So, please feel free to submit a separate patch for this. :-)
Thanks.
--
tejun
next prev parent reply other threads:[~2009-04-19 9:28 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-17 9:33 [PATCHSET pata-2.6] ide: rq->buffer, data, special and misc cleanups, take#2 Tejun Heo
2009-04-17 9:33 ` [PATCH 01/15] block: clear req->errors on bio completion only for fs requests Tejun Heo
2009-04-17 9:33 ` [PATCH 02/15] ide-tape: remove back-to-back REQUEST_SENSE detection Tejun Heo
2009-04-17 10:23 ` Borislav Petkov
2009-04-17 10:35 ` Tejun Heo
2009-04-17 10:40 ` Tejun Heo
2009-04-17 11:03 ` Borislav Petkov
2009-04-17 21:12 ` Tejun Heo
2009-04-17 21:27 ` Mark Lord
2009-04-18 19:48 ` Borislav Petkov
2009-04-18 21:39 ` Tejun Heo
2009-04-19 7:28 ` Borislav Petkov
2009-04-19 7:36 ` Tejun Heo
2009-04-18 16:51 ` Bartlomiej Zolnierkiewicz
2009-04-18 21:42 ` Tejun Heo
2009-04-17 9:33 ` [PATCH 03/15] ide: use blk_run_queue() instead of blk_start_queueing() Tejun Heo
2009-04-17 9:33 ` [PATCH 04/15] ide: don't set REQ_SOFTBARRIER Tejun Heo
2009-04-17 9:33 ` [PATCH 05/15] ide kill unused ide_cmd->special Tejun Heo
2009-04-17 9:33 ` [PATCH 06/15] ide-cd: clear sense buffer before issuing request sense Tejun Heo
2009-04-17 9:33 ` [PATCH 07/15] ide-floppy: block pc always uses bio Tejun Heo
2009-04-17 9:33 ` [PATCH 08/15] ide-taskfile: don't abuse rq->buffer Tejun Heo
2009-04-17 9:33 ` [PATCH 09/15] ide-atapi: " Tejun Heo
2009-04-17 9:33 ` [PATCH 10/15] ide-cd: " Tejun Heo
2009-04-17 9:33 ` [PATCH 11/15] ide: add helpers for preparing sense requests Tejun Heo
2009-04-17 9:33 ` [PATCH 12/15] ide-cd: convert to using generic sense request Tejun Heo
2009-04-19 9:22 ` Borislav Petkov
2009-04-19 9:28 ` Tejun Heo [this message]
2009-04-19 9:30 ` Tejun Heo
2009-04-17 9:33 ` [PATCH 13/15] ide-atapi: convert ide-{floppy,tape} to using preallocated sense buffer Tejun Heo
2009-04-17 9:33 ` [PATCH 14/15] ide-cd,atapi: use bio for internal commands Tejun Heo
2009-04-17 9:33 ` [PATCH 15/15] ide-pm: don't abuse rq->data Tejun Heo
2009-04-18 16:32 ` [PATCHSET pata-2.6] ide: rq->buffer, data, special and misc cleanups, take#2 Bartlomiej Zolnierkiewicz
2009-04-18 20:04 ` Borislav Petkov
2009-04-18 21:43 ` Tejun Heo
2009-04-18 22:04 ` [GIT PATCH " Tejun Heo
2009-04-20 11:47 ` Bartlomiej Zolnierkiewicz
2009-04-20 11:59 ` Tejun Heo
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=49EAEEB8.10300@kernel.org \
--to=tj@kernel.org \
--cc=axboe@kernel.dk \
--cc=bzolnier@gmail.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=linux-ide@vger.kernel.org \
--cc=petkovbb@gmail.com \
--cc=petkovbb@googlemail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.