linux-kernel - Re: [PATCH v4 04/12] auto-fs: rename d_count field of dentry to d

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFwNS+QSngRg4SQ_1o3GsGKqVXENaTsD0jB_8HwBP+kSUg@mail.gmail.com>
Date:	Thu, 4 Jul 2013 10:53:09 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Waiman Long <waiman.long@...com>
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	Jeff Layton <jlayton@...hat.com>,
	Miklos Szeredi <mszeredi@...e.cz>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ian Kent <raven@...maw.net>,
	autofs mailing list <autofs@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Andi Kleen <andi@...stfloor.org>,
	"Chandramouleeswaran, Aswin" <aswin@...com>,
	"Norton, Scott J" <scott.norton@...com>
Subject: Re: [PATCH v4 04/12] auto-fs: rename d_count field of dentry to d_refcount

On Thu, Jul 4, 2013 at 7:47 AM, Waiman Long <waiman.long@...com> wrote:
>
> I could change patch 3 so that I keep the d_count name, but #define
> d_refcount to d_count. In that way, I can do piece-meal changes without
> breaking the build. Alternatively, I could collapse patches 3-11 into a
> single big patch which will be harder to review.

Since there are many fewer d_count users than there are d_lock users,
I think collapsing things is the right thing to do.

That said, I think Al is right that for all those filesystem uses, we
might actually be much better off with a helper function looking at
d_count, with no macros etc, since they are purely about reading the
count.

So maybe the right thing to do is to add a

   static inline int d_count(struct dentry *dentry) { return dentry->d_count; }

helper function *first*, and just say "filesystems should never access
d_count directly", and make the few filesystem users use this helper
function first. That way we can do that as independent commits to
prepare for the switch-over.

Then when the switch-over happens, we just change "d_count" in that
helper function, and it has no filesystem impact at all.

But fs/dcache.c and fs/namei.c that actually really know about and
modify d_count would not use that helper function. It would purely be
about isolating filesystems from these kinds of internal
implementation issues: fs/cache.c and fs/namei.c are all *about* those
internal issues, so they shouldn't be isolated..

           Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/