Messages in this thread | | | Date | Tue, 3 Sep 2019 14:38:09 +0200 | From | David Sterba <> | Subject | Re: [mainline][BUG][PPC][btrfs][bisected 00801a] kernel BUG at fs/btrfs/locking.c:71! |
| |
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.
| |