[PATCH v5] add barriers to buffer functions

Mikulas Patocka posted 1 patch 3 years, 8 months ago
[PATCH v5] add barriers to buffer functions
Posted by Mikulas Patocka 3 years, 8 months ago


On Fri, 5 Aug 2022, Matthew Wilcox wrote:

> On Mon, Aug 01, 2022 at 11:01:40AM -0400, Mikulas Patocka wrote:
> > 
> > In most cases, the buffer is set uptodate while it is locked, so that 
> > there is no race on the uptodate flag (the race exists on the locked 
> > flag). Are there any cases where the uptodate flag is modified on unlocked 
> > buffer, so that it needs special treatment too?
> 
> I think you misunderstand the purpose of locked/uptodate.  At least
> for pages, the lock flag does not order access to the data in the page.
> Indeed, the contents of the page can be changed while you hold the lock.
> But the uptodate flag does order access to the data.  At the point where
> you can observe the uptodate flag set, you know the contents of the page
> have been completely read from storage.  And you don't need to hold the
> lock to check the uptodate flag.  So this is wrong:
> 
> 	buffer_lock()
> 	*data = 0x12345678;
> 	buffer_set_uptodate_not_ordered()
> 	buffer_unlock_ordered()
> 
> because a reader can do:
> 
> 	while (!buffer_test_uptodate()) {
> 		buffer_lock();
> 		buffer_unlock();
> 	}
> 	x = *data;
> 
> and get x != 0x12345678 because the compiler can move the
> buffer_set_uptodate_not_ordered() before the store to *data.

Thanks for explanation. Would you like this patch?



From: Mikulas Patocka <mpatocks@redhat.com>

Let's have a look at this piece of code in __bread_slow:
	get_bh(bh);
	bh->b_end_io = end_buffer_read_sync;
	submit_bh(REQ_OP_READ, 0, bh);
	wait_on_buffer(bh);
	if (buffer_uptodate(bh))
		return bh;
Neither wait_on_buffer nor buffer_uptodate contain any memory barrier.
Consequently, if someone calls sb_bread and then reads the buffer data,
the read of buffer data may be executed before wait_on_buffer(bh) on
architectures with weak memory ordering and it may return invalid data.

Fix this bug by adding a write memory barrier to set_buffer_uptodate and a
read memory barrier to buffer_uptodate (in the same way as
folio_test_uptodate and folio_mark_uptodate).

We also add a barrier to buffer_locked - it pairs with a barrier in
unlock_buffer.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org

Index: linux-2.6/include/linux/buffer_head.h
===================================================================
--- linux-2.6.orig/include/linux/buffer_head.h
+++ linux-2.6/include/linux/buffer_head.h
@@ -117,10 +117,8 @@ static __always_inline int test_clear_bu
  * of the form "mark_buffer_foo()".  These are higher-level functions which
  * do something in addition to setting a b_state bit.
  */
-BUFFER_FNS(Uptodate, uptodate)
 BUFFER_FNS(Dirty, dirty)
 TAS_BUFFER_FNS(Dirty, dirty)
-BUFFER_FNS(Lock, locked)
 BUFFER_FNS(Req, req)
 TAS_BUFFER_FNS(Req, req)
 BUFFER_FNS(Mapped, mapped)
@@ -135,6 +133,49 @@ BUFFER_FNS(Meta, meta)
 BUFFER_FNS(Prio, prio)
 BUFFER_FNS(Defer_Completion, defer_completion)
 
