LinuxPPC-Dev Archive on
 help / color / Atom feed
From: David Sterba <>
To: Abdul Haleem <>
Cc: sachinp <>,
	Nikolay Borisov <>,, linux-kernel <>,
	David Sterba <>,
	chandan <>,
	Brian King <>,
	linuxppc-dev <>,
Subject: Re: [mainline][BUG][PPC][btrfs][bisected 00801a] kernel BUG at fs/btrfs/locking.c:71!
Date: Tue, 3 Sep 2019 14:38:09 +0200
Message-ID: <> (raw)
In-Reply-To: <1567500907.5082.12.camel@abdul>

On Tue, Sep 03, 2019 at 02:25:07PM +0530, Abdul Haleem wrote:
> Greeting's
> Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my P9 box running mainline kernel 5.3.0-rc5
> BUG_ON was first introduced by below commit

Well, technically the bug_on was there already the only change is the
handling of the updates of the value.

> commit 00801ae4bb2be5f5af46502ef239ac5f4b536094
> Author: David Sterba <>
> Date:   Thu May 2 16:53:47 2019 +0200
>     btrfs: switch extent_buffer write_locks from atomic to int
>     The write_locks is either 0 or 1 and always updated under the lock,
>     so we don't need the atomic_t semantics.

Assuming the code was correct before the patch, if this got broken one
of the above does not hold anymore:

* 0/1 updates -- this can be verified in code that all the state
  transitions are valid, ie. initial 0, locked update to 1, locked
  update 1->0

* atomic_t -> int behaves differently and the changes of the value get
  mixed up, eg. on the instruction level where intel architecture does
  'inc' while p9 does I-don't-know-what a RMW update?

But even with a RMW, this should not matter due to
write_lock/write_unlock around all the updates.

  parent reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03  8:55 Abdul Haleem
2019-09-03 10:39 ` Nikolay Borisov
2019-09-11  8:00   ` Abdul Haleem
2019-09-11  8:09     ` Nikolay Borisov
2019-09-11  9:14       ` Abdul Haleem
2019-09-03 12:38 ` David Sterba [this message]
2019-09-06 15:51 ` David Sterba

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LinuxPPC-Dev Archive on

Archives are clonable:
	git clone --mirror linuxppc-dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linuxppc-dev linuxppc-dev/ \
	public-inbox-index linuxppc-dev

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone