[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100126035658.GE19799@ZenIV.linux.org.uk>
Date: Tue, 26 Jan 2010 03:56:58 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Tejun Heo <tj@...nel.org>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Frederic Weisbecker <fweisbec@...il.com>,
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,
dan.j.williams@...el.com, borislav.petkov@....com,
ying.huang@...el.com, lenb@...nel.org, neilb@...e.de,
cl@...ux-foundation.org
Subject: Re: [PATCH 7/8] percpu: add __percpu sparse annotations to
hw_breakpoint
On Tue, Jan 26, 2010 at 12:10:51PM +0900, Tejun Heo wrote:
> Hello,
>
> On 01/26/2010 11:48 AM, Al Viro wrote:
> > On Tue, Jan 26, 2010 at 11:43:56AM +0900, Tejun Heo wrote:
> >
> >>> Eh... You are leaving that noderef in place in case of array. And _that_
> >>> is not an address space, so casts to AS 0 won't do you any good.
> >>
> >> Any ideas on how to fix it?
> >
> > BTW, before we go any further, which warnings are you getting from sparse
> > and which version of sparse are you using?
> >
> > noderef is one thing; address_space mess is a different story. The version
> > I have here steps into the former, but not the latter; what are you seeing?
>
> Oops, I too am seeing the noderef thing not the address space warning.
OK... So all messing around __kernel __force is actually a red herring.
Frankly, for now I'd keep it as in your patch. Yes, including workarounds
in these few places. Longer term... We probably want to implement
__attribute__((qualify(...)))/__attribute__((unqualify(...))), revert
__typeof__ for AS/noderef to what gcc is doing for normal qualifiers
(i.e. "if p is int const *, typeof(*p) v gives const int") go for explicit
__unqualify((address_space,noderef)) in there. Playing interesting games
with arrays for unqualify (i.e. creating parallel chains of type nodes
all way down to the place where original qualifier had been applied).
--
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