+static __always_inline void set_buffer_uptodate(struct buffer_head *bh)
+{
+	/*
+	 * make it consistent with folio_mark_uptodate
+	 * pairs with smp_acquire__after_ctrl_dep in buffer_uptodate
+	 */
+	smp_wmb();
+	set_bit(BH_Uptodate, &bh->b_state);
+}
+
+static __always_inline void clear_buffer_uptodate(struct buffer_head *bh)
+{
+	clear_bit(BH_Uptodate, &bh->b_state);
+}
+
+static __always_inline int buffer_uptodate(const struct buffer_head *bh)
+{
+	bool ret = test_bit(BH_Uptodate, &bh->b_state);
+	/*
+	 * make it consistent with folio_test_uptodate
+	 * pairs with smp_wmb in set_buffer_uptodate
+	 */
+	if (ret)
+		smp_acquire__after_ctrl_dep();
+	return ret;
+}
+
+static __always_inline void set_buffer_locked(struct buffer_head *bh)
+{
+	set_bit(BH_Lock, &bh->b_state);
+}
+
+static __always_inline int buffer_locked(const struct buffer_head *bh)
+{
+	bool ret = test_bit(BH_Lock, &bh->b_state);
+	/*
+	 * pairs with smp_mb__after_atomic in unlock_buffer
+	 */
+	if (!ret)
+		smp_acquire__after_ctrl_dep();
+	return ret;
+}
+
 #define bh_offset(bh)		((unsigned long)(bh)->b_data & ~PAGE_MASK)
 
 /* If we *know* page->private refers to buffer_heads */
Re: [PATCH v5] add barriers to buffer functions
Posted by Matthew Wilcox 3 years, 8 months ago
On Sun, Aug 07, 2022 at 07:37:22AM -0400, Mikulas Patocka wrote:
> @@ -135,6 +133,49 @@ BUFFER_FNS(Meta, meta)
>  BUFFER_FNS(Prio, prio)
>  BUFFER_FNS(Defer_Completion, defer_completion)
>  
> +static __always_inline void set_buffer_uptodate(struct buffer_head *bh)
> +{
> +	/*
> +	 * make it consistent with folio_mark_uptodate
> +	 * pairs with smp_acquire__after_ctrl_dep in buffer_uptodate
> +	 */
> +	smp_wmb();
> +	set_bit(BH_Uptodate, &bh->b_state);
> +}
> +
> +static __always_inline void clear_buffer_uptodate(struct buffer_head *bh)
> +{
> +	clear_bit(BH_Uptodate, &bh->b_state);
> +}
> +
> +static __always_inline int buffer_uptodate(const struct buffer_head *bh)
> +{
> +	bool ret = test_bit(BH_Uptodate, &bh->b_state);
> +	/*
> +	 * make it consistent with folio_test_uptodate
> +	 * pairs with smp_wmb in set_buffer_uptodate
> +	 */
> +	if (ret)
> +		smp_acquire__after_ctrl_dep();
> +	return ret;
> +}

This all works for me.  While we have the experts paying attention,
would it be better to do

	return smp_load_acquire(&bh->b_state) & (1L << BH_Uptodate) > 0;

> +static __always_inline void set_buffer_locked(struct buffer_head *bh)
> +{
> +	set_bit(BH_Lock, &bh->b_state);
> +}
> +
> +static __always_inline int buffer_locked(const struct buffer_head *bh)
> +{
> +	bool ret = test_bit(BH_Lock, &bh->b_state);
> +	/*
> +	 * pairs with smp_mb__after_atomic in unlock_buffer
> +	 */
> +	if (!ret)
> +		smp_acquire__after_ctrl_dep();
> +	return ret;
> +}

Are there places that think that lock/unlock buffer implies a memory
barrier?
Re: [PATCH v5] add barriers to buffer functions
Posted by Mikulas Patocka 3 years, 8 months ago

On Sun, 7 Aug 2022, Matthew Wilcox wrote:

