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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1307042349230.11637@ionos.tec.linutronix.de>
Date:	Thu, 4 Jul 2013 23:50:33 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Waiman Long <waiman.long@...com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Jeff Layton <jlayton@...hat.com>,
	Miklos Szeredi <mszeredi@...e.cz>,
	Ingo Molnar <mingo@...hat.com>, 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, 4 Jul 2013, Linus Torvalds wrote:

> 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..

And all of this can sanely be done with coccinelle. Julia will
certainly help to get the scripts right.

Thanks,

	tglx
--
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/