From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753126AbcERMcS (ORCPT ); Wed, 18 May 2016 08:32:18 -0400 Received: from ud10.udmedia.de ([194.117.254.50]:38300 "EHLO mail.ud10.udmedia.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751967AbcERMcR (ORCPT ); Wed, 18 May 2016 08:32:17 -0400 Date: Wed, 18 May 2016 14:32:13 +0200 From: Markus Trippelsdorf To: Al Viro Cc: linux-kernel@vger.kernel.org, Chris Mason Subject: Re: general protection fault (btrfs_real_readdir) Message-ID: <20160518123213.GA311@x4> References: <20160518113140.GA321@x4> <20160518122113.GP14480@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160518122113.GP14480@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: > > [] ? btrfs_real_readdir+0x44b/0x540 > > [] ? SyS_getdents+0x12d/0x2a0 > > [] ? SyS_ioctl+0x6a0/0x6a0 > > [] ? 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 [] btrfs_readdir_delayed_dir_index+0x73/0x120 > > RSP > > ---[ 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