From: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
To: Alasdair Kergon <agk@redhat.com>, Mikulas Patocka <mpatocka@redhat.com>
Cc: device-mapper development <dm-devel@redhat.com>
Subject: possible regression by the barrier patch in 2.6.30-rc2
Date: Fri, 17 Apr 2009 13:57:02 +0900 [thread overview]
Message-ID: <49E80C1E.1040905@ct.jp.nec.com> (raw)
Hi Alasdair, Mikulas,
I have reviewed the barrier patch-set and found some possible
regression from 2.6.29 in dm-implement-basic-barrier-support.patch:
http://git.kernel.org/?p=linux/kernel/git/agk/linux-2.6-dm.git;a=commitdiff;h=af7e466a1acededbc10beaba9eec8531d561c566;hp=92c639021ca6e962645114f02e356e7feb131d0b
Please take a look and consider to fix them (I don't have enough
time to make patches now unfortunately).
1. The semantics of flush suspend has been changed.
For flush suspend, dm used to flush all bios submitted before
the invocation of suspend.
But now, dm may not flush such bios:
1. submit a barrier => set QUEUE_IO_TO_THREAD flag and kick kdmflush
2. submit some bios => queued into md->defered if the barrier
is still in progress
3. invoke suspend => set BLOCK_IO_FOR_SUSPEND flag
=> kdmflush stops flushing md->defered
=> complete suspend with holding the bios
Then, we could expect bios submitted at 2 to be flushed, but
we can't expect that any more now.
I think no suspend user wants this semantics change.
Is it intended change or just a bug?
2. Possible invalid pointer reference problem again.
Milan had fixed a possible NULL pointer reference in 2.6.29 by
http://git.kernel.org/?p=linux/kernel/git/agk/linux-2.6-dm.git;a=commitdiff;h=b35f8caa0890169000fec22902290d9a15274cbd;hp=b2174eebd1fadb76454dad09a1dacbc17081e6b0.
His patch means that we must not touch md after calling bio_endio()
in dec_pending() because the bio submitter can close/free the md
once bio_endio() is called.
The barrier patch breaks his fix and we get the possible invalid
pointer reference problem again.
The problematic part is below and free_io() should be called
before bio_endio().
----------------------------------------------------------------------
- free_io(md, io);
+ if (bio_barrier(bio)) {
+ /*
+ * There can be just one barrier request so we use
+ * a per-device variable for error reporting.
+ * Note that you can't touch the bio after end_io_acct
+ */
+ md->barrier_error = io_error;
+ end_io_acct(io);
+ } else {
+ end_io_acct(io);
- if (io_error != DM_ENDIO_REQUEUE) {
- trace_block_bio_complete(md->queue, bio);
+ if (io_error != DM_ENDIO_REQUEUE) {
+ trace_block_bio_complete(md->queue, bio);
- bio_endio(bio, io_error);
+ bio_endio(bio, io_error);
+ }
}
+
+ free_io(md, io);
----------------------------------------------------------------------
Thanks,
Kiyoshi Ueda
next reply other threads:[~2009-04-17 4:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-17 4:57 Kiyoshi Ueda [this message]
2009-04-17 13:22 ` possible regression by the barrier patch in 2.6.30-rc2 Alasdair G Kergon
2009-04-20 4:27 ` Kiyoshi Ueda
2009-04-20 6:20 ` Mikulas Patocka
2009-10-28 15:21 ` Alasdair G Kergon
2009-11-05 1:53 ` Mikulas Patocka
2009-11-05 2:02 ` Mikulas Patocka
2009-11-06 2:42 ` snapshot of mirror (was: possible regression by the barrier patch in 2.6.30-rc2) Mikulas Patocka
2009-11-05 2:04 ` Re: possible regression by the barrier patch in 2.6.30-rc2 Alasdair G Kergon
2009-11-06 7:34 ` Kiyoshi Ueda
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=49E80C1E.1040905@ct.jp.nec.com \
--to=k-ueda@ct.jp.nec.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=mpatocka@redhat.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.