> On Sun, Aug 07, 2022 at 07:37:22AM -0400, Mikulas Patocka wrote:
> > @@ -135,6 +133,49 @@ BUFFER_FNS(Meta, meta)
> >  BUFFER_FNS(Prio, prio)
> >  BUFFER_FNS(Defer_Completion, defer_completion)
> >  
> > +static __always_inline void set_buffer_uptodate(struct buffer_head *bh)
> > +{
> > +	/*
> > +	 * make it consistent with folio_mark_uptodate
> > +	 * pairs with smp_acquire__after_ctrl_dep in buffer_uptodate
> > +	 */
> > +	smp_wmb();
> > +	set_bit(BH_Uptodate, &bh->b_state);
> > +}
> > +
> > +static __always_inline void clear_buffer_uptodate(struct buffer_head *bh)
> > +{
> > +	clear_bit(BH_Uptodate, &bh->b_state);
> > +}
> > +
> > +static __always_inline int buffer_uptodate(const struct buffer_head *bh)
> > +{
> > +	bool ret = test_bit(BH_Uptodate, &bh->b_state);
> > +	/*
> > +	 * make it consistent with folio_test_uptodate
> > +	 * pairs with smp_wmb in set_buffer_uptodate
> > +	 */
> > +	if (ret)
> > +		smp_acquire__after_ctrl_dep();
> > +	return ret;
> > +}
> 
> This all works for me.  While we have the experts paying attention,
> would it be better to do
> 
> 	return smp_load_acquire(&bh->b_state) & (1L << BH_Uptodate) > 0;

Yes, it may be nicer.

> > +static __always_inline void set_buffer_locked(struct buffer_head *bh)
> > +{
> > +	set_bit(BH_Lock, &bh->b_state);
> > +}
> > +
> > +static __always_inline int buffer_locked(const struct buffer_head *bh)
> > +{
> > +	bool ret = test_bit(BH_Lock, &bh->b_state);
> > +	/*
> > +	 * pairs with smp_mb__after_atomic in unlock_buffer
> > +	 */
> > +	if (!ret)
> > +		smp_acquire__after_ctrl_dep();
> > +	return ret;
> > +}
> 
> Are there places that think that lock/unlock buffer implies a memory
> barrier?

There's this in fs/reiserfs:

