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);
next prev parent 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.