From: Andrew Morton <akpm@osdl.org>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ide write barrier support
Date: Mon, 13 Oct 2003 16:07:35 -0700 [thread overview]
Message-ID: <20031013160735.089df1fb.akpm@osdl.org> (raw)
In-Reply-To: <20031013140858.GU1107@suse.de>
Jens Axboe <axboe@suse.de> wrote:
>
> Hi,
>
> Forward ported and tested today (with the dummy ext3 patch included),
> works for me. Some todo's left, but I thought I'd send it out to gauge
> interest. TODO:
>
> - Detect write cache setting and only issue SYNC_CACHE if write cache is
> enabled (not a biggy, all drives ship with it enabled)
>
> - Toggle flush support on hdparm -W0/1
>
> - Various small bits I can't remember right now
>
> ...
> + set_bit(BH_Ordered, &bh->b_state);
We have standard macros for generating standard buffer_head operations, so
this can become
set_buffer_ordered(bh);
See appended patch.
> --- 1.40/fs/jbd/commit.c Fri Aug 1 12:02:20 2003
> +++ edited/fs/jbd/commit.c Mon Oct 13 10:17:28 2003
> @@ -474,7 +474,9 @@
> clear_buffer_dirty(bh);
> set_buffer_uptodate(bh);
> bh->b_end_io = journal_end_buffer_io_sync;
> + set_bit(BH_Ordered, &bh->b_state);
> submit_bh(WRITE, bh);
> + clear_bit(BH_Ordered, &bh->b_state);
> }
> cond_resched();
Why does the ordering go here? I'd have thought that we only need to
enforce ordering around the commit block.
Touching the bh here after submitting it may be racy: may need to take an
extra ref against the bh to prevent it from disappearing. I need to look
at it more closely.
> @@ -344,6 +348,8 @@
> unsigned long seg_boundary_mask;
> unsigned int dma_alignment;
>
> + unsigned short ordered;
> +
> struct blk_queue_tag *queue_tags;
>
> atomic_t refcnt;
shorts-in-structs worry me. If the CPU implements a write-to-short as a
word-sized RMW and the compiler decides to align or pack the short into a
less-than-wored-sized storage space then a write-to-short could stomp on a
neighbouring member.
I doubt if it can happen, but if so, I'd be interested in knowing what guarantees it.
> ...
> unsigned vdma : 1; /* 1=doing PIO over DMA 0=doing normal DMA */
> + unsigned doing_barrier : 1; /* state, 1=currently doing flush */
Similarly, I suspect that bitfields like this need locking. If the CPU
implements a write-to-bitfield as a non-buslocked RMW it can stomp on
neighbouring bitfields in the same word.
25-akpm/fs/buffer.c | 4 ++--
25-akpm/fs/jbd/commit.c | 4 ++--
25-akpm/include/linux/buffer_head.h | 3 ++-
3 files changed, 6 insertions(+), 5 deletions(-)
diff -puN fs/buffer.c~ide-write-barrier-support-tidies fs/buffer.c
--- 25/fs/buffer.c~ide-write-barrier-support-tidies Mon Oct 13 15:53:56 2003
+++ 25-akpm/fs/buffer.c Mon Oct 13 15:53:56 2003
@@ -2655,7 +2655,7 @@ int submit_bh(int rw, struct buffer_head
BUG_ON(!bh->b_end_io);
if (rw == WRITEBARRIER) {
- set_bit(BH_Ordered, &bh->b_state);
+ set_buffer_ordered(bh);
rw = WRITE;
}
@@ -2666,7 +2666,7 @@ int submit_bh(int rw, struct buffer_head
if (rw == READ && buffer_dirty(bh))
buffer_error();
- if (test_bit(BH_Ordered, &bh->b_state) && (rw == WRITE))
+ if (buffer_ordered(bh) && (rw == WRITE))
rw = WRITEBARRIER;
/* Only clear out a write error when rewriting */
diff -puN fs/jbd/commit.c~ide-write-barrier-support-tidies fs/jbd/commit.c
--- 25/fs/jbd/commit.c~ide-write-barrier-support-tidies Mon Oct 13 15:53:56 2003
+++ 25-akpm/fs/jbd/commit.c Mon Oct 13 15:53:56 2003
@@ -474,9 +474,9 @@ start_journal_io:
clear_buffer_dirty(bh);
set_buffer_uptodate(bh);
bh->b_end_io = journal_end_buffer_io_sync;
- set_bit(BH_Ordered, &bh->b_state);
+ set_buffer_ordered(bh);
submit_bh(WRITE, bh);
- clear_bit(BH_Ordered, &bh->b_state);
+ clear_buffer_ordered(bh)
}
cond_resched();
diff -puN include/linux/buffer_head.h~ide-write-barrier-support-tidies include/linux/buffer_head.h
--- 25/include/linux/buffer_head.h~ide-write-barrier-support-tidies Mon Oct 13 15:53:56 2003
+++ 25-akpm/include/linux/buffer_head.h Mon Oct 13 15:53:56 2003
@@ -118,7 +118,8 @@ BUFFER_FNS(Async_Read, async_read)
BUFFER_FNS(Async_Write, async_write)
BUFFER_FNS(Delay, delay)
BUFFER_FNS(Boundary, boundary)
-BUFFER_FNS(Write_EIO,write_io_error)
+BUFFER_FNS(Write_EIO, write_io_error)
+BUFFER_FNS(Ordered, ordered)
#define bh_offset(bh) ((unsigned long)(bh)->b_data & ~PAGE_MASK)
#define touch_buffer(bh) mark_page_accessed(bh->b_page)
_
next prev parent reply other threads:[~2003-10-13 23:07 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-13 14:08 Jens Axboe
2003-10-13 15:23 ` Jeff Garzik
2003-10-13 15:35 ` Jens Axboe
2003-10-13 15:37 ` Jens Axboe
2003-10-13 22:39 ` Matthias Andree
2003-10-14 0:16 ` Jeff Garzik
2003-10-16 10:36 ` Jens Axboe
2003-10-16 10:46 ` Jeff Garzik
2003-10-16 10:48 ` Jens Axboe
2003-10-13 23:07 ` Andrew Morton [this message]
2003-10-14 6:48 ` Jens Axboe
2003-10-15 3:40 ` Greg Stark
2003-10-16 7:10 ` Jens Axboe
2003-10-20 17:10 ` Daniel Phillips
2003-10-20 19:56 ` Jens Axboe
2003-10-20 23:46 ` Daniel Phillips
2003-10-21 5:40 ` Jens Axboe
2003-10-23 16:22 ` Daniel Phillips
2003-10-23 16:23 ` Jens Axboe
2003-10-23 17:20 ` Daniel Phillips
2003-10-23 23:21 ` Nick Piggin
2003-10-26 21:06 ` Daniel Phillips
2003-10-27 10:29 ` Lars Marowsky-Bree
2003-10-27 21:35 ` Daniel Phillips
2003-10-24 9:36 ` Helge Hafting
2003-10-26 15:38 ` Daniel Phillips
2003-10-16 16:51 Mudama, Eric
2003-10-16 20:43 ` Greg Stark
2003-10-17 6:44 ` Jens Axboe
2003-10-17 6:46 ` Jens Axboe
2003-10-16 20:51 Mudama, Eric
2003-10-17 6:48 ` Jens Axboe
2003-10-17 16:07 Mudama, Eric
2003-10-17 18:08 ` Jens Axboe
2003-10-17 17:59 Manfred Spraul
2003-10-17 18:06 ` Jens Axboe
2003-10-21 0:47 ` Matthias Andree
2003-10-17 18:42 Mudama, Eric
[not found] <IXzh.61g.5@gated-at.bofh.it>
2003-10-21 19:24 ` Anton Ertl
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=20031013160735.089df1fb.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=axboe@suse.de \
--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
Powered by JetHome