Messages in this thread | | | Date | Wed, 18 May 2016 09:11:36 -0400 | From | Chris Mason <> | Subject | Re: general protection fault (btrfs_real_readdir) |
| |
On Wed, May 18, 2016 at 01:21:14PM +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?
Yeah, it does expect the mutex to be held, sorry Al I missed this when you asked. I'll cook a patch today.
-chris
| |