FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-28-2010, 10:36 PM
Nicholas Miell
 
Default memcpy overlap: quickly detect, diagnose, work around

On 11/28/2010 03:13 PM, John Reiser wrote:
> The option to check is controlled by an environment variable
> MEMCPY_CHECK_ which influences choices made by __init_cpu_features
> and the STT_GNU_IFUNC mechanism for choosing alternate implementations
> at runtime.

If you're going to control it via an environment variable, why not just
make a LD_PRELOADed shared library which intercepts memcpy() in the
usual manner?

Doing it that way has the added benefit that anybody could use it
immediately, without needing to replace their glibc with a patched
version that will never get merged upstream.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-29-2010, 08:46 PM
Kevin Kofler
 
Default memcpy overlap: quickly detect, diagnose, work around

John Reiser wrote:
> This patch (with .rpms for x86_64 and i686) enables glibc optionally
> to detect, diagnose, and work around overlap in memcpy/mempcpy:
> http://bitwagon.com/glibc-memlap/glibc-memlap.html
> The option to check is controlled by an environment variable
> MEMCPY_CHECK_ which influences choices made by __init_cpu_features
> and the STT_GNU_IFUNC mechanism for choosing alternate implementations
> at runtime.

This does not work where the memcpy is inlined (which glibc can do in
several cases).

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-29-2010, 10:35 PM
John Reiser
 
Default memcpy overlap: quickly detect, diagnose, work around

On 11/28/2010 03:36 PM, Nicholas Miell wrote:
> On 11/28/2010 03:13 PM, John Reiser wrote:
>> The option to check is controlled by an environment variable
>> MEMCPY_CHECK_ which influences choices made by __init_cpu_features
>> and the STT_GNU_IFUNC mechanism for choosing alternate implementations
>> at runtime.
>
> If you're going to control it via an environment variable, why not just
> make a LD_PRELOADed shared library which intercepts memcpy() in the
> usual manner?
>
> Doing it that way has the added benefit that anybody could use it
> immediately, without needing to replace their glibc with a patched
> version that will never get merged upstream.

Using LD_PRELOAD is a good option in many cases. Having a built-in tool
can be more convenient, easier to use, and more likely to be used.
Using LD_PRELOAD often involves a trip through two PLTs (Program
Linkage Tables), each with an indirect JUMP. Often such a JUMP
takes many cycles. A builtin solution that enables using only one
indirect JUMP can be faster, enough to make a difference.

--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-29-2010, 10:35 PM
John Reiser
 
Default memcpy overlap: quickly detect, diagnose, work around

On 11/29/2010 01:46 PM, Kevin Kofler wrote:
> John Reiser wrote:
>> This patch (with .rpms for x86_64 and i686) enables glibc optionally
>> to detect, diagnose, and work around overlap in memcpy/mempcpy:
>> http://bitwagon.com/glibc-memlap/glibc-memlap.html
>> The option to check is controlled by an environment variable
>> MEMCPY_CHECK_ which influences choices made by __init_cpu_features
>> and the STT_GNU_IFUNC mechanism for choosing alternate implementations
>> at runtime.
>
> This does not work where the memcpy is inlined (which glibc can do in
> several cases).

Right. However, specifying the flag -fno-builtin-memcpy at compilation
disables gcc inlining of memcpy, thus exposing calls to memcpy that
can be checked. Also, a survey of recent versions of gcc indicates
that the inlining always copies in ascending address order (of both
source and destination.) While the details of inlining are subject
to change, copying in ascending address order is the order that is
assumed by all violators of the no-overlap requirement.

--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-29-2010, 10:44 PM
Matt McCutchen
 
Default memcpy overlap: quickly detect, diagnose, work around

On Sun, 2010-11-28 at 15:13 -0800, John Reiser wrote:
> This patch (with .rpms for x86_64 and i686) enables glibc optionally
> to detect, diagnose, and work around overlap in memcpy/mempcpy:
> http://bitwagon.com/glibc-memlap/glibc-memlap.html

What is the mass addition of commented curly braces for? It is
distracting from the substance of the patch.

