From: Christophe Saout <christophe@saout.de>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Linux IDE <linux-ide@vger.kernel.org>,
Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Subject: Possibly wrong BIO usage in ide_multwrite
Date: Thu, 01 Jan 2004 18:18:27 +0100 [thread overview]
Message-ID: <1072977507.4170.14.camel@leto.cs.pocnet.net> (raw)
Hi!
I was just investigating where bio->bi_idx gets modified in the kernel.
I found these lines in ide-disk.c in ide_multwrite (DMA off, TASKFILE_IO
off):
> if (++bio->bi_idx >= bio->bi_vcnt) {
> bio->bi_idx = 0;
> bio = bio->bi_next;
> }
(rq->bio also gets changed but it's protected by the scratch buffer)
I think changing the bi_idx here is dangerous because
end_that_request_first needs this value to be unchanged because it
tracks the progress of the bio processing and updates bi_idx itself.
And bio->bi_idx = 0 is probably wrong because the bio can be submitted
with bio->bi_idx > 0 (if the bio was splitted and there are clones that
share the bio_vec array, like raid or device-mapper code).
If it really needs to play with bi_idx itself care should be taken to
reset bi_idx to the original value, not to zero.
I wasn't able to trigger a problem though, I don't know why exactly,
perhaps there are paths in __end_that_request_first that are not
interested in bi_dx. I still think there is something wrong with it.
next reply other threads:[~2004-01-01 17:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-01 17:18 Christophe Saout [this message]
2004-01-01 11:27 ` Bartlomiej Zolnierkiewicz
2004-01-02 3:20 ` Christophe Saout
2004-01-02 4:43 ` CPRM ?? " Andre Hedrick
2004-01-02 11:30 ` Jens Axboe
2004-01-03 7:53 ` Andre Hedrick
2004-01-03 10:57 ` Jens Axboe
2004-01-03 19:55 ` Andre Hedrick
2004-01-04 10:42 ` Jens Axboe
2004-01-04 22:02 ` Andre Hedrick
2004-01-05 10:17 ` Jens Axboe
2004-01-02 12:45 ` Christophe Saout
2004-01-03 7:51 ` Andre Hedrick
2004-01-03 22:02 ` Bartlomiej Zolnierkiewicz
2004-01-04 17:30 ` Christophe Saout
2004-01-05 16:12 ` Bartlomiej Zolnierkiewicz
2004-01-05 16:48 ` Christophe Saout
2004-01-05 19:37 ` Frederik Deweerdt
2004-01-05 20:13 ` Bartlomiej Zolnierkiewicz
2004-01-05 3:52 ` Christophe Saout
2004-01-05 17:08 ` Bartlomiej Zolnierkiewicz
2004-01-05 22:51 ` Christophe Saout
2004-01-05 23:59 ` Bartlomiej Zolnierkiewicz
2004-01-06 11:33 ` Christophe Saout
2004-01-06 14:38 ` Bartlomiej Zolnierkiewicz
2004-01-06 15:21 ` Christophe Saout
2004-01-05 4:03 ` Christophe Saout
2004-01-05 16:47 ` Bartlomiej Zolnierkiewicz
2004-01-05 16:49 ` Jens Axboe
2004-01-05 17:13 ` Bartlomiej Zolnierkiewicz
2004-01-05 18:16 ` Jens Axboe
2004-01-05 18:27 ` Bartlomiej Zolnierkiewicz
2004-01-01 23:02 ` Andre Hedrick
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=1072977507.4170.14.camel@leto.cs.pocnet.net \
--to=christophe@saout.de \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®