From: Feifei Xu <xufeifei@linux.vnet.ibm.com>
To: Al Viro <viro@ZenIV.linux.org.uk>, hejianet <hejianet@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, xuhilar@gmail.com, boqun.feng@gmail.com
Subject: Re: [Bug] fs/dcache.c: NULL pointer dereference on dentry_string_cmp
Date: Thu, 21 Jul 2016 14:40:39 +0800 [thread overview]
Message-ID: <52a76841-35e6-15c2-2482-7d7d4a8fba03@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160721041857.GK2356@ZenIV.linux.org.uk>
On 2016/7/21 12:18, Al Viro wrote:
>
> Hash insertion does smp_store_release(). Hash chain traversal -
> smp_read_barrier_depends(). On ppc the former is lwsync, while the latter
> is no-op, so it boils down to
> store dentry->d_name.name
> lwsync
> store mangled address of dentry into hash chain
> vs.
> fetch mangled address of dentry
> demangle it
> fetch dentry->d_name.name
> which should be enough - lwsync paired with address dependency gives the
> ordering. IOW, it's not about the barriers in __d_alloc(), it's those in
> hlist_bl_add_head_rcu() and hlist_bl_for_each_entry_rcu().
>
> And it couldn't be a missing barrier anyway - crash dump shows that
> sucker with NULL ->d_name.name.
>
Maybe this is useful: there's a warning that in dmesg before the oops:
http://paste.ubuntu.com/20279712/
[379630.827833] ------------[ cut here ]------------
[379630.827834] WARNING: at lib/list_debug.c:59
[379630.827835] Modules linked in: iptable_mangle iptable_nat nf_nat_ipv4 nf_nat iptable_raw iptable_filter ip_tables binfmt_misc nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack xfs libcrc32c ses enclosure sg ipmi_powernv ipmi_msghandler rtc_opal i2c_opal i2c_core powernv_rng shpchp ext4 mbcache jbd2 dm_service_time sd_mod sr_mod crc_t10dif crct10dif_generic cdrom crct10dif_common ipr tg3 cxgb4 libata ptp pps_core dm_mirror dm_region_hash dm_log dm_multipath nf_conntrack_ftp dm_mod nf_conntrack [last unloaded: ip_tables]
[379630.827876] CPU: 120 PID: 1371 Comm: kswapd17 Not tainted 3.10.0-327.18.2.el7.ppc64le #1
[379630.827877] task: c000000fe4c49c80 ti: c000000fe4ca0000 task.ti: c000000fe4ca0000
[379630.827879] NIP: c0000000004c9964 LR: c0000000004c9960 CTR: c0000000004b2860
[379630.827880] REGS: c000000fe4ca36a0 TRAP: 0700 Not tainted (3.10.0-327.18.2.el7.ppc64le)
[379630.827881] MSR: 9000000100029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 28044044 XER: 20000000
[379630.827886] CFAR: c000000000956fb8 SOFTE: 1
GPR00: c0000000004c9960 c000000fe4ca3920 c0000000011231b0 0000000000000054
GPR04: c00000010ce08018 c00000010ce18bf0 0000000000000000 0000000000000002
GPR08: c000000000cb31b0 0000000000000000 0000000000000000 3239343331313632
GPR12: 0000000042044042 c000000007b63800 0000000000000000 0000000000000d63
GPR16: c000000001055848 00000000000001d4 00000000000f0b03 c000000001055868
GPR20: c000000fa0a2fbd8 00000000000f0b02 0000000000000040 0000000000000078
GPR24: 0000000000000000 c000000fe4ca39b0 c000000fe4ca39a0 0000000000000000
GPR28: c000000001162580 c000000fa0a2f8d0 c000000fa0a2f800 c000002611349200
[379630.827904] NIP [c0000000004c9964] __list_del_entry+0xb4/0xe0
[379630.827906] LR [c0000000004c9960] __list_del_entry+0xb0/0xe0
[379630.827907] Call Trace:
[379630.827909] [c000000fe4ca3920] [c0000000004c9960] __list_del_entry+0xb0/0xe0 (unreliable)
[379630.827913] [c000000fe4ca3980] [c0000000003270dc] prune_dcache_sb+0x9c/0x250
[379630.827915] [c000000fe4ca3a10] [c0000000002ff558] prune_super+0x1b8/0x200
[379630.827918] [c000000fe4ca3a50] [c00000000025adf4] shrink_slab+0x204/0x3b0
[379630.827920] [c000000fe4ca3b50] [c00000000025f00c] balance_pgdat+0x8ac/0xb20
[379630.827922] [c000000fe4ca3c90] [c00000000025f444] kswapd+0x1c4/0x740
[379630.827924] [c000000fe4ca3d80] [c00000000011023c] kthread+0xec/0x100
[379630.827927] [c000000fe4ca3e30] [c00000000000a474] ret_from_kernel_thread+0x5c/0x68
[379630.827928] Instruction dump:
[379630.827929] 0fe00000 4bffffd8 3c62ffa5 38639668 4848d5f9 60000000 0fe00000 4bffffc0
[379630.827931] 3c62ffa5 38639628 4848d5e1 60000000 <0fe00000> 4bffffa8 3c62ffa5 7d254b78
[379630.827935] ---[ end trace 7c1c505a25279a31 ]---
Thanks
Fiona
next prev parent reply other threads:[~2016-07-21 6:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-14 13:25 [Bug] fs/dcache.c: NULL pointer dereference on dentry_string_cmp Feifei Xu
2016-07-20 5:59 ` Al Viro
2016-07-21 3:20 ` hejianet
2016-07-21 4:18 ` Al Viro
2016-07-21 5:57 ` Al Viro
2016-07-21 6:40 ` Feifei Xu [this message]
2016-07-21 7:42 ` Feifei Xu
2016-07-21 6:30 ` Feifei Xu
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=52a76841-35e6-15c2-2482-7d7d4a8fba03@linux.vnet.ibm.com \
--to=xufeifei@linux.vnet.ibm.com \
--cc=boqun.feng@gmail.com \
--cc=hejianet@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
--cc=xuhilar@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.