From: David Sterba <dsterba@suse.cz>
To: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Cc: sachinp <sachinp@linux.vnet.ibm.com>,
Nikolay Borisov <nborisov@suse.com>,
josef@toxicpanda.com, linux-kernel <linux-kernel@vger.kernel.org>,
David Sterba <dsterba@suse.com>,
chandan <chandan@linux.vnet.ibm.com>,
Brian King <brking@linux.vnet.ibm.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-btrfs@vger.kernel.org
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 [thread overview]
Message-ID: <20190903123809.GC2752@suse.cz> (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 <dsterba@suse.com>
> 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.
next prev parent reply other threads:[~2019-09-03 12:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 8:55 [mainline][BUG][PPC][btrfs][bisected 00801a] kernel BUG at fs/btrfs/locking.c:71! 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 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=20190903123809.GC2752@suse.cz \
--to=dsterba@suse.cz \
--cc=abdhalee@linux.vnet.ibm.com \
--cc=brking@linux.vnet.ibm.com \
--cc=chandan@linux.vnet.ibm.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=nborisov@suse.com \
--cc=sachinp@linux.vnet.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).