[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100125231411.GA19799@ZenIV.linux.org.uk>
Date: Mon, 25 Jan 2010 23:14:11 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Tejun Heo <tj@...nel.org>
Cc: linux-kernel@...r.kernel.org, axboe@...nel.dk,
rusty@...tcorp.com.au, akpm@...ux-foundation.org,
ebiederm@...ssion.com, tytso@....edu, Trond.Myklebust@...app.com,
aelder@....com, hch@...radead.org, davem@...emloft.net,
netdev@...r.kernel.org, x86@...nel.org, mingo@...hat.com,
fweisbec@...il.com, dan.j.williams@...el.com,
borislav.petkov@....com, ying.huang@...el.com, lenb@...nel.org,
neilb@...e.de, cl@...ux-foundation.org
Subject: Re: [PATCHSET] percpu: add __percpu sparse annotations
On Tue, Jan 26, 2010 at 12:22:07AM +0900, Tejun Heo wrote:
> This patchset adds __percpu sparse annotations to all percpu users
> covered by x86_64 allmodconfig. __percpu annotation teaches sparse
> that percpu variables live in a separate address space and can't be
> accessed directly without going through percpu accessors. This allows
> detection of most percpu access mistakes involving both static and
> dyanmic percpu variables.
>
> This patchset contains the following eight patches.
>
> 0001-percpu-add-__percpu-sparse-annotations-to-core-kerne.patch
> 0002-percpu-add-__percpu-sparse-annotations-to-fs.patch
> 0003-percpu-add-__percpu-sparse-annotations-to-net.patch
> 0004-percpu-add-__percpu-sparse-annotations-to-net-driver.patch
> 0005-percpu-add-__percpu-sparse-annotations-to-x86.patch
> 0006-percpu-add-__percpu-sparse-annotations-to-trace.patch
> 0007-percpu-add-__percpu-sparse-annotations-to-hw_breakpo.patch
> 0008-percpu-add-__percpu-sparse-annotations-to-what-s-lef.patch
>
> As these annotations are for sparse, none of the above patches affects
> normal kernel build and most of the conversions are straight-forward
> and trivial. There are a few places where the conversion isn't
> completely straight-forward (but still fairly trivial). Those are
> mentioned in each patch description.
>
> I can route the patch through percpu and conflict resolution, if
> necessary, wouldn't be difficult at all for these changes. If anyone
> wants to route one of these patches through a different tree, please
> let me know. All that's necessary would be adding dummy __percpu
> definition to the patch.
>
> If nobody objects, I'll push these into percpu tree in three or four
> days.
Um. Where *is* the definition of __percpu? Presumably, that'd be
something like __attribute__((noderef,address_space(4)) under ifdef
__CHECKER__ and empty otherwise? If so, I'm fine with that patchset,
provided that it does grow that #define and becomes self-contained...
--
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