linux-kernel - Re: Is gcc thread-unsafe?

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e2e108260710261007n118186b5geb3a48094638497f@mail.gmail.com>
Date:	Fri, 26 Oct 2007 19:07:14 +0200
From:	"Bart Van Assche" <bart.vanassche@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Andrew Haley" <aph@...hat.com>
Subject: Re: Is gcc thread-unsafe?

On 10/26/07, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
> On Fri, 26 Oct 2007, Linus Torvalds wrote:
> >
> > On Fri, 26 Oct 2007, Bart Van Assche wrote:
> > >
> > > You can find my proposal to improve gcc here:
> > > http://gcc.gnu.org/ml/gcc/2007-10/msg00465.html
> >
> > Btw, I think this is fine per se, but putting "__attribute__((acquire))"
> > on the functions that acquire a lock does seem to be problematic, in that
> > quite often you might well want to inline those things. How would you
> > handle that?
>
> Thinking some more about this, you really have two cases:
>  - full functions taking/releasing locks (possibly conditionally, ie
>   with something like trylock and/or based on argument values).
>
>   You simply *cannot* require these to be marked, because the locking may
>   have been done indirectly. Yes, you can mark things like
>   "pthread_mutex_trylock()" as being an acquire-function, but the fact
>   is, users will then wrap these things in *other* functions, and return
>   their return values.
>
>   Ergo: a compiler *must* assume that a function call that it
>   didn't inline involves locking. There's no point in adding some
>   gcc-specific attributes to system header files, because it's not going
>   to fix anything in any portable program.

You have a point here.

>  - inline assembly (together with, potentially, compiler primitives).
>    That's the only other way to reliably do locking from C.
>
>    This one gcc could certainly extend on. But would there really be any
>    upside? It would be easier/better to say that inline assembly (at least
>    if it clobbers memory or is volatile) has the same serialization issues
>    as a function call.

A problem is that the serialization properties defined for functions
in the C standard only apply to volatile variables, not to
non-volatile variables. But for asm statements this can be solved by
adding memory to the list of clobbered registers -- this will prevent
any reordering of manipulations of non-volatile variables and asm
statements.

Andrew, do you know whether gcc currently contains any optimization
that interchanges the order of accesses to non-volatile variables and
function calls ?

> So the fact is, any compiler that turns
>
>         if (conditional)
>                 x++;
>
> into an unconditional write to x (where 'x' is potentially visible to the
> outside - global visibility or has had its address taken) is just broken.
>
> No ifs, buts or maybes about it. You simply cannot do that optimization,
> because there is no way for the compiler to know whether the conditional
> implies that you hold a lock or not.

I agree with the above, but I see this as a different issue -- it
wasn't my intention to solve this with my proposal for acquire and
release attributes.

Bart Van Assche.
-
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/