From: Prarit Bhargava <prarit@sgi.com>
To: Jens Axboe <axboe@suse.de>
Cc: linux-ide@vger.kernel.org
Subject: Re: [PATCH]: Fix erroneous rq->buffer = NULL in ide-io.c:ide_dma_timeout_retry
Date: Tue, 04 Jan 2005 15:49:22 -0500 [thread overview]
Message-ID: <41DB0152.1030504@sgi.com> (raw)
In-Reply-To: <20050104190403.GW2825@suse.de>
Thanks Jens,
I can your issue of correcting the position of the buffer. I've tested
with this patch and do not hit the BUG().
P.
--- linux-2.5.orig/drivers/ide/ide-io.c 2005-01-04 15:45:17.000000000 -0500
+++ linux-2.5/drivers/ide/ide-io.c 2005-01-04 15:45:27.000000000 -0500
@@ -1205,21 +1205,21 @@
HWGROUP(drive)->rq = NULL;
rq->errors = 0;
if (!rq->bio)
goto out;
rq->sector = rq->bio->bi_sector;
rq->current_nr_sectors = bio_iovec(rq->bio)->bv_len >> 9;
rq->hard_cur_sectors = rq->current_nr_sectors;
- rq->buffer = NULL;
+ rq->buffer = bio_data(rq->bio);
out:
return ret;
}
/**
* ide_timer_expiry - handle lack of an IDE interrupt
* @data: timer callback magic (hwgroup)
*
* An IDE command has timed out before the expected drive return
* occurred. At this point we attempt to clean up the current
Jens Axboe wrote:
>On Tue, Jan 04 2005, Prarit Bhargava wrote:
>
>
>>Hello,
>>
>>I have found an IDE bug in the IDE DMA timeout function,
>>ide-io.c: ide_dma_timeout_retry erroneously sets the first_rq->buffer =
>>NULL.
>>
>>ide_dma_timeout_retry will be called whenever a command is issued, times
>>out,
>>and the drive is waiting for DMA. The function, ide_dma_timeout_retry,
>>un-busies the hardware group and attempts to clean up the current request.
>>As part of this cleanup the current failed first_rq->buffer is set to NULL.
>>
>>However, as part of this retry process first_rq is retried up to 3 times in
>>PIO mode (with DMA off).
>>
>>During the retry, ide-cd.c: cdrom_start_read is called, which in turn
>>calls, restore_request. restore_request references first_rq->buffer
>>(which is
>>NULL) in order to calculate hard_cur_sectors, hard_nr_sectors, etc.
>>
>>ie) All of these values will be bogus because of the first_rq->buffer =
>>NULL.
>>
>>This request will fail and the IDE core will enter error handling. IDE
>>core generates a new request, sense_rq, in order to request sense. Attached
>>this request is a back pointer to the original first_rq request.
>>
>> ie) sense_rq->buffer = first_rq
>>
>>Eventually ide-cd.c:cdrom_end_request is called on sense_rq, and
>>then ide-io.c:ide_end_dequeued_request is called on first_rq. Note
>>that ide_end_dequeued_request is called with the bogus values from first_rq.
>>
>>The return value essentially depends on the return value of
>>ll_rw_blk.c:__end_that_request_first. The arguements to this function
>>include
>>nr_sectors, which as noted above, is bogus.
>>
>>This leads to a return of 1 from ll_rw_blk.c:__end_that_request_first
>>which eventually leads to an erroneous call to BUG() in
>>ide-cd.c:cdrom_end_request.
>>
>>I have forced this issue to occur by modifying code to effectively DMA
>>timeout on CDROM accesses on i686 and ia64 platforms. I hit the bug
>>100% of the time.
>>
>>It appears that the modification should be to rid the ide-io.c code of
>>the rq->buffer = NULL call.
>>
>>Patch is based off of latest BK linux-2.5 as of 2005-01-04 09:00.
>>
>>--- linux-2.5.orig/drivers/ide/ide-io.c 2005-01-04 09:31:45.000000000 -0500
>>+++ linux-2.5/drivers/ide/ide-io.c 2005-01-04 09:32:23.000000000 -0500
>>@@ -1205,21 +1205,20 @@
>> HWGROUP(drive)->rq = NULL;
>>
>> rq->errors = 0;
>>
>> if (!rq->bio)
>> goto out;
>>
>> rq->sector = rq->bio->bi_sector;
>> rq->current_nr_sectors = bio_iovec(rq->bio)->bv_len >> 9;
>> rq->hard_cur_sectors = rq->current_nr_sectors;
>>- rq->buffer = NULL;
>>
>>
>
>Probably safer to do
>
> rq->buffer = bio_data(rq->bio);
>
>
>
prev parent reply other threads:[~2005-01-04 20:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-04 14:47 [PATCH]: Fix erroneous rq->buffer = NULL in ide-io.c:ide_dma_timeout_retry Prarit Bhargava
2005-01-04 19:04 ` Jens Axboe
2005-01-04 20:49 ` Prarit Bhargava [this message]
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=41DB0152.1030504@sgi.com \
--to=prarit@sgi.com \
--cc=axboe@suse.de \
--cc=linux-ide@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;
as well as URLs for NNTP newsgroup(s).