mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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)

_


  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