linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Abdul Haleem <abdhalee@linux.vnet.ibm.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Cc: sachinp <sachinp@linux.vnet.ibm.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>,
	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 13:39:57 +0300	[thread overview]
Message-ID: <7139ac07-db63-b984-c416-d1c94337c9bf@suse.com> (raw)
In-Reply-To: <1567500907.5082.12.camel@abdul>



On 3.09.19 г. 11:55 ч., 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
> 
> 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.
>     
>     Reviewed-by: Nikolay Borisov <nborisov@suse.com>
>     Signed-off-by: David Sterba <dsterba@suse.com>
> 
> diff --git a/fs/btrfs/locking.c b/fs/btrfs/locking.c
> index 2706676279..98fccce420 100644
> --- a/fs/btrfs/locking.c
> +++ b/fs/btrfs/locking.c
> @@ -58,17 +58,17 @@ static void btrfs_assert_tree_read_locked(struct
> extent_buffer *eb)
>  
>  static void btrfs_assert_tree_write_locks_get(struct extent_buffer *eb)
>  {
> -       atomic_inc(&eb->write_locks);
> +       eb->write_locks++;
>  }
>  
>  static void btrfs_assert_tree_write_locks_put(struct extent_buffer *eb)
>  {
> -       atomic_dec(&eb->write_locks);
> +       eb->write_locks--;
>  }
>  
>  void btrfs_assert_tree_locked(struct extent_buffer *eb)
>  {
> -       BUG_ON(!atomic_read(&eb->write_locks));
> +       BUG_ON(!eb->write_locks);
>  }
>  
> 
> tests logs:
> avocado-misc-tests/io/disk/ltp_fs.py:LtpFs.test_fs_run;fs_fill-dir-ext3-61cd:  [ 3376.022096] EXT4-fs (nvme0n1): mounting ext3 file system using the ext4 subsystem
> EXT4-fs (nvme0n1): mounted filesystem with ordered data mode. Opts: (null)
> EXT4-fs (loop1): mounting ext2 file system using the ext4 subsystem
> EXT4-fs (loop1): mounted filesystem without journal. Opts: (null)
> EXT4-fs (loop1): mounting ext3 file system using the ext4 subsystem
> EXT4-fs (loop1): mounted filesystem with ordered data mode. Opts: (null)
> EXT4-fs (loop1): mounted filesystem with ordered data mode. Opts: (null)
> XFS (loop1): Mounting V5 Filesystem
> XFS (loop1): Ending clean mount
> XFS (loop1): Unmounting Filesystem
> BTRFS: device fsid 7c08f81b-6642-4a06-9182-2884e80d56ee devid 1 transid 5 /dev/loop1
> BTRFS info (device loop1): disk space caching is enabled
> BTRFS info (device loop1): has skinny extents
> BTRFS info (device loop1): enabling ssd optimizations
> BTRFS info (device loop1): creating UUID tree
> ------------[ cut here ]------------
> kernel BUG at fs/btrfs/locking.c:71!
> Oops: Exception in kernel mode, sig: 5 [#1]
> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> Modules linked in: fuse(E) vfat(E) fat(E) btrfs(E) xor(E)
> zstd_decompress(E) zstd_compress(E) raid6_pq(E) xfs(E) raid0(E)
> linear(E) dm_round_robin(E) dm_queue_length(E) dm_service_time(E)
> dm_multipath(E) loop(E) rpadlpar_io(E) rpaphp(E) lpfc(E) bnx2x(E)
> xt_CHECKSUM(E) xt_MASQUERADE(E) tun(E) bridge(E) stp(E) llc(E) kvm_pr(E)
> kvm(E) tcp_diag(E) udp_diag(E) inet_diag(E) unix_diag(E)
> af_packet_diag(E) netlink_diag(E) ip6t_rpfilter(E) ipt_REJECT(E)
> nf_reject_ipv4(E) ip6t_REJECT(E) nf_reject_ipv6(E) xt_conntrack(E)
> ip_set(E) nfnetlink(E) ebtable_nat(E) ebtable_broute(E) ip6table_nat(E)
> ip6table_mangle(E) ip6table_security(E) ip6table_raw(E) iptable_nat(E)
> nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E)
> iptable_mangle(E) iptable_security(E) iptable_raw(E) ebtable_filter(E)
> ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E) sunrpc(E)
> raid10(E) xts(E) pseries_rng(E) vmx_crypto(E) sg(E) uio_pdrv_genirq(E)
> uio(E) binfmt_misc(E) sch_fq_codel(E) ip_tables(E)
>  ext4(E) mbcache(E) jbd2(E) sr_mod(E) cdrom(E) sd_mod(E) ibmvscsi(E)
> scsi_transport_srp(E) ibmveth(E) nvmet_fc(E) nvmet(E) nvme_fc(E)
> nvme_fabrics(E) scsi_transport_fc(E) mdio(E) libcrc32c(E) ptp(E)
> pps_core(E) nvme(E) nvme_core(E) dm_mirror(E) dm_region_hash(E)
> dm_log(E) dm_mod(E) [last unloaded: lpfc]
> CPU: 14 PID: 1803 Comm: kworker/u32:8 Tainted: G            E     5.3.0-rc5-autotest-autotest #1
> Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
> NIP:  c00800000164dd70 LR: c00800000164df00 CTR: c000000000a817a0
> REGS: c00000000260b5d0 TRAP: 0700   Tainted: G            E      (5.3.0-rc5-autotest-autotest)
> MSR:  8000000102029033 <SF,VEC,EE,ME,IR,DR,RI,LE,TM[E]>  CR: 22444082  XER: 00000000
> CFAR: c00800000164defc IRQMASK: 0
> GPR00: c0080000015c55f4 c00000000260b860 c008000001703b00 c000000267a29af0
> GPR04: 0000000000000000 0000000000000001 0000000000000000 0000000000000000
> GPR08: 0000000000000000 0000000000000001 0000000000000000 0000000000000004
> GPR12: 0000000000004000 c00000001ec58e00 0000000000000000 0000000000000000
> GPR16: 0000000000010000 0000000000000004 0000000000000001 0000000000000001
> GPR20: 0000000000000000 0000000000000001 000000003e0f83e1 c00000025a7cbef0
> GPR24: c00000000260ba26 0000000040000000 c0000000014a26e8 0000000000000003
> GPR28: 0000000000000004 c00000025f2010a0 c000000267a29af0 0000000000000000
> NIP [c00800000164dd70] btrfs_assert_tree_locked+0x10/0x20 [btrfs]
> LR [c00800000164df00] btrfs_set_lock_blocking_write+0x60/0x100 [btrfs]
> Call Trace:
> [c00000000260b860] [c00000000260b8e0] 0xc00000000260b8e0 (unreliable)
> [c00000000260b890] [c0080000015c55f4] btrfs_set_path_blocking+0xb4/0xc0 [btrfs]
> [c00000000260b8e0] [c0080000015cb808] btrfs_search_slot+0x8e8/0xb80 [btrfs]

Can you provide the line numbers btrfs_search_slot+0x8e8/0xb80
corresponds to?


  reply	other threads:[~2019-09-03 10:52 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 [this message]
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
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=7139ac07-db63-b984-c416-d1c94337c9bf@suse.com \
    --to=nborisov@suse.com \
    --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=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).