Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2312577ybe; Tue, 3 Sep 2019 10:58:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqx6/GlIvL0i3h0LpqA4lP1UAgE2f7RJtAGPMwnodPTE5dC4yXDsOBR0nivD3yLsuVvCU3AN X-Received: by 2002:a17:902:581:: with SMTP id f1mr36072633plf.246.1567533510525; Tue, 03 Sep 2019 10:58:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567533510; cv=none; d=google.com; s=arc-20160816; b=aM0+4ZDUJSfEdiL8A8Lfaagm3KLp5aogidIsUbIaM3FHPfpNYou/gR4Zbeb1uNwpa6 mSJULPAURb47B+SYqbsA6oAE0hlN5MO6QLH9cRm2nz8nO6yUuT/DdZTQfPbyUiEp+s4z YBja3xN0Jqt31C3pQS6769Tn8QsgYbmm9qxDPVVYJeY4l/4jHNM+2NyC6QfZaXQs4Otd KOSXgOXOhC7XoGWnRGpmpf41fzN9TGG87/e7yrArw9O9aavaBO2bH9uSOuCAgE759vwU IYjdZs/F+/iCT84lu64zJnxU61i2r3kEih0eYD9tV01yFHsiL5jlxN+rEwcIl8vAAPR3 f6Vg== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=sutzcz36vQxGokOSsdgEUGyFiZIKdD04C38/ou9RS7s=; b=EzhlQK+yvf6HQRC+m4fq/qYuYtYXBjVLugBQctrDhDEDJtEzyuhdHeMH6crKbDVChb qT/kWDAqzx2b8SNsFfpv/mvIivd0Ua7WYEbY5zjF2fimDG+TGZFkMbsKmPnCftbm+CGh WB1DfYGWatfhUClvgn+vdB+UpwcH7t5J6z3XcjpPFiXGoFfsEgAqoYBw2IrRTyxod3tY /xSSmMZlspN6mn/WYYCf6C3pMDkV6N7QodAXibvBTbvl4KxcWuIS9YeSAJzaBnQL+YTD 7QqpW7qzewq6BZWlfnEBQ1qKIhWtHom1AahmVCExzbeZ0ZnD7+w6KKwV5rMYgwkCD+ZW HmTw== 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 u17si15171559pgn.387.2019.09.03.10.58.14; Tue, 03 Sep 2019 10:58:30 -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 S1730009AbfICR4O (ORCPT + 99 others); Tue, 3 Sep 2019 13:56:14 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:33200 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727667AbfICR4N (ORCPT ); Tue, 3 Sep 2019 13:56:13 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.1 #3 (Red Hat Linux)) id 1i5D2I-00046p-T4; Tue, 03 Sep 2019 17:56:11 +0000 Date: Tue, 3 Sep 2019 18:56:10 +0100 From: Al Viro To: Christoph Hellwig Cc: Qian Cai , linux-fsdevel@vger.kernel.org, LKML , Linus Torvalds Subject: Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic Message-ID: <20190903175610.GM1131@ZenIV.linux.org.uk> References: <7C6CCE98-1E22-433C-BF70-A3CBCDED4635@lca.pw> <20190903123719.GF1131@ZenIV.linux.org.uk> <20190903130456.GA9567@infradead.org> <20190903134832.GH1131@ZenIV.linux.org.uk> <20190903135024.GA8274@infradead.org> <20190903135354.GI1131@ZenIV.linux.org.uk> <20190903153930.GA2791@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190903153930.GA2791@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 08:39:30AM -0700, Christoph Hellwig wrote: > > There's much nastier situation than "new upstream kernel released, > > need to rebuild" - it's bisect in mainline trying to locate something... > > I really don't get the point. And it's not like we've card about > this anywhere else. And jumping wildly around with the numeric values > for constants will lead to bugs like the one you added and fixed again > and again. The thing is, there are several groups - it's not as if all additions were guaranteed to be at the end. So either we play with renumbering again and again, or we are back to the square one... Is there any common trick that would allow to verify the lack of duplicates at the build time? Or we can reorder the list by constant value, with no grouping visible anywhere...