if (!buffer_dirty(bh) && !buffer_locked(bh)) {
	reiserfs_free_jh(bh); <--- this could be moved before buffer_locked


if (buffer_locked((journal->j_header_bh))) {
	...
}
journal->j_last_flush_trans_id = trans_id;
journal->j_first_unflushed_offset = offset;
jh = (struct reiserfs_journal_header *)(journal->j_header_bh->b_data); <--- this could be moved before buffer_locked

Mikulas
Re: [PATCH v5] add barriers to buffer functions
Posted by Matthew Wilcox 3 years, 8 months ago
On Mon, Aug 08, 2022 at 10:26:10AM -0400, Mikulas Patocka wrote:
> On Sun, 7 Aug 2022, Matthew Wilcox wrote:
> > > +static __always_inline void set_buffer_locked(struct buffer_head *bh)
> > > +{
> > > +	set_bit(BH_Lock, &bh->b_state);
> > > +}
> > > +
> > > +static __always_inline int buffer_locked(const struct buffer_head *bh)
> > > +{
> > > +	bool ret = test_bit(BH_Lock, &bh->b_state);
> > > +	/*
> > > +	 * pairs with smp_mb__after_atomic in unlock_buffer
> > > +	 */
> > > +	if (!ret)
> > > +		smp_acquire__after_ctrl_dep();
> > > +	return ret;
> > > +}
> > 
> > Are there places that think that lock/unlock buffer implies a memory
> > barrier?
> 
> There's this in fs/reiserfs:
> 
> if (!buffer_dirty(bh) && !buffer_locked(bh)) {
> 	reiserfs_free_jh(bh); <--- this could be moved before buffer_locked

It might be better to think of buffer_locked() as
buffer_someone_has_exclusive_access().  I can't see the problem with
moving the reads in reiserfs_free_jh() before the read of buffer_locked.

> if (buffer_locked((journal->j_header_bh))) {
> 	...
> }
> journal->j_last_flush_trans_id = trans_id;
> journal->j_first_unflushed_offset = offset;
> jh = (struct reiserfs_journal_header *)(journal->j_header_bh->b_data); <--- this could be moved before buffer_locked

I don't think b_data is going to be changed while someone else holds
the buffer locked.  That's initialised by set_bh_page(), which is an
initialisation-time thing, before the BH is visible to any other thread.
Re: [PATCH v5] add barriers to buffer functions
Posted by Mikulas Patocka 3 years, 8 months ago

On Mon, 8 Aug 2022, Matthew Wilcox wrote:

> On Mon, Aug 08, 2022 at 10:26:10AM -0400, Mikulas Patocka wrote:
> > On Sun, 7 Aug 2022, Matthew Wilcox wrote:
> > > > +static __always_inline void set_buffer_locked(struct buffer_head *bh)
> > > > +{
> > > > +	set_bit(BH_Lock, &bh->b_state);
> > > > +}
> > > > +
> > > > +static __always_inline int buffer_locked(const struct buffer_head *bh)
> > > > +{
> > > > +	bool ret = test_bit(BH_Lock, &bh->b_state);
> > > > +	/*
> > > > +	 * pairs with smp_mb__after_atomic in unlock_buffer
> > > > +	 */
> > > > +	if (!ret)
> > > > +		smp_acquire__after_ctrl_dep();
> > > > +	return ret;
> > > > +}
> > > 
> > > Are there places that think that lock/unlock buffer implies a memory
> > > barrier?
> > 
> > There's this in fs/reiserfs:
> > 
> > if (!buffer_dirty(bh) && !buffer_locked(bh)) {
> > 	reiserfs_free_jh(bh); <--- this could be moved before buffer_locked
> 
> It might be better to think of buffer_locked() as
> buffer_someone_has_exclusive_access().  I can't see the problem with
> moving the reads in reiserfs_free_jh() before the read of buffer_locked.
> 
> > if (buffer_locked((journal->j_header_bh))) {
> > 	...
> > }
> > journal->j_last_flush_trans_id = trans_id;
> > journal->j_first_unflushed_offset = offset;
> > jh = (struct reiserfs_journal_header *)(journal->j_header_bh->b_data); <--- this could be moved before buffer_locked
> 
> I don't think b_data is going to be changed while someone else holds
> the buffer locked.  That's initialised by set_bh_page(), which is an
> initialisation-time thing, before the BH is visible to any other thread.

So, do you think that we don't need a barrier in buffer_locked()?


There is also this (where the BUG_ON(!buffer_uptodate(bh)) saves it).
                if (buffer_locked(bh)) {
                        int depth;
                        PROC_INFO_INC(sb, scan_bitmap.wait);
                        depth = reiserfs_write_unlock_nested(sb);
                        __wait_on_buffer(bh);
                        reiserfs_write_lock_nested(sb, depth);
                }
                BUG_ON(!buffer_uptodate(bh));
                BUG_ON(atomic_read(&bh->b_count) == 0);

                if (info->free_count == UINT_MAX)
                        reiserfs_cache_bitmap_metadata(sb, bh, info); <--- this could be moved before buffer_locked if there were no BUG_ONs

Mikulas
Re: [PATCH v5] add barriers to buffer functions
Posted by Matthew Wilcox 3 years, 8 months ago
On Mon, Aug 08, 2022 at 10:57:45AM -0400, Mikulas Patocka wrote:
> On Mon, 8 Aug 2022, Matthew Wilcox wrote:
> 
> > On Mon, Aug 08, 2022 at 10:26:10AM -0400, Mikulas Patocka wrote:
> > > On Sun, 7 Aug 2022, Matthew Wilcox wrote:
> > > > > +static __always_inline void set_buffer_locked(struct buffer_head *bh)
> > > > > +{
> > > > > +	set_bit(BH_Lock, &bh->b_state);
> > > > > +}
> > > > > +
> > > > > +static __always_inline int buffer_locked(const struct buffer_head *bh)
> > > > > +{
> > > > > +	bool ret = test_bit(BH_Lock, &bh->b_state);
> > > > > +	/*
> > > > > +	 * pairs with smp_mb__after_atomic in unlock_buffer
> > > > > +	 */
> > > > > +	if (!ret)
> > > > > +		smp_acquire__after_ctrl_dep();
> > > > > +	return ret;
> > > > > +}
> > > > 
> > > > Are there places that think that lock/unlock buffer implies a memory
> > > > barrier?
> > > 
> > > There's this in fs/reiserfs:
> > > 
> > > if (!buffer_dirty(bh) && !buffer_locked(bh)) {
> > > 	reiserfs_free_jh(bh); <--- this could be moved before buffer_locked
> > 
> > It might be better to think of buffer_locked() as
> > buffer_someone_has_exclusive_access().  I can't see the problem with
> > moving the reads in reiserfs_free_jh() before the read of buffer_locked.
> > 
> > > if (buffer_locked((journal->j_header_bh))) {
> > > 	...
> > > }
> > > journal->j_last_flush_trans_id = trans_id;
> > > journal->j_first_unflushed_offset = offset;
> > > jh = (struct reiserfs_journal_header *)(journal->j_header_bh->b_data); <--- this could be moved before buffer_locked
> > 
> > I don't think b_data is going to be changed while someone else holds
> > the buffer locked.  That's initialised by set_bh_page(), which is an
> > initialisation-time thing, before the BH is visible to any other thread.
> 
> So, do you think that we don't need a barrier in buffer_locked()?

That's my feeling.  Of course, you might not be the only one confused,
and if fs authors in general have made the mistake of thinking that
buffer_locked is serialising, then it might be better to live up to
that expectation.

> There is also this (where the BUG_ON(!buffer_uptodate(bh)) saves it).
>                 if (buffer_locked(bh)) {
>                         int depth;
>                         PROC_INFO_INC(sb, scan_bitmap.wait);
>                         depth = reiserfs_write_unlock_nested(sb);
>                         __wait_on_buffer(bh);
>                         reiserfs_write_lock_nested(sb, depth);
>                 }
>                 BUG_ON(!buffer_uptodate(bh));
>                 BUG_ON(atomic_read(&bh->b_count) == 0);
> 
>                 if (info->free_count == UINT_MAX)
>                         reiserfs_cache_bitmap_metadata(sb, bh, info); <--- this could be moved before buffer_locked if there were no BUG_ONs

It could be moved before buffer_locked(), but I don't see the harm in
that.  Look at how reiserfs_read_bitmap_block() gets the bh:

        bh = sb_bread(sb, block);

__bread_gfp() has either already read the buffer (and it's uptodate),
in which case it returns it.  Or it calls __bread_slow() which will do
the read and check uptodate before returning it.  I wouldn't be surprised
to find that this buffer_locked() check is actually dead code, but I have
no desire to dive into reiserfs far enough to find out whether it's dead
code or not.
[PATCH v6] add barriers to buffer_uptodate and set_buffer_uptodate
Posted by Mikulas Patocka 3 years, 8 months ago


On Mon, 8 Aug 2022, Matthew Wilcox wrote:

> On Mon, Aug 08, 2022 at 10:57:45AM -0400, Mikulas Patocka wrote:
> > On Mon, 8 Aug 2022, Matthew Wilcox wrote:
> > 
> > > On Mon, Aug 08, 2022 at 10:26:10AM -0400, Mikulas Patocka wrote:
> > > > On Sun, 7 Aug 2022, Matthew Wilcox wrote:
> > > > > > +static __always_inline void set_buffer_locked(struct buffer_head *bh)
> > > > > > +{
> > > > > > +	set_bit(BH_Lock, &bh->b_state);
> > > > > > +}
> > > > > > +
> > > > > > +static __always_inline int buffer_locked(const struct buffer_head *bh)
> > > > > > +{
> > > > > > +	bool ret = test_bit(BH_Lock, &bh->b_state);
> > > > > > +	/*
> > > > > > +	 * pairs with smp_mb__after_atomic in unlock_buffer
> > > > > > +	 */
> > > > > > +	if (!ret)
> > > > > > +		smp_acquire__after_ctrl_dep();
> > > > > > +	return ret;
> > > > > > +}
> > > > > 
> > > > > Are there places that think that lock/unlock buffer implies a memory
> > > > > barrier?
> > > > 
> > > > There's this in fs/reiserfs:
> > > > 
> > > > if (!buffer_dirty(bh) && !buffer_locked(bh)) {
> > > > 	reiserfs_free_jh(bh); <--- this could be moved before buffer_locked
> > > 
> > > It might be better to think of buffer_locked() as
> > > buffer_someone_has_exclusive_access().  I can't see the problem with
> > > moving the reads in reiserfs_free_jh() before the read of buffer_locked.
> > > 
> > > > if (buffer_locked((journal->j_header_bh))) {
> > > > 	...
> > > > }
> > > > journal->j_last_flush_trans_id = trans_id;
> > > > journal->j_first_unflushed_offset = offset;
> > > > jh = (struct reiserfs_journal_header *)(journal->j_header_bh->b_data); <--- this could be moved before buffer_locked
> > > 
> > > I don't think b_data is going to be changed while someone else holds
> > > the buffer locked.  That's initialised by set_bh_page(), which is an
> > > initialisation-time thing, before the BH is visible to any other thread.
> > 
> > So, do you think that we don't need a barrier in buffer_locked()?
> 
> That's my feeling.  Of course, you might not be the only one confused,
> and if fs authors in general have made the mistake of thinking that
> buffer_locked is serialising, then it might be better to live up to
> that expectation.

In my spadfs filesystem, I used lock_buffer/unlock_buffer to prevent the 
system from seeing or writing back incomplete data. The patterns is
	lock_buffer(bh);
	... do several changes to the buffer that should appear atomically
	unlock_buffer(bh);
	mark_buffer_dirty(bh);
but it seems to be ok, because both lock_buffer and unlock_buffer have 
acquire/release semantics. I'm not sure about buffer_locked - perhaps it 
really doesn't need the barriers - spin_is_locked, mutex_is_locked and 
rwsem_is_locked also don't have any barriers.

Here I'm sending the patch without the change to buffer_locked.

Mikulas



From: Mikulas Patocka <mpatocka@redhat.com>

Let's have a look at this piece of code in __bread_slow:
	get_bh(bh);
	bh->b_end_io = end_buffer_read_sync;
	submit_bh(REQ_OP_READ, 0, bh);
	wait_on_buffer(bh);
	if (buffer_uptodate(bh))
		return bh;
Neither wait_on_buffer nor buffer_uptodate contain any memory barrier.
Consequently, if someone calls sb_bread and then reads the buffer data,
the read of buffer data may be executed before wait_on_buffer(bh) on
architectures with weak memory ordering and it may return invalid data.

Fix this bug by adding a memory barrier to set_buffer_uptodate and an
acquire barrier to buffer_uptodate (in a similar way as
folio_test_uptodate and folio_mark_uptodate).

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org

Index: linux-2.6/include/linux/buffer_head.h
===================================================================
--- linux-2.6.orig/include/linux/buffer_head.h
+++ linux-2.6/include/linux/buffer_head.h
@@ -117,7 +117,6 @@ static __always_inline int test_clear_bu
  * of the form "mark_buffer_foo()".  These are higher-level functions which
  * do something in addition to setting a b_state bit.
  */
-BUFFER_FNS(Uptodate, uptodate)
 BUFFER_FNS(Dirty, dirty)
 TAS_BUFFER_FNS(Dirty, dirty)
 BUFFER_FNS(Lock, locked)
@@ -135,6 +134,30 @@ BUFFER_FNS(Meta, meta)
 BUFFER_FNS(Prio, prio)
 BUFFER_FNS(Defer_Completion, defer_completion)
 
+static __always_inline void set_buffer_uptodate(struct buffer_head *bh)
+{
+	/*
+	 * make it consistent with folio_mark_uptodate
+	 * pairs with smp_load_acquire in buffer_uptodate
+	 */
+	smp_mb__before_atomic();
+	set_bit(BH_Uptodate, &bh->b_state);
+}
+
+static __always_inline void clear_buffer_uptodate(struct buffer_head *bh)
+{
+	clear_bit(BH_Uptodate, &bh->b_state);
+}
+
+static __always_inline int buffer_uptodate(const struct buffer_head *bh)
+{
+	/*
+	 * make it consistent with folio_test_uptodate
+	 * pairs with smp_mb__before_atomic in set_buffer_uptodate
+	 */
+	return (smp_load_acquire(&bh->b_state) & (1UL << BH_Uptodate)) != 0;
+}
+
 #define bh_offset(bh)		((unsigned long)(bh)->b_data & ~PAGE_MASK)
 
 /* If we *know* page->private refers to buffer_heads */
Re: [PATCH v6] add barriers to buffer_uptodate and set_buffer_uptodate
Posted by Linus Torvalds 3 years, 8 months ago
On Tue, Aug 9, 2022 at 11:32 AM Mikulas Patocka <mpatocka@redhat.com> wrote:
>
> Let's have a look at this piece of code in __bread_slow:
>         get_bh(bh);
>         bh->b_end_io = end_buffer_read_sync;
>         submit_bh(REQ_OP_READ, 0, bh);
>         wait_on_buffer(bh);
>         if (buffer_uptodate(bh))
>                 return bh;
> Neither wait_on_buffer nor buffer_uptodate contain any memory barrier.
> Consequently, if someone calls sb_bread and then reads the buffer data,
> the read of buffer data may be executed before wait_on_buffer(bh) on
> architectures with weak memory ordering and it may return invalid data.
>
> Fix this bug by adding a memory barrier to set_buffer_uptodate and an
> acquire barrier to buffer_uptodate (in a similar way as
> folio_test_uptodate and folio_mark_uptodate).

Ok, I've applied this to my tree.

I still feel that we should probably take a long look at having the
proper "acquire/release" uses everywhere for the buffer / page / folio
flags, but that wouldn't really work for backporting to stable, so I
think that's a "future fixes/cleanup" thing.

Thanks,
              Linus
Re: [PATCH v6] add barriers to buffer_uptodate and set_buffer_uptodate
Posted by Matthew Wilcox 3 years, 8 months ago
On Tue, Aug 09, 2022 at 02:32:13PM -0400, Mikulas Patocka wrote:
> From: Mikulas Patocka <mpatocka@redhat.com>
> 
> Let's have a look at this piece of code in __bread_slow:
> 	get_bh(bh);
> 	bh->b_end_io = end_buffer_read_sync;
> 	submit_bh(REQ_OP_READ, 0, bh);
> 	wait_on_buffer(bh);
> 	if (buffer_uptodate(bh))
> 		return bh;
> Neither wait_on_buffer nor buffer_uptodate contain any memory barrier.
> Consequently, if someone calls sb_bread and then reads the buffer data,
> the read of buffer data may be executed before wait_on_buffer(bh) on
> architectures with weak memory ordering and it may return invalid data.
> 
> Fix this bug by adding a memory barrier to set_buffer_uptodate and an
> acquire barrier to buffer_uptodate (in a similar way as
> folio_test_uptodate and folio_mark_uptodate).
> 
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>

> Cc: stable@vger.kernel.org
> 
> Index: linux-2.6/include/linux/buffer_head.h
> ===================================================================
> --- linux-2.6.orig/include/linux/buffer_head.h
> +++ linux-2.6/include/linux/buffer_head.h
> @@ -117,7 +117,6 @@ static __always_inline int test_clear_bu
>   * of the form "mark_buffer_foo()".  These are higher-level functions which
>   * do something in addition to setting a b_state bit.
>   */
> -BUFFER_FNS(Uptodate, uptodate)
>  BUFFER_FNS(Dirty, dirty)
>  TAS_BUFFER_FNS(Dirty, dirty)
>  BUFFER_FNS(Lock, locked)
> @@ -135,6 +134,30 @@ BUFFER_FNS(Meta, meta)
>  BUFFER_FNS(Prio, prio)
>  BUFFER_FNS(Defer_Completion, defer_completion)
>  
> +static __always_inline void set_buffer_uptodate(struct buffer_head *bh)
> +{
> +	/*
> +	 * make it consistent with folio_mark_uptodate
> +	 * pairs with smp_load_acquire in buffer_uptodate
> +	 */
> +	smp_mb__before_atomic();
> +	set_bit(BH_Uptodate, &bh->b_state);
> +}
> +
> +static __always_inline void clear_buffer_uptodate(struct buffer_head *bh)
> +{
> +	clear_bit(BH_Uptodate, &bh->b_state);
> +}
> +
> +static __always_inline int buffer_uptodate(const struct buffer_head *bh)
> +{
> +	/*
> +	 * make it consistent with folio_test_uptodate
> +	 * pairs with smp_mb__before_atomic in set_buffer_uptodate
> +	 */
> +	return (smp_load_acquire(&bh->b_state) & (1UL << BH_Uptodate)) != 0;
> +}
> +
>  #define bh_offset(bh)		((unsigned long)(bh)->b_data & ~PAGE_MASK)
>  
>  /* If we *know* page->private refers to buffer_heads */
>
Re: [PATCH v5] add barriers to buffer functions
Posted by Paul E. McKenney 3 years, 8 months ago
On Mon, Aug 08, 2022 at 10:57:45AM -0400, Mikulas Patocka wrote:
> 
> 
> On Mon, 8 Aug 2022, Matthew Wilcox wrote:
> 
> > On Mon, Aug 08, 2022 at 10:26:10AM -0400, Mikulas Patocka wrote:
> > > On Sun, 7 Aug 2022, Matthew Wilcox wrote:
> > > > > +static __always_inline void set_buffer_locked(struct buffer_head *bh)
> > > > > +{
> > > > > +	set_bit(BH_Lock, &bh->b_state);
> > > > > +}
> > > > > +
> > > > > +static __always_inline int buffer_locked(const struct buffer_head *bh)
> > > > > +{
> > > > > +	bool ret = test_bit(BH_Lock, &bh->b_state);
> > > > > +	/*
> > > > > +	 * pairs with smp_mb__after_atomic in unlock_buffer
> > > > > +	 */
> > > > > +	if (!ret)
> > > > > +		smp_acquire__after_ctrl_dep();
> > > > > +	return ret;
> > > > > +}
> > > > 
> > > > Are there places that think that lock/unlock buffer implies a memory
> > > > barrier?
> > > 
> > > There's this in fs/reiserfs:
> > > 
> > > if (!buffer_dirty(bh) && !buffer_locked(bh)) {
> > > 	reiserfs_free_jh(bh); <--- this could be moved before buffer_locked
> > 
> > It might be better to think of buffer_locked() as
> > buffer_someone_has_exclusive_access().  I can't see the problem with
> > moving the reads in reiserfs_free_jh() before the read of buffer_locked.
> > 
> > > if (buffer_locked((journal->j_header_bh))) {
> > > 	...
> > > }
> > > journal->j_last_flush_trans_id = trans_id;
> > > journal->j_first_unflushed_offset = offset;
> > > jh = (struct reiserfs_journal_header *)(journal->j_header_bh->b_data); <--- this could be moved before buffer_locked
> > 
> > I don't think b_data is going to be changed while someone else holds
> > the buffer locked.  That's initialised by set_bh_page(), which is an
> > initialisation-time thing, before the BH is visible to any other thread.
> 
> So, do you think that we don't need a barrier in buffer_locked()?

The question to ask here is "What prevents another call to buffer_locked()
from returning false?"

> There is also this (where the BUG_ON(!buffer_uptodate(bh)) saves it).
>                 if (buffer_locked(bh)) {

Right here, for example.  If something prevents any change that might
cause buffer_locked() to return false here, we don't need a barrier.
If there is nothing preventing such a change, how is a barrier going
to help?

One way this code could be correct is if the above check is a heuristic,
so that a false positive just consumes a bit more CPU and a false negative
just delays this action.

I must leave final judgment to those having better understanding of this
code than do I.

							Thanx, Paul

>                         int depth;
>                         PROC_INFO_INC(sb, scan_bitmap.wait);
>                         depth = reiserfs_write_unlock_nested(sb);
>                         __wait_on_buffer(bh);
>                         reiserfs_write_lock_nested(sb, depth);
>                 }
>                 BUG_ON(!buffer_uptodate(bh));
>                 BUG_ON(atomic_read(&bh->b_count) == 0);
> 
>                 if (info->free_count == UINT_MAX)
>                         reiserfs_cache_bitmap_metadata(sb, bh, info); <--- this could be moved before buffer_locked if there were no BUG_ONs
> 
> Mikulas
>