diff --git a/sysdeps/x86_64/multiarch/strcmp.S b/sysdeps/x86_64/multiarch/strcmp.S
index 1859289..e014283 100644
--- a/sysdeps/x86_64/multiarch/strcmp.S
+++ b/sysdeps/x86_64/multiarch/strcmp.S
@@ -21,7 +21,7 @@
#include <sysdep.h>
#include <init-arch.h>

-#ifdef USE_AS_STRNCMP
+#ifdef USE_AS_STRNCMP /*{*/
/* Since the counter, %r11, is unsigned, we branch to strcmp_exitz
if the new counter > the old one or is 0. */
# define UPDATE_STRNCMP_COUNTER

(etc.)

--
Matt

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-29-2010, 10:47 PM
Gregory Maxwell
 
Default memcpy overlap: quickly detect, diagnose, work around

On Mon, Nov 29, 2010 at 6:35 PM, John Reiser <jreiser@bitwagon.com> wrote:
> While the details of inlining are subject
> to change, copying in ascending address order is the order that is
> assumed by all violators of the no-overlap requirement.

All violators? Citation needed.

I'm sure lurking somewhere there are ovelap copies which have no
'assumption' at all— some bad luck with arithmetic makes it ovelap
during some rare alignment of the stars... though cases like that
aren't going to be the ones that get inlined by GCC.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-29-2010, 10:47 PM
Gregory Maxwell
 
Default memcpy overlap: quickly detect, diagnose, work around

On Mon, Nov 29, 2010 at 6:35 PM, John Reiser <jreiser@bitwagon.com> wrote:
> While the details of inlining are subject
> to change, copying in ascending address order is the order that is
> assumed by all violators of the no-overlap requirement.

All violators? Citation needed.

I'm sure lurking somewhere there are ovelap copies which have no
'assumption' at all— some bad luck with arithmetic makes it ovelap
during some rare alignment of the stars... though cases like that
aren't going to be the ones that get inlined by GCC.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-29-2010, 11:08 PM
John Reiser
 
Default memcpy overlap: quickly detect, diagnose, work around

On 11/29/2010 03:44 PM, Matt McCutchen wrote:
> On Sun, 2010-11-28 at 15:13 -0800, John Reiser wrote:
>> This patch (with .rpms for x86_64 and i686) enables glibc optionally
>> to detect, diagnose, and work around overlap in memcpy/mempcpy:
>> http://bitwagon.com/glibc-memlap/glibc-memlap.html
>
> What is the mass addition of commented curly braces for? It is
> distracting from the substance of the patch.
>

> -#ifdef USE_AS_STRNCMP
> +#ifdef USE_AS_STRNCMP /*{*/
> /* Since the counter, %r11, is unsigned, we branch to strcmp_exitz
> if the new counter > the old one or is 0. */
> # define UPDATE_STRNCMP_COUNTER

Those comments enable parenthesis matching in some text editors.
The scoping of conditional compilation in sysdeps/x86_64/multiarch/strcmp.S
was complicated enough that I needed help figuring it out.
Indeed, it was complicated enough to help conceal a bug.

--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-30-2010, 12:29 AM
Matt McCutchen
 
Default memcpy overlap: quickly detect, diagnose, work around

On Mon, 2010-11-29 at 16:08 -0800, John Reiser wrote:
> On 11/29/2010 03:44 PM, Matt McCutchen wrote:
> > What is the mass addition of commented curly braces for? It is
> > distracting from the substance of the patch.

> Those comments enable parenthesis matching in some text editors.
> The scoping of conditional compilation in sysdeps/x86_64/multiarch/strcmp.S
> was complicated enough that I needed help figuring it out.
> Indeed, it was complicated enough to help conceal a bug.

I see. Still, you could split the patch into one that just adds
commented curly braces to existing code and a second with the
substantive changes, which would be easier for anyone interested to
review.

--
Matt

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-30-2010, 01:52 PM
Kevin Kofler
 
Default memcpy overlap: quickly detect, diagnose, work around

John Reiser wrote:
> Right. However, specifying the flag -fno-builtin-memcpy at compilation
> disables gcc inlining of memcpy

But not glibc's.

You need -D__NO_STRING_INLINES too. (That said, the most aggressive inlining
is disabled by default and only enabled if you use -D__USE_STRING_INLINES.)

In any case, it means you need to recompile the executables, not just drop
in the modified glibc.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 12:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org