Re: [RFC][PATCH 0/5] arch: atomic rework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxx> 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-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux