LinuxPPC-Dev Archive on lore.kernel.org
 help / color / Atom feed
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
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.

  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:
  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

LinuxPPC-Dev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linuxppc-dev/0 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/ https://lore.kernel.org/linuxppc-dev \
		linuxppc-dev@lists.ozlabs.org linuxppc-dev@ozlabs.org
	public-inbox-index linuxppc-dev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.ozlabs.lists.linuxppc-dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git