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