All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@infradead.org>, Qian Cai <cai@lca.pw>,
	linux-fsdevel@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic
Date: Wed, 4 Sep 2019 05:39:41 -0700	[thread overview]
Message-ID: <20190904123940.GA24520@infradead.org> (raw)
In-Reply-To: <20190903175610.GM1131@ZenIV.linux.org.uk>

On Tue, Sep 03, 2019 at 06:56:10PM +0100, Al Viro wrote:
> 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...

Here is what I'd do.  No validation of duplicates, but the 1 << bit
notation makes them very easy to spot:

diff --git a/include/linux/namei.h b/include/linux/namei.h
index 397a08ade6a2..a9536f90936c 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -16,28 +16,47 @@ enum { MAX_NESTED_LINKS = 8 };
  */
 enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
 
-/* pathwalk mode */
-#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_REVAL		0x0020	/* tell ->d_revalidate() to trust no cache */
-#define LOOKUP_RCU		0x0040	/* RCU pathwalk mode; semi-internal */
-
-/* These tell filesystem methods that we are dealing with the final component... */
-#define LOOKUP_OPEN		0x0100	/* ... in open */
-#define LOOKUP_CREATE		0x0200	/* ... in object creation */
-#define LOOKUP_EXCL		0x0400	/* ... in exclusive creation */
-#define LOOKUP_RENAME_TARGET	0x0800	/* ... in destination of rename() */
-
-/* internal use only */
-#define LOOKUP_PARENT		0x0010
-#define LOOKUP_NO_REVAL		0x0080
-#define LOOKUP_JUMPED		0x1000
-#define LOOKUP_ROOT		0x2000
-#define LOOKUP_ROOT_GRABBED	0x0008
+/*
+ * Pathwalk mode:
+ */
+
+/* follow links at the end */
+#define LOOKUP_FOLLOW		(1 << 0)
+/* require a directory */
+#define LOOKUP_DIRECTORY	(1 << 1)
+/* force terminal automount */
+#define LOOKUP_AUTOMOUNT	(1 << 2)
+/* accept empty path [user_... only] */
+#define LOOKUP_EMPTY		(1 << 3)
+/* follow mounts in the starting point */
+#define LOOKUP_DOWN		(1 << 4)
+/* tell ->d_revalidate() to trust no cache */
+#define LOOKUP_REVAL		(1 << 5)
+/* RCU pathwalk mode; semi-internal */
+#define LOOKUP_RCU		(1 << 6)
+
+
+/*
+ * These tell filesystem methods that we are dealing with the final component:
+ */
+
+/* ... in open */
+#define LOOKUP_OPEN		(1 << 10)
+/* ... in object creation */
+#define LOOKUP_CREATE		(1 << 11)
+/* ... in exclusive creation */
+#define LOOKUP_EXCL		(1 << 12)
+/* ... in destination of rename() */
+#define LOOKUP_RENAME_TARGET	(1 << 13)
+
+/*
+ * Internal use only:
+ */
+#define LOOKUP_PARENT		(1 << 20)
+#define LOOKUP_NO_REVAL		(1 << 21)
+#define LOOKUP_JUMPED		(1 << 22)
+#define LOOKUP_ROOT		(1 << 23)
+#define LOOKUP_ROOT_GRABBED	(1 << 24)
 
 extern int path_pts(struct path *path);
 

  reply	other threads:[~2019-09-04 12:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03  4:21 "fs/namei.c: keep track of nd->root refcount status" causes boot panic Qian Cai
2019-09-03  5:22 ` Dexuan-Linux Cui
2019-09-03  5:50   ` Dexuan Cui
2019-09-03  6:00     ` Dexuan Cui
2019-09-03  8:13 ` Naresh Kamboju
2019-09-03  9:08   ` Sachin Sant
2019-09-03 12:37 ` Al Viro
2019-09-03 13:04   ` Christoph Hellwig
2019-09-03 13:48     ` Al Viro
2019-09-03 13:50       ` Christoph Hellwig
2019-09-03 13:53         ` Al Viro
2019-09-03 15:39           ` Christoph Hellwig
2019-09-03 17:56             ` Al Viro
2019-09-04 12:39               ` Christoph Hellwig [this message]
2019-09-05  9:13                 ` Naresh Kamboju
2019-09-05 16:46                   ` Al Viro
2019-09-05 12:17               ` Kevin Easton
2019-09-03 21:30         ` Theodore Y. Ts'o
2019-09-03 13:31   ` Al Viro
2019-09-03 13:52     ` Naresh Kamboju

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=20190904123940.GA24520@infradead.org \
    --to=hch@infradead.org \
    --cc=cai@lca.pw \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.