Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2011844ybe; Tue, 3 Sep 2019 06:49:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqxnB6xWtD+T4Vea39BHHXbYh+Y6IAxW1DdJeQP66tuWfuBormyd+WTWQMTgMjkpGUncqdxN X-Received: by 2002:aa7:9e50:: with SMTP id z16mr21653318pfq.83.1567518593897; Tue, 03 Sep 2019 06:49:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567518593; cv=none; d=google.com; s=arc-20160816; b=0lX2QbgyafzfC6T9WIkFwDUiibyK9eopZMyQzErdlllv4EYwSFtegfYyR0zv/Q8zuz tKMtNCK2mkm63g8PmvRbRIH5WNi7guRiXpRi9J9bKLsFmcM9r13wt6VQW2MMrV/p3H9v c0Per0/60bpKItQA88BzVheNPXUqkxkzY8SKBIYzuBJDTvx3OAZ/0EVw9rjSu7r/SlM6 IYa9YhRMzMrIG4yYzRFoP8mvso7XvnJepIgrW7PaBVQ6TJsmEHci2XqF65VOWYq1RtSg Bz0R6pUpDqyoOrcqUzHTQ1KAjUtpBWLyOpFwSB5qfrFx10HfrXmtOu3XihhdON74NiUF TuSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=rkPRXSkEDr8xD6h330SXqVhKVq9DQWy0PkF4KQHb+iQ=; b=cbTLGAh0kPflPCj2uPkPO31HsLG5wCrWeXytG7YFHxRgX/D1dgkDHndie6yx5qsfz7 4b9ZPwMvcKfPRKWpcZM4PPK8zWbZb5XtZwbsp9su3qvLgk0pVtnoFEl/2bKNmL9DpkAe 1cSOsHc3E+J735M5Di/gT3UxLQBA8Ky+p4MDUEwKxc7IeFQEx+/shVWXMYRSOXkEmQo0 qoXyr9+QYR89087aBuOKqaA9fjAsNOD6TXaW/sfPRORJvIvVDieAfGVRxQF3gQCHf57F 4NhsxoSPuaQMP9I/RcU/Ye/iq7vPw7jt8S4Hb9++33AFrQeIQLsgRQj8BJO2vCHiTh8s 00Xg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r14si14992137pls.108.2019.09.03.06.49.38; Tue, 03 Sep 2019 06:49:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729306AbfICNsf (ORCPT + 99 others); Tue, 3 Sep 2019 09:48:35 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:57838 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728860AbfICNsf (ORCPT ); Tue, 3 Sep 2019 09:48:35 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.1 #3 (Red Hat Linux)) id 1i59Ae-0003on-Cg; Tue, 03 Sep 2019 13:48:32 +0000 Date: Tue, 3 Sep 2019 14:48:32 +0100 From: Al Viro To: Christoph Hellwig Cc: Qian Cai , linux-fsdevel@vger.kernel.org, LKML Subject: Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic Message-ID: <20190903134832.GH1131@ZenIV.linux.org.uk> References: <7C6CCE98-1E22-433C-BF70-A3CBCDED4635@lca.pw> <20190903123719.GF1131@ZenIV.linux.org.uk> <20190903130456.GA9567@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190903130456.GA9567@infradead.org> User-Agent: Mutt/1.12.0 (2019-05-25) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 03, 2019 at 06:04:56AM -0700, Christoph Hellwig wrote: > On Tue, Sep 03, 2019 at 01:37:19PM +0100, Al Viro wrote: > > On Tue, Sep 03, 2019 at 12:21:36AM -0400, Qian Cai wrote: > > > The linux-next commit "fs/namei.c: keep track of nd->root refcount status” [1] causes boot panic on all > > > architectures here on today’s linux-next (0902). Reverted it will fix the issue. > > > > > > > > OK, I see what's going on. Incremental to be folded in: > > > > diff --git a/include/linux/namei.h b/include/linux/namei.h > > index 20ce2f917ef4..2ed0942a67f8 100644 > > --- a/include/linux/namei.h > > +++ b/include/linux/namei.h > > @@ -20,8 +20,8 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND}; > > #define LOOKUP_FOLLOW 0x0001 /* follow links at the end */ > > #define LOOKUP_DIRECTORY 0x0002 /* require a directory */ > > #define LOOKUP_AUTOMOUNT 0x0004 /* force terminal automount */ > > -#define LOOKUP_EMPTY 0x4000 /* accept empty path [user_... only] */ > > -#define LOOKUP_DOWN 0x8000 /* follow mounts in the starting point */ > > +#define LOOKUP_EMPTY 0x8000 /* accept empty path [user_... only] */ > > +#define LOOKUP_DOWN 0x10000 /* follow mounts in the starting point */ > > > > #define LOOKUP_REVAL 0x0020 /* tell ->d_revalidate() to trust no cache */ > > #define LOOKUP_RCU 0x0040 /* RCU pathwalk mode; semi-internal */ > > Any chance to keep these ordered numerically to avoid someone else > introdcing this kind of bug again later on? Not sure what would be the best way to do it... I don't mind breaking the out-of-tree modules, whatever their license is; what I would rather avoid is _quiet_ breaking of such.