This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/11449] crypt/crypt_util.c: __init_des_r() needs memory barrier
- From: "drepper.fsp at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Sat, 23 Jul 2011 03:27:20 +0000
- Subject: [Bug libc/11449] crypt/crypt_util.c: __init_des_r() needs memory barrier
- Auto-submitted: auto-generated
- References: <bug-11449-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=11449
Ulrich Drepper <drepper.fsp at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #4 from Ulrich Drepper <drepper.fsp at gmail dot com> 2011-07-23 03:27:04 UTC ---
(In reply to comment #3)
> Now in Power-PC memory model, it is perfectly valid to execute read operations
> to different addresses out of order as long as there is no barrier in between
> them. Although thread 2 issues the instructions in order, it is possible that
> the second read (...= experm32tab[...]) will execute before the first read of
> the flag. This is shown here.
>
> Thread 1 Thread 2
> sb[sg][inx ] = eperm32tab[...];
> eperm32tab[..] |= BITMASK[bit % 24];
> atomic_write_barrier();
> small_tables_initialized = 1;
The only reason I made a change is because it doesn't disturb x86. Your models
need adjustment to reality since you completely ignore the memset calls.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.