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 */
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?
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
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.
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
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.
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 */
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
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 */
>
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
>
© 2016 - 2026 Red Hat, Inc.