[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091214163019.GG7812@parisc-linux.org>
Date: Mon, 14 Dec 2009 09:30:19 -0700
From: Matthew Wilcox <matthew@....cx>
To: Arjan van de Ven <arjan@...radead.org>
Cc: Pavel Machek <pavel@....cz>, Emese Revfy <re.emese@...il.com>,
Paul Mundt <lethal@...ux-sh.org>, linux-kernel@...r.kernel.org,
torvalds@...ux-foundation.org, viro@...iv.linux.org.uk,
akpm@...ux-foundation.org
Subject: Re: [PATCH 0/1] Constify struct address_space_operations for
2.6.32-git-053fe57ac v2
On Mon, Dec 14, 2009 at 08:00:49AM -0800, Arjan van de Ven wrote:
> I for one am not opposed to using const where we could be using const.
> It's a fundamental language feature, that helps the compiler and
> developer. Yes there is sparse, and no, almost nobody uses that.
>
> If it's const, it won't be and can't be changed, allowing
> more aggressive optimization. It also means all these structures get
> put in the rodata section, which means by definition they can no longer
> have false sharing with data structures that are written to,.. and that
> section is often even really read only (cpu protection bits), which is
> also a nice, but secundary; _ops are one of those targets for rootkits
> and accidental overwrites.
Yes, but that's accomplished by tagging each of the arrays of function
pointers in question as const. Not by tagging the individual members
within the structure definition as const, which is what this patch
series does.
I don't think anyone objects to what you're trying to accomplish, but
this series of patches, as Al says, feel like pure cargo-culting.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
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/
Powered by blists - more mailing lists