[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140224185341.GU8264@linux.vnet.ibm.com>
Date: Mon, 24 Feb 2014 10:53:41 -0800
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Torvald Riegel <triegel@...hat.com>,
Will Deacon <will.deacon@....com>,
Peter Zijlstra <peterz@...radead.org>,
Ramana Radhakrishnan <Ramana.Radhakrishnan@....com>,
David Howells <dhowells@...hat.com>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"mingo@...nel.org" <mingo@...nel.org>,
"gcc@....gnu.org" <gcc@....gnu.org>
Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
On Mon, Feb 24, 2014 at 10:14:01AM -0800, Linus Torvalds wrote:
> On Mon, Feb 24, 2014 at 9:21 AM, Paul E. McKenney
> <paulmck@...ux.vnet.ibm.com> wrote:
> >
> > 4. Bitwise operators ("&", "|", "^", and I suppose also "~")
> > applied to a chained pointer and an integer results in another
> > chained pointer in that same pointer chain.
>
> No. You cannot define it this way. Taking the value of a pointer and
> doing a bitwise operation that throws away all the bits (or even
> *most* of the bits) results in the compiler easily being able to turn
> the "chain" into a non-chain.
>
> The obvious example being "val & 0", but things like "val & 1" are in
> practice also something that compilers easily turn into control
> dependencies instead of data dependencies.
Indeed, most of the bits need to remain for this to work.
> So you can talk about things like "aligning the pointer value to
> object boundaries" etc, but it really cannot and *must* not be about
> the syntactic operations.
>
> The same goes for "adding and subtracting an integer". The *syntax*
> doesn't matter. It's about remaining information. Doing "p-(int)p" or
> "p+(-(int)p)" doesn't leave any information despite being "subtracting
> and adding an integer" at a syntactic level.
>
> Syntax is meaningless. Really.
Good points. How about the following replacements?
3. Adding or subtracting an integer to/from a chained pointer
results in another chained pointer in that same pointer chain.
The results of addition and subtraction operations that cancel
the chained pointer's value (for example, "p-(long)p" where "p"
is a pointer to char) are implementation defined.
4. Bitwise operators ("&", "|", "^", and I suppose also "~")
applied to a chained pointer and an integer for the purposes
of alignment and pointer translation results in another
chained pointer in that same pointer chain. Other uses
of bitwise operators on chained pointers (for example,
"p|~0") are implementation defined.
> > 8. Applying any of the following operators to a chained pointer
> > results in something that is not a chained pointer:
> > "()", sizeof, "!", "*", "/", "%", ">>", "<<", "<", ">", "<=",
> > ">=", "==", "!=", "&&", and "||".
>
> Parenthesis? I'm assuming that you mean calling through the chained pointer.
Yes, good point. Of course, parentheses for grouping just pass the
value through without affecting the chained-ness.
> Also, I think all of /, * and % are perfectly fine, and might be used
> for that "aligning the pointer" operation that is fine.
Something like this?
char *p;
p = p - (unsigned long)p % 8;
I was thinking of this as subtraction -- the "p" gets moduloed by 8,
which loses the chained-pointer designation. But that is OK because
that designation gets folded back in by the subtraction. Am I missing
a use case?
That leaves things like this one:
p = (p / 8) * 8;
I cannot think of any other legitimate use for "/" and "*".
Here is an updated #8 and a new 8a:
8. Applying any of the following operators to a chained pointer
results in something that is not a chained pointer: function call
"()", sizeof, "!", "%", ">>", "<<", "<", ">", "<=", ">=", "==",
"!=", "&&", "||", and "kill_dependency()".
8a. Dividing a chained pointer by an integer and multiplying it
by that same integer (for example, to align that pointer) results
in a chained pointer in that same pointer chain. The ordering
effects of other uses of infix "*" and "/" on chained pointers
are implementation defined.
Does that capture it?
Thanx, Paul
--
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