From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-kernel@vger.kernel.org, Chris Mason <clm@fb.com>
Subject: Re: general protection fault (btrfs_real_readdir)
Date: Wed, 18 May 2016 14:32:13 +0200 [thread overview]
Message-ID: <20160518123213.GA311@x4> (raw)
In-Reply-To: <20160518122113.GP14480@ZenIV.linux.org.uk>
On 2016.05.18 at 13:21 +0100, Al Viro wrote:
> On Wed, May 18, 2016 at 01:31:40PM +0200, Markus Trippelsdorf wrote:
> > I'm running the latest Linus git tree and the parallel filesystem directory
> > handling update seems to cause the following issue:
>
> > Call Trace:
> > [<ffffffff812f038b>] ? btrfs_real_readdir+0x44b/0x540
> > [<ffffffff811b064d>] ? SyS_getdents+0x12d/0x2a0
> > [<ffffffff811affa0>] ? SyS_ioctl+0x6a0/0x6a0
> > [<ffffffff810923db>] ? entry_SYSCALL_64_fastpath+0x13/0x8f
> > Code: 02 00 00 00 00 ad de eb 1e f0 ff 4b 60 74 73 49 8b 47 40 49 8d 57 40 4c 89 fb 48 39 d5 4c 8d 78 c0 0f 84 8d 00 00 00 48 8b 53 48 <48> 89 50 08 48 89 02 4c 89 6b 40 4c 89 63 48 48 8b 4b 21 49 3b
> > RIP [<ffffffff8134e9f3>] btrfs_readdir_delayed_dir_index+0x73/0x120
> > RSP <ffff8801076e3dc0>
> > ---[ end trace 91067801e8a68a7e ]---
> >
> > This happened while I was building gcc, so the system was very busy.
>
> From a very superficial reading of delayed-inode.c, it looks like delayed
> node might need locking... This
> list_for_each_entry_safe(curr, next, ins_list, readdir_list) {
> list_del(&curr->readdir_list);
> looks particularly unpleasant. Just to make sure that this *is* just a
> readdir issue (and not something involving lookups), could you try to
> reproduce the breakage with 972b241f8 reverted?
Will give it a try later.
Just in case it may help:
(gdb) list *(btrfs_readdir_delayed_dir_index+0x73)
0xffffffff8134e9f3 is in btrfs_readdir_delayed_dir_index (include/linux/list.h:89).
84 * This is only for internal list manipulation where we know
85 * the prev/next entries already!
86 */
87 static inline void __list_del(struct list_head * prev, struct list_head * next)
88 {
89 next->prev = prev;
90 WRITE_ONCE(prev->next, next);
91 }
92
93 /**
(gdb) list *(btrfs_real_readdir+0x44b)
0xffffffff812f038b is in btrfs_real_readdir (fs/btrfs/inode.c:5858).
5853
5854 if (key_type == BTRFS_DIR_INDEX_KEY) {
5855 if (is_curr)
5856 ctx->pos++;
5857 ret = btrfs_readdir_delayed_dir_index(ctx, &ins_list, &emitted);
5858 if (ret)
5859 goto nopos;
5860 }
5861
5862 /*
--
Markus
next prev parent reply other threads:[~2016-05-18 12:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-18 11:31 general protection fault (btrfs_real_readdir) Markus Trippelsdorf
2016-05-18 12:21 ` Al Viro
2016-05-18 12:32 ` Markus Trippelsdorf [this message]
2016-05-18 13:01 ` Markus Trippelsdorf
2016-05-18 13:11 ` Chris Mason
2016-05-18 14:14 ` Chris Mason
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=20160518123213.GA311@x4 \
--to=markus@trippelsdorf.de \
--cc=clm@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/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