linux-kernel - Fwd: Unnecessary Relocation Hiding?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 25 Aug 2006 14:39:33 +0800
From:	"Dong Feng" <middle.fengdong@...il.com>
To:	"Paul Mackerras" <paulus@...ba.org>
Cc:	ak@...e.de, "Christoph Lameter" <clameter@....com>,
	linux-kernel@...r.kernel.org
Subject: Fwd: Unnecessary Relocation Hiding?

The mail was rejected by the list because I sent it in HTML format, my
fault. Resend it in plain-text and you can delete the version you do
not like.

I put my understanding below for your confirm or correcting, ...

Once I get a C pointer, say "some_type_t * ptr;" ...

1. If I want to treat it as an ordinary C array and retrieve elements
from it, then plain pointer addition is OK. Like this:

some_type_t * ptr1 = ptr + 2;

2. If I want to add some offset to it (that is, the ptr need to be
converted to _void *_ or _unsigned long_ before manipulated), and the
offset does not exceed sizeof(some_type_t), then plain C addtion is
OK. Like this:

unsigned long raw_addr = (unsigned long)ptr;
int *second_mem = raw_addr + sizeof(int);  // as long as the
sizeof(int) less than
                                                               // the
sizeof(some_type_t), for example,
                                                               //
some_type_t really has two members and the
                                                               // the
first is really an integer.

3. If I want to add some offset to it (after converted to _void *_ or
_unsigned long_). However, the offset exceed sizeof(some_type_t). In
this case, gcc still (mis-)assume that I would want to do the same
thing as case 2 (but I am not actually). In this case, I have to use
RELOC_HIDE. And this is exactly what per_cpu() going to do.

== the end of the description of my understanding ==

Thanks.
Feng,Dong

2006/8/25, Paul Mackerras <paulus@...ba.org>:
> Dong Feng writes:
>
> > Sorry for perhaps extending the specific question to a more generic
> > one. In which cases shall we, in current or future development,
> > prevent gcc from knowing a pointer-addition in the way RELOC_HIDE? And
> > in what cases shall we just write pure C point addition?
>
> Where you are saying to gcc "you think this variable is at this
> address, but I know it's actually at this other address over here" you
> should use RELOC_HIDE.  Where the addition is being used to get the
> address of some part of the object (so the resulting address is still
> within the object) you can just use plain addition.
>
> 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/