[Bug nptl/13165] New: pthread_cond_wait() can consume a signal that was sent before it started waiting

[Bug nptl/13165] New: pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

             Bug #: 13165
           Summary: pthread_cond_wait() can consume a signal that was sent
                    before it started waiting
           Product: glibc
           Version: 2.14
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: mihaylov.mihail@gmail.com
    Classification: Unclassified


I was implementing something like a monitor on top of pthread condition
variables and I observed some strange behaviour. I was always holding the mutex
when calling pthread_cond_signal(). My code relied on only two assumptions
about the way pthread_cond_signal() works:

1) A call to pthread_cond_signal() will wake at least one thread which is
blocked on the condition, and the woken threads will start waiting on the
mutex.

2) If the signaling thread holds the mutex when it calls pthread_cond_signal(),
only threads which are already waiting on the condition variable may be woken.
In particular, if the signaling thread releases the mutex and then another
thread acquires the mutex and calls pthread_cond_wait(), the waiting thread
cannot be woken by this signal, no matter what other waiters are present before
or after the signal.

The only explanation that I could find for the observed behaviour was that my
second assumption was wrong. It seemed that I was hitting the following
scenario:

1) We have several threads which are blocked on the condvar in
pthread_cond_wait(). I'll call these threads "group A".

2) We then send N signals from another thread while holding the mutex. We are
releasing the mutex and acquiring it again between the signals.

3) Next we have several more threads (at least two) that acquire the mutex and
enter pthread_cond_wait(). I'll call these threads "group B"

4) Then we acquire the mutex in the signaling thread again and call
pthread_cond_signal() just once, then we release the mutex.

5) Two threads from group B wake up, and N-1 threads from group A wake up. In
effect one of the threads from group B has stolen a signal that was sent before
it started waiting from a thread from group A.

My expectation in this scenario is that at least N threads from group A should
wake up. I don't expect that exactly one thread from group B should wake up,
because spurious wakeups are possible. But this is not a spurious wakeup - I
have N signals, and N woken threads, it's just that the order is wrong.

I ran some experiments and they seemed to confirm my theory, so I looked at the
condvar implementation in nptl. I'm new to POSIX and Linux programing, but I
think I see how this can happen:

1) When we send the first N signals, N threads from group A that are waiting on
the cond->__data.__futex are woken and start waiting on cond->__data.__lock.

2) Then while the threads from group B enter pthread_cond_wait, some of the
woken threads from group A may remain waiting on the lock.

3) When we send the last signal, one thread from group B will wake and consume
this signal.

4) But suppose one more thread from group B wakes spuriously from
lll_futex_wait. At this moment it is possible that some of the woken threads
from group A will still be waiting on cond->__data.__lock. In that case the
spuriously woken thread from group B will see that cond->__data.__wakeup_seq
has changed (because of the last signal) and cond->__data._woken_seq has not
reached cond->__data.__wakeup_seq (because some of the woken threads in group A
are still waiting to acquire cond->__data.__lock), so it will exit the retry
loop and increase cond->__data.__woken_seq. The result is that the thread will
steal the signal.

Is this scenario really possible? And if it is, is this on purpose or is it a
bug?

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #1 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2011-09-21 09:12:26 UTC ---
It's been two weeks with no update on the bug. There is no way to tell if
someone has noticed it at all.

Is it possible to have at least some statement as of if this is considered a
valid bug that might be addressed at some point in the future?

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> 2011-09-21 18:18:43 UTC ---
I've waited months for a response to some of my bug reports for NPTL, all race
conditions, some of which make it impossible to use major features like
cancellation in a robust program. Nothing. Good luck, but don't hold your
breath. The best thing I can recommend to you is cross-posting the bug report
to distros' bug trackers, and getting other people interesting these issues to
follow up on the bug tracker with confirmations that they can reproduce it.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> 2011-09-21 22:29:21 UTC ---
Can you explain how you know (2) is completed before (3) occurs, in your
scenario? If there's no synchronization to order these steps, then isn't it
possible that one or more of the signals happens after a thread from group B is
waiting?

If you have a minimal self-contained test case for the issue, I'd be interested
in seeing it.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #4 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2011-09-22 22:21:10 UTC ---
Thank you for taking an interest in this issue.

(In reply to comment #3)
> Can you explain how you know (2) is completed before (3) occurs, in your
> scenario? If there's no synchronization to order these steps, then isn't it
> possible that one or more of the signals happens after a thread from group B is
> waiting?

Basically, because we are holding the mutex when signaling, we can tell exactly
which threads started waiting after we finished sending the first N signals.
These are the threads that I call "group B", so by this definition they cannot
start waiting before all signals from step 2 have been sent.

What I'm trying to say is that the scenario is not a test case, but rather a
hypothetical  sequence of events that can happen and can be observed, so it
doesn't specify why exactly no new threads started waiting during step 2, it
just says what happened. This left some ambiguity in my description.

One way to resolve this ambiguity is to say that if during step 2 some threads
acquired the mutex and called pthread_cond_wait(), they should be counted
towards group A.

Another way is to change step 2 and say that the signaling thread acquired the
mutex, sent N signals and only then released the mutex, without releasing it
between the signals.

The second way seems simpler and will probably make the race more likely, but
the first is closer to what I actually observed.

> If you have a minimal self-contained test case for the issue, I'd be interested
> in seeing it.

I don't have such a test case, but I'll try to find time in the next days to
write one and attach it to the bug.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #5 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2011-09-25 21:32:35 UTC ---
Created attachment 5945
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5945
Test to observe the race

Attaching a self contained test. What the test does:

We have a mutex and a condition variable. We also have several auxiliary
condition variables and counters.

The main thread locks the mutex and creates as many waiter threads as possible.
The waiter threads start by waiting on the mutex. Then both the main thread and
the waiter thread start looping to perform iterations of the test until the
race condition in NPTL is hit.

The loops of the main thread and the waiter threads are synchronized and go
like this:

1) The main thread starts by releasing the mutex and blocking on an auxiliary
condvar. This unblocks the waiter threads which start by entering the first
wait on the condition variable. Each waiter thread increments a waiters counter
before waiting and the last one also signals the auxiliary condvar to notify
the main thread that all waiters are blocked on the first wait.

2) When all waiters are blocked on the first wait, the main thread is unblocked
and starts sending signals. It sends as many signals as there are waiters, so
all waiters should move (eventually) beyond the first wait. The main thread
holds the mutex while sending the signals. The 'releaseMutexBetweenSignals'
constant controls whether it will release and reacquire the mutex between
signals.

3) Each unblocked waiter decrements the waiters counter and moves to the second
wait. To simplify the test, the waiters don't enter the second wait until all
signals from step 2 have been sent. This is controlled through a sent signals
counter and another auxiliary condvar.

4) After the main thread has sent all signals, it starts waiting for at least
two waiters to block on the second wait. This is facilitated by a counter of
the threads that have reached the second wait and one more auxiliary condvar.

5) When at least two threads have blocked on the second wait, the main thread
sends one more signal. Threads that get unblocked from the second wait may
start a third wait to allow the test iteration to complete before they loop
back to the first wait (of course this actually happens when the main thread
releases the mutex in step 6)

6) The main thread starts waiting for all waiters to exit the first wait. Each
waiter that exits the first wait decrements the waiters count and the last one
signals the last auxiliary condvar that the main thread waits on. If the wait
times out, the test has failed, otherwise it has passed.

7) If the test has passed, all waiters are waiting on the condition variable in
the second wait or the third wait, so the main thread sends a broadcast to
unblock them and all waiters move back to the first wait. With this the test
iteration is complete and a new iteration begins.


The main point about this test is that at the point where the main thread sends
the single signal, all waiters should be:

1) either waiting on the mutex in the first wait,
2) or waiting on the condition variable in the second wait,
3) or waiting on the mutex in the wait on the auxiliary condvar from step 3

which means that if the mutex gets released for long enough, all threads should
acquire the mutex in the first wait and the waiters count should eventually
reach zero. Step 6 is meant to provide this time. At step 6, the main thread
releases the mutex and starts waiting, and all waiters that acquire the mutex
release it almost immediately and start waiting themselves, so there is nothing
to prevent the threads from group (1) above from acquiring the mutex one by one
and bringing the waiters counter back to 0. The only thing that can get in the
way is if there is a waiter which is still blocked on the condition variable in
the first wait, which is what the test aims to trigger and detect.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #6 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2011-09-25 21:43:17 UTC ---
(In reply to comment #3)
> If you have a minimal self-contained test case for the issue, I'd be interested
> in seeing it.

I wrote a self-contained test case. It is not very simple, and may seem
contrived. My real code is actually much simpler (just one condition variable),
but it is not suitable as a test.

I ran the test on my dual-core laptop and had consistent results of one stolen
signal. I guess that with more cores it will be possible for more signals to be
stolen. Typically it took from 3 to 40 iterations to hit the race.

I would appreciate your feedback.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #7 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2011-09-26 09:13:37 UTC ---
I ran the test on my workstation too. It took much longer to hit the race. The
difference is that on my workstation a process can start over 30000 threads as
opposed to about 400 on my laptop. Limiting the number of created threads to
several hundred made the race much easier to hit.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> 2011-09-26 16:19:50 UTC ---
Could you simplify it? I'm not sure why the test has to be so much more
complicated than your real code. If you think there's a race/bug in cond vars,
then it's probably not a good idea to be using cond vars in the logic for the
test loop, since it will be hard to tell if the bug is occurring in the tested
code or the control code. Perhaps you could use barriers or semaphores to
synchronize the test control logic, if needed. Personally barriers are my
favorite synchronization primitive for that sort of thing.

Also, yes, get rid of the "make as many threads as possible" logic. That will
not make it any easier to find the race, and the limit to how many threads you
can make is usually dependent on available memory/virtual address space, not
kernel thread resources. Just pick a "sane" number (probably below 100) and go
with it.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #9 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2011-09-27 10:10:23 UTC ---
Created attachment 5946
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5946
Simpler test to observe the race

This is a much simpler test case that demonstrates the race. The logic is
pretty much the same as with the previous test but it doesn't use any auxiliary
condition variables.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #10 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2011-09-27 10:13:25 UTC ---
(In reply to comment #8)
> Could you simplify it? I'm not sure why the test has to be so much more
> complicated than your real code. If you think there's a race/bug in cond vars,
> then it's probably not a good idea to be using cond vars in the logic for the
> test loop, since it will be hard to tell if the bug is occurring in the tested
> code or the control code. Perhaps you could use barriers or semaphores to
> synchronize the test control logic, if needed. Personally barriers are my
> favorite synchronization primitive for that sort of thing.
> 
> Also, yes, get rid of the "make as many threads as possible" logic. That will
> not make it any easier to find the race, and the limit to how many threads you
> can make is usually dependent on available memory/virtual address space, not
> kernel thread resources. Just pick a "sane" number (probably below 100) and go
> with it.

I simplified the test significantly as you suggested. Now its somewhat simpler
than my actual code.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #11 from Rich Felker <bugdal at aerifal dot cx> 2011-09-28 02:06:54 UTC ---
I've confirmed that the issue occurs on my Debian system with their libc6
package (eglibc 2.13-10, albeit slightly different from glibc). I've also
confirmed that the issue does not occur with my implementation of condition
variables in musl libc(*). I suspect it's a real bug, but I need to read the
code more closely to understand what's going on...

(*) I've converted the test to C (just replaced cout with printf) so I can run
it without C++ support. I'm attaching the modified version.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #12 from Rich Felker <bugdal at aerifal dot cx> 2011-09-28 02:08:00 UTC ---
Created attachment 5947
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5947
Simpler test, converted to pure C

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #13 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2011-09-28 09:02:51 UTC ---
(In reply to comment #11)
> I've confirmed that the issue occurs on my Debian system with their libc6
> package (eglibc 2.13-10, albeit slightly different from glibc).

I originally observed the problem on a Debian stable. I've run my test case on
my laptop which is running Mint and on my office workstation which is running
kubuntu.

I looked at the eglibc source code before posting the bug and saw that the code
which causes the race is identical to the one in glibc, so the bug is in both
implementations.

> I've also confirmed that the issue does not occur with my implementation of
> condition variables in musl libc(*).

I took a look at your code. As far as I can tell, you are not trying to avoid
spurious wakeups as hard as glibc, that's why you don't have the same race.

> I suspect it's a real bug, but I need to read the code more closely to
> understand what's going on...

Here is my understanding of the root cause - an attempt to prevent spurious
wakeups that has gone too far and destroys ordering - waking future waiters
instead of present ones.

There are two checks that NPTL uses to prevent spurious wakeups:

1) It only allows a thread to wake if a signal has been sent after it started
waiting. This is achieved by checking if cond->__data.__wakeup_seq has remained
unchanged.

2) It only allows as many threads to wake up as there were signals. This is
achieved by checking if cond->__data._woken_seq equals
cond->__data.__wakeup_seq.

If any of this checks indicates a spurious wakeup the thread retries the wait.

The problem is in check 2, because the guard is triggered if any thread has
woken spuriously - not just the current thread. Worse - it is triggered only
after the spuriously woken thread consumed a signal. So in many cases the
spuriously woken thread consumes the signal, and a validly woken thread is
forced to retry. The result is that a spurious wakeup may steal signals that
were sent before it started waiting.

Now, I'm confident that the race is real. But maybe some people would disagree
that it is a bug. That's why I asked in my original message if this behaviour
is intentional or a bug.

It is a bug if pthread condition variables should support the following usage: 

   ...

   pthread_mutex_lock(&m);

   SomeType localState = f(sharedState);

   while ( predicate(sharedState, localState) ) {
      pthread_cond_wait(&c, &m);
   }

   ...

In this case it actually matters which thread will wake up, because if the
wrong thread wakes up, it will retry the wait and the signal will be lost (this
is what happened to me). Unfortunately the spec is not very clear on the issue.
But this is the pattern that the pthread_cond_wait implementation in glibc
itself uses to detect spurious wakeups on the futex.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #14 from Rich Felker <bugdal at aerifal dot cx> 2011-09-28 16:06:21 UTC ---
I think it's clear that the usage you describe needs to be supported. Nowhere
does the standard state that predicate must be a pure function of the shared
(mutex-protected) state, or that it even need to depend on the shared state
whatsoever. For example, this is a valid albeit potentially stupid use of cond
variables:

Thread 1:

Lock mutex.
Create thread 2.
Wait on cond var.
Unlock mutex.
Continue with other work.

Thread 2:

Lock mutex.
Signal cond var.
Unlock mutex.
Continue with other work.

There is no guarantee that thread 1 will actually block until thread 2 starts
and signals (it could have a spurious wakeup), but there is a guarantee that
the signal will cause a wakeup if one has not already occurred. Naturally this
example is not analogous to your test (there's nobody else using the cond var),
but the point is that it's valid to use cond vars even without predicates. If
you read the language of the standard, which is in terms of threads currently
blocked rather than predicates, it's clear.

By the way, assuming spurious wakeups are rare, my above "stupid" use of cond
vars may actually be an efficient way to roughly synchronize typical start
times of parallel calculations, perhaps useful in benchmarks or in tweaking
cache utilization for a particular machine. Barriers would probably be more
appropriate, however.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #15 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2011-09-28 20:59:15 UTC ---
Well, you don't need to convince me. I think this is a bug too. But based on
how Ulrich Drepper responded to Bug 12875, he might claim that this is not a
bug either. Bug 12875 is almost certainly a manifestation of the same race.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[triegel at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |triegel at redhat dot com

--- Comment #16 from Torvald Riegel <triegel at redhat dot com> 2012-09-19 15:15:02 UTC ---
I'm not aware of any requirement that pthread_cond_signal should block until a
waiter has actually woken up. (Your test case relies on it to not block, so
that it can send out multiple signals while holding the mutex, right?)  I'm
also not aware of any ordering requirement wrt. waiters (i.e., fairness).  If
you combine both, you will see that the behavior you observe is a valid
execution.

(In reply to comment #5)
> 4) After the main thread has sent all signals, it starts waiting for at least
> two waiters to block on the second wait. This is facilitated by a counter of
> the threads that have reached the second wait and one more auxiliary cond var.

And here you do block for waiters to have consumed a signal (i.e., for a call
to pthread_cond_signal to have finished its work and delivered a signal), but
you do this just for two of the signals / calls.

If you do not want to wait for all signals being delivered yet still need a
fair cond var implementation, I suggest either (1) building your own (e.g., you
could build something like a simple queue lock based on pthread mutexes or cond
vars) or (2) propose an addition of a fair cond var to glibc or the respective
standards bodies.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[triegel at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #17 from Torvald Riegel <triegel at redhat dot com> 2012-09-19 15:20:45 UTC ---
(In reply to comment #13)
> It is a bug if pthread condition variables should support the following usage: 
> 
>    ...
> 
>    pthread_mutex_lock(&m);
> 
>    SomeType localState = f(sharedState);
> 
>    while ( predicate(sharedState, localState) ) {
>       pthread_cond_wait(&c, &m);
>    }
> 
>    ...
> 
> In this case it actually matters which thread will wake up, because if the
> wrong thread wakes up, it will retry the wait and the signal will be lost (this
> is what happened to me). Unfortunately the spec is not very clear on the issue.

If the spec doesn't guarantee something, it's usually best to not depend on
this.

> But this is the pattern that the pthread_cond_wait implementation in glibc
> itself uses to detect spurious wakeups on the futex.

Not quite.  For one, pthread_cond_wait doesn't try to establish the ordering
that you seem to depend on the piece of code above.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #18 from Rich Felker <bugdal at aerifal dot cx> 2012-09-19 17:23:20 UTC ---
> I'm not aware of any requirement that pthread_cond_signal should block until a
> waiter has actually woken up. (Your test case relies on it to not block, so

Do you mean "should block" or "should not block"? POSIX's definition of threads
has general language that requires that forward process be possible, and
blocking in pthread_cond_signal until a waiter actually wakes up (including
acquiring the mutex) would be non-conformant; in fact it would be a guaranteed
deadlock.

> that it can send out multiple signals while holding the mutex, right?)  I'm

It is definitely required that pthread_cond_signal can be called more than
once.

> also not aware of any ordering requirement wrt. waiters (i.e., fairness).  If
> you combine both, you will see that the behavior you observe is a valid
> execution.

Nobody has asked for glibc to satisfy any fairness constraint. The standard
says it shall unblock at least one thread that "has blocked" on the condition
variable, not that it can randomly fail to do so or instead send the unblocking
event into the future to be consumed by another thread that has not yet blocked
but is about to block (after the signaling thread unlocks the mutex). The claim
in this bug report is that glibc is randomly failing (race condition) to
unblock ANY of the threads that have blocked. A viable mechanism of how this
failure is occurring has also been proposed.

You are free to test this hypothesis and claim that this is not what's
happening, or provide a rigorous proof that it couldn't happen. But what you've
been doing so far is mischaracterizing the bug report and my comments as a
complaint about scheduling fairness, which they are not, and this is getting
really frustrating...

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #19 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2012-09-20 10:21:39 UTC ---
(In reply to comment #16)
Sorry for the long reply. Please, bare with me, because this issue is very
subtle and I don't know how to explain it more succinctly.

First of all, let me clarify that this is a test that exposes the race, and not
the usage scenario that I claim should be supported. The usage scenario is
described in the bug description. Well, actually, I do claim that the scenario
in the test should be supported too, but the scenario in the description makes
more sense.

> I'm not aware of any requirement that pthread_cond_signal should block until a
> waiter has actually woken up. (Your test case relies on it to not block, so
> that it can send out multiple signals while holding the mutex, right?)  I'm
> also not aware of any ordering requirement wrt. waiters (i.e., fairness).  If
> you combine both, you will see that the behavior you observe is a valid
> execution.

I'm not making any assumptions about the state of the waiters when
pthread_cond_signal returns. All I'm assuming is that, no matter if the
signaling thread releases and reacquires the mutex after each sent signal or
sends all signals without releasing the mutex, at least as many waiters as the
number of signals will wake (eventually).

But even if this assumption is wrong (and it's not), if you set
releaseMutexBetweenSignals to true, the test will release the mutex after each
sent signal. In this case the test doesn't send multiple signals while holding
the mutex, and the problem still occurs.

As for fairness, this is not about fairness. It is also not about ordering
between the waiters. It's about ordering between waiters and signalers.

I'm getting tired of people jumping to fairness at the first mention of
ordering. You could say that I'm requesting fairness if I wanted the first
single signal to wake the waiter that blocked first. But all I'm requesting is
for the signal to wake at least one of the waiters that started waiting before
the signal was sent. I don't care which one of them.

This is guaranteed by the standard (from the documentation of pthread_cond_wait
and pthread_cond_signal on the opengroup site):

"The pthread_cond_signal() function shall unblock at least one of the threads
that are blocked on the specified condition variable cond (if any threads are
blocked on cond)."

And I think the next quote makes it very clear what threads are considered to
be blocked on the condvar at the time of the call to pthread_cond_signal():

"That is, if another thread is able to acquire the mutex after the
about-to-block thread has released it, then a subsequent call to
pthread_cond_broadcast() or pthread_cond_signal() in that thread shall behave
as if it were issued after the about-to-block thread has blocked."

In effect this means that each call to pthread_cond_signal() defines a point in
time and all waiters (or calls to pthread_cond_wait() if you prefer) are either
before this call, or after it. And only the ones that are before it are allowed
to consume the signal sent by this call.

Now, of course in a multiprocessor system it is hard to order events in time,
but that's where the mutex comes in. And if the signaling thread sends multiple
signals while holding the mutex, we can consider all these signals to be
simultaneous. But that doesn't change the validity of the test.

On the other hand, the standard doesn't guarantee that there won't be spurious
wakeups. However, glibc tries to prevent them. But the logic for this
prevention is flawed and causes the race that this bug is about.

So the net result is that glibc chose to provide a feature that is not
required, but dropped a much more important feature which is actually required.
Hence, this bug is not a fairness feature request, it is a correctness defect
report.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[triegel at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #20 from Torvald Riegel <triegel at redhat dot com> 2012-09-20 10:43:00 UTC ---
(In reply to comment #18)
> > I'm not aware of any requirement that pthread_cond_signal should block until a
> > waiter has actually woken up. (Your test case relies on it to not block, so
> 
> Do you mean "should block" or "should not block"?

"Block", as I wrote.

> POSIX's definition of threads
> has general language that requires that forward process be possible, and
> blocking in pthread_cond_signal until a waiter actually wakes up (including
> acquiring the mutex) would be non-conformant; in fact it would be a guaranteed
> deadlock.

That's what I'm pointing out.  Glad you agree on this point.

> 
> > that it can send out multiple signals while holding the mutex, right?)  I'm
> 
> It is definitely required that pthread_cond_signal can be called more than
> once.
> 
> > also not aware of any ordering requirement wrt. waiters (i.e., fairness).  If
> > you combine both, you will see that the behavior you observe is a valid
> > execution.
> 
> Nobody has asked for glibc to satisfy any fairness constraint.

Glad you agree on that too. Now please just think about the combination of both
for a minute.

> The standard
> says it shall unblock at least one thread that "has blocked" on the condition
> variable, not that it can randomly fail to do so or instead send the unblocking
> event into the future to be consumed by another thread that has not yet blocked
> but is about to block (after the signaling thread unlocks the mutex).

You assume that only some threads can count as blocked, which is not guaranteed
by the standard. Signalers are not required to have finished delivering the
signal when they return.  Thus, the scope of which threads are blocked can be
longer than you assume.  Combined with no fairness guarantee this exactly
allows the behavior that we're talking about here.

The standard indeed doesn't talk about the "future".  It doesn't make a sort of
lower-bound requirement on which threads have to be considered blocked, but no
upper bound.  If you think there's an upper bound, please point the requirement
in the standard.  If there is no required upper bound, it's up to the
implementation how to deal with that.

> The claim
> in this bug report is that glibc is randomly failing (race condition) to
> unblock ANY of the threads that have blocked.

No.  The claim is that the "wrong" threads have been unblocked, where "wrong"
is based on an assumption on ordering or an upper-bound-on-blocked-threads
guarantee that is not required by the standard.

> A viable mechanism of how this
> failure is occurring has also been proposed.
> 
> You are free to test this hypothesis and claim that this is not what's
> happening, or provide a rigorous proof that it couldn't happen.

I have argued that this is allowed behavior, because there is no requirement
that conflicts with it, and pointed out why.  You haven't done that; just
because you think the standard should have a certain requirement doesn't mean
it actually has.

> But what you've
> been doing so far is mischaracterizing the bug report and my comments as a
> complaint about scheduling fairness, which they are not, and this is getting
> really frustrating...

I've never talked about "scheduling fairness" (assuming you mean the OS
scheduler here), just about fairness regarding which thread gets wakened. So
much for mischaracterization, eh?

Sorry to hear that you feel frustrated, but I'd like to point out that I don't
think that I'm the cause for this.

Bottom line: In my opinion, this is not a bug.  However, it might be good to
explain why this behavior is allowed (e.g., somewhere in the docs or on the
wiki), so that this doesn't surprise other users.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #21 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2012-09-20 11:05:21 UTC ---
(In reply to comment #20)
> The standard indeed doesn't talk about the "future".  It doesn't make a sort of
> lower-bound requirement on which threads have to be considered blocked, but no
> upper bound.  If you think there's an upper bound, please point the requirement
> in the standard.  If there is no required upper bound, it's up to the
> implementation how to deal with that.

"The pthread_cond_broadcast() and pthread_cond_signal() functions shall have no
effect if there are no threads currently blocked on cond."

How about this as an upper bound? If implementations are allowed to determine
the set of blocked threads at any point in time they see fit, there would be no
way to define "currently blocked" at all and this sentence couldn't make any
sense.

And also:

".... however, if predictable scheduling behavior is required, then that mutex
shall be locked by the thread calling pthread_cond_broadcast() or
pthread_cond_signal()."

If I accept your argument, there will be no way to determine at least a set of
threads from which the woken thread will be chosen, so why does the standard
talk about predictability?

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[triegel at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #22 from Torvald Riegel <triegel at redhat dot com> 2012-09-20 11:22:45 UTC ---
(In reply to comment #19)
> (In reply to comment #16)
> Sorry for the long reply. Please, bare with me, because this issue is very
> subtle and I don't know how to explain it more succinctly.

No worries.  If it would be straight-forward, we wouldn't be talking about it
here :)

> 
> First of all, let me clarify that this is a test that exposes the race, and not
> the usage scenario that I claim should be supported. The usage scenario is
> described in the bug description. Well, actually, I do claim that the scenario
> in the test should be supported too, but the scenario in the description makes
> more sense.

I think your test is good and helps to point out the issue (including,
actually, why it's not a bug).  In your comment #1, I agree on assumption 1),
but not on assumption 2). The latter (2) is not required by the standard.

> > I'm not aware of any requirement that pthread_cond_signal should block until a
> > waiter has actually woken up. (Your test case relies on it to not block, so
> > that it can send out multiple signals while holding the mutex, right?)  I'm
> > also not aware of any ordering requirement wrt. waiters (i.e., fairness).  If
> > you combine both, you will see that the behavior you observe is a valid
> > execution.
> 
> I'm not making any assumptions about the state of the waiters when
> pthread_cond_signal returns.

You do assume that only those will be associated with this particular signal
call.  We can argue that whether this is part of the state of waiters or not,
but I hope you'll agree that it's at least a property that the waiters are part
of.

> All I'm assuming is that, no matter if the
> signaling thread releases and reacquires the mutex after each sent signal or
> sends all signals without releasing the mutex, at least as many waiters as the
> number of signals will wake (eventually).

This assumption is correct, but you assume more:  That only the threads before
cond_signal returns will be considered as blocked.

So, if you have waiters W and signal S, and an execution of (W1->W2->S->W3),
then the standard requires that W1 and W2 need to be considered as blocked
threads by S.  It does not require that W3 is _not_ considered as a blocked
thread.

Informally, S is required to be ordered after W1 and W2, but it is unspecified
whether it is ordered before W3. S does not block; it is like starting an
asynchronous operation that will eventually deliver a signal.  S can return
earlier, and the earlier return can happen before W3, but that doesn't mean
anything for the delivery of the signal.

> But even if this assumption is wrong (and it's not), if you set
> releaseMutexBetweenSignals to true, the test will release the mutex after each
> sent signal. In this case the test doesn't send multiple signals while holding
> the mutex, and the problem still occurs.
> 
> As for fairness, this is not about fairness. It is also not about ordering
> between the waiters. It's about ordering between waiters and signalers.

The ordering between waiters and signalers is the first point, which I
illustrated with "signalers don't block for waiters".  After that, we have the
problem of which of the blocked threads the signal chooses to wake up, so this
becomes an ordering problem (i.e., a selection problem if applied
continuously). On an abstract level, this is a typical fairness problem.

As I pointed out, it's the combination of both these issues.

> I'm getting tired of people jumping to fairness at the first mention of
> ordering.

If you're tired, get some sleep before suggesting that the participants of this
discussion don't understand ordering.

> You could say that I'm requesting fairness if I wanted the first
> single signal to wake the waiter that blocked first. But all I'm requesting is
> for the signal to wake at least one of the waiters that started waiting before
> the signal was sent. I don't care which one of them.

That's the first wrong assumption ("before the signal" [call returned]).  If
you don't make that incorrect assumption, then it becomes a fairness issue
among classes of waiters, where the classes are defined by whether they
happened before a certain signal call.

> This is guaranteed by the standard (from the documentation of pthread_cond_wait
> and pthread_cond_signal on the opengroup site):
> 
> "The pthread_cond_signal() function shall unblock at least one of the threads
> that are blocked on the specified condition variable cond (if any threads are
> blocked on cond)."
>
> And I think the next quote makes it very clear what threads are considered to
> be blocked on the condvar at the time of the call to pthread_cond_signal():

It says that a thread must be considered blocked if the cond_wait call happened
before the signal call.  It does NOT say that ONLY those threads need to be
considered blocked.

> "That is, if another thread is able to acquire the mutex after the
> about-to-block thread has released it, then a subsequent call to
> pthread_cond_broadcast() or pthread_cond_signal() in that thread shall behave
> as if it were issued after the about-to-block thread has blocked."
> 
> In effect this means that each call to pthread_cond_signal() defines a point in
> time and all waiters (or calls to pthread_cond_wait() if you prefer) are either
> before this call, or after it. And only the ones that are before it are allowed
> to consume the signal sent by this call.

No it does not.  It only talks about what happens before (=> meaning it
implies):

waiter happens-before signaler => waiter is considered blocked

It does not say (<=> meaning being equivalent to):

waiter happens-before signaler <=> waiter is considered blocked

(In fact, if you spin the second (<=>) further, you could only expect / build
an ordering based on the mutex, but not for other kinds of enforced
happens-before order. That's not what we'd want.)

> On the other hand, the standard doesn't guarantee that there won't be spurious
> wakeups. However, glibc tries to prevent them. But the logic for this
> prevention is flawed and causes the race that this bug is about.

The term "race" here is misleading.  If there's a race, in it's how you use the
cond var and expect it to behave.  The logic would be flawed if it allowed
incorrect behavior, which it doesn't.

> So the net result is that glibc chose to provide a feature that is not
> required, but dropped a much more important feature which is actually required.
> Hence, this bug is not a fairness feature request, it is a correctness defect
> report.

No.  You assume a guarantee that isn't required by the standard.

The comment that you are asking for a fairness feature is an attempt at an
explanation for you that should point out the difference to what the standard
guarantees.  This was meant to help in this discussion.  If we want to further
discuss this, I believe this needs to focus around whether the standard
requires that certain threads must not be considered blocked.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[triegel at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #23 from Torvald Riegel <triegel at redhat dot com> 2012-09-20 11:58:26 UTC ---
(In reply to comment #21)
> (In reply to comment #20)
> > The standard indeed doesn't talk about the "future".  It doesn't make a sort of
> > lower-bound requirement on which threads have to be considered blocked, but no
> > upper bound.  If you think there's an upper bound, please point the requirement
> > in the standard.  If there is no required upper bound, it's up to the
> > implementation how to deal with that.
> 
> "The pthread_cond_broadcast() and pthread_cond_signal() functions shall have no
> effect if there are no threads currently blocked on cond."
> 
> How about this as an upper bound?

This states something in relation to those threads that are considered to be
blocked.  It does not state anything about which threads can or have to be
considered to be blocked.  So, it can't be an upper bound.

> If implementations are allowed to determine
> the set of blocked threads at any point in time they see fit, there would be no
> way to define "currently blocked" at all and this sentence couldn't make any
> sense.

There is a lower bound (or minimum requirement) based on the happens-before via
the mutex (hence "currently").  The sentence allows the implementation to let
the signal have no effect if there is no thread that has to be considered
blocked with the assumption of the lower bound.  Assuming more threads to be
blocked is the same as allowing spurious wake-ups.

> And also:
> 
> ".... however, if predictable scheduling behavior is required, then that mutex
> shall be locked by the thread calling pthread_cond_broadcast() or
> pthread_cond_signal()."
> 
> If I accept your argument, there will be no way to determine at least a set of
> threads from which the woken thread will be chosen, so why does the standard
> talk about predictability?

There is the lower bound, which does determine properties of this set.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #24 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2012-09-20 12:46:24 UTC ---
(In reply to comment #23)
> This states something in relation to those threads that are considered to be
> blocked.  It does not state anything about which threads can or have to be
> considered to be blocked.  So, it can't be an upper bound.

It doesn't say "blocked at the time the signal is delivered". It says
"currently blocked". And it doesn't talk about the effect of the delivery of
the signal, it talks about the effect of the function. So "current" and
"function" should be related somehow. I'm taking the relation to be that
"current" means "at the time of the call to the function".

But the language of the standard is too vague to make it explicit what
"currently" means here, so I guess you are free to interpret it otherwise.

> There is a lower bound (or minimum requirement) based on the happens-before via
> the mutex (hence "currently").  The sentence allows the implementation to let
> the signal have no effect if there is no thread that has to be considered
> blocked with the assumption of the lower bound.  Assuming more threads to be
> blocked is the same as allowing spurious wake-ups.

I don't really buy your argument here, but I just realized that this sentence
only talks about the situation when there are no blocked threads, so I cannot
use it to reason about the case when there are blocked waiters before the call.

Again, the vague language of the standard allows your interpretation.

> > If I accept your argument, there will be no way to determine at least a set of
> > threads from which the woken thread will be chosen, so why does the standard
> > talk about predictability?
> 
> There is the lower bound, which does determine properties of this set.

What I meant is that if we accept your interpretation, there are no threads
that can be excluded from the set of blocked threads - except the ones that
never called, nor will ever call pthread_cond_wait() and the ones that have
already returned from all the calls to pthread_cond_wait() they will ever make.

To illustrate this, let me take what you're saying to its logical conclusion.

Suppose for simplicity that we have a single call to pthread_cond_signal() and
many calls to pthread_cond_wait(), both before and after the call to
pthread_cond_signal(). What you are actually saying is that it is correct for
the call to pthread_cond_signal() to consider all of these threads to be
blocked, and is allowed to wake any of them, even threads that are not created
yet.

Even more, if the signaling thread calls pthread_cond_wait() some time (even
hours) after it called pthread_cond_signal(). it is correct (although
undesirable) for it to consume its own signal and all the rest waiters to
become blocked.

Although I agree that the spec allows this interpretation, I think it is highly
impractical and unintuitive, that's why I believe it is not what the authors
had in mind. But of course, the only resolution of this argument at this point
is to ask them for clarification. So I don't see any point in arguing any more
without involving them.

Meanwhile, just consider this: you have code in the implementation which tries
to prevent spurious wakeups and it basically aims to establish a timeline of
the calls to pthread_cond_signal() and pthread_cond_wait() and assumes that a
wakeup is spurious if it occurred without a signal being sent after the
respective thread blocked. I dare say that the code suggests that whoever wrote
this code had the same assumptions about ordering as me. And it actually
contradicts your interpretation, because with your interpretation a single
counter of outstanding signals would be enough.

BTW, the reason why this code fails to work correctly is very simple - you
can't detect spurious wakeups reliably using constant memory without giving up
all ordering guarantees.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #25 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2012-09-20 12:49:05 UTC ---
(In reply to comment #24)
> Even more, if the signaling thread calls pthread_cond_wait() some time (even
> hours) after it called pthread_cond_signal(). it is correct (although
> undesirable) for it to consume its own signal and all the rest waiters to
> become blocked.

I meant "to remain blocked"...

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[triegel at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #26 from Torvald Riegel <triegel at redhat dot com> 2012-09-20 16:21:01 UTC ---
(In reply to comment #24)
> Although I agree that the spec allows this interpretation, I think it is highly
> impractical and unintuitive, that's why I believe it is not what the authors
> had in mind. But of course, the only resolution of this argument at this point
> is to ask them for clarification. So I don't see any point in arguing any more
> without involving them.

If the requirements in the specification should change in the future, we can
look at this again. I personally don't think that this makes cond vars
significantly impractical or unintuitive, but that is a trade-off that the
standards body will have to make (or probably did when it produced the current
spec).

Until then, I suppose that you now agree that this is correct behavior
according to the current spec.

> Meanwhile, just consider this: you have code in the implementation which tries
> to prevent spurious wakeups and it basically aims to establish a timeline of
> the calls to pthread_cond_signal() and pthread_cond_wait()

Not a timeline, but just overall number of signals or threads that started
waiting.

> and assumes that a
> wakeup is spurious if it occurred without a signal being sent after the
> respective thread blocked.

It is spurious if there were not enough signals being sent, or other threads
consumed the signals that were sent.

> I dare say that the code suggests that whoever wrote
> this code had the same assumptions about ordering as me.

Looking at the git log for the respective files, you should take that question
to Ulrich or Jakub.

> And it actually
> contradicts your interpretation, because with your interpretation a single
> counter of outstanding signals would be enough.

I doubt that (if you want to do this efficiently).

> BTW, the reason why this code fails to work correctly is very simple - you
> can't detect spurious wakeups reliably using constant memory without giving up
> all ordering guarantees.

I think you can (just combine something like a ticket lock with the futex) --
but this won't be efficient.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #27 from Rich Felker <bugdal at aerifal dot cx> 2012-09-20 18:39:10 UTC ---
I disagree strongly that the spec even allows Torvald's interpretation.
Torvald's claim is essentially that an implementation can consider an
unspecified set of threads beyond those which "have blocked" per the
specification of pthread_cond_wait to also "have blocked" on the condition. Not
only is there no language in the standard to support this (the only definition
of "blocked" on a condition variable is the one we've cited); it would also
make the specification of pthread_cond_signal completely useless, as the "at
least one" could always be taken to mean "the one invisible thread your
application can't see that's always blocked on every possible condition
variable". This is the pinnacle of absurdity in an attempt to language-lawyer
out of fixing a bug.

The fact of the matter is that POSIX, along with common sense and the entire
intended usage of condition variables, requires pthread_cond_signal to unblock
at least one thread that "has blocked", in the sense of the blocking that
happens atomically with unlocking the mutex as described in the specification
of pthread_cond_wait.

The situation we're looking at here is that the authors of NPTL came up with a
clever hack to reduce spurious wakeups in pthread_cond_wait, but failed to
realize the hack was broken in some corner cases, and now Torvald is unwilling
to admit that the hack is broken and take it out.

It should also be noted that I have been unable to demonstrate any case where
NPTL's hack to prevent spurious wakeups actually has any positive effect. A
while back I wrote a test program to hammer condition variables and look for
spurious wakeups, and I could not generate any with either NPTL's buggy
implementation OR with musl's implementation which does not use any similar
hack and does not suffer from this bug. Thus, in addition to being wrong and
broken, it's my conclusion, unless anybody else can produce evidence to the
contrary, that the hack is also useless (does not have the intended effect of
improving performance).

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #28 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2012-09-20 19:48:25 UTC ---
(In reply to comment #27)
> I disagree strongly that the spec even allows Torvald's interpretation.
> Torvald's claim is essentially that an implementation can consider an
> unspecified set of threads beyond those which "have blocked" per the
> specification of pthread_cond_wait to also "have blocked" on the condition.

Yes, that's what he claims.

> Not
> only is there no language in the standard to support this (the only definition
> of "blocked" on a condition variable is the one we've cited);

Yes, there is no language to support it, but I must admit that there is also no
language to explicitly prevent it, even though I too consider this
interpretation completely unreasonable as I tried to explain several times.

Anyway, this whole dispute has been reduced to the question of which threads
are eligible for wakeup, so I've taken the liberty to post a clarification
request to the Austin Group, asking them to add explicit text explaining which
threads should be considered blocked with respect to a pthread_cond_signal()
call. The clarification request is at
http://austingroupbugs.net/view.php?id=609. Torvald, please correct me if have
inadvertently misrepresented your position.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #29 from Rich Felker <bugdal at aerifal dot cx> 2012-09-20 20:31:26 UTC ---
The lack of language to explicitly prevent something is not necessary. Do you
see any language that explicitly prevents an implementation from writing the
text "42" to stdout when you call strlen? I would grant that Torvald has an
argument if the application had called any glibc functions not specified by
POSIX (which could be defined by the implementation to do all sorts of crazy
things) or if the application had passed constants other than those defined by
POSIX to standard functions (e.g. a special attribute for the condition
variable). But in the absence of that, no interface in the standard library can
have further side effects on other interfaces/objects than what it's specified
to do.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[triegel at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #30 from Torvald Riegel <triegel at redhat dot com> 2012-09-21 08:03:55 UTC ---
(In reply to comment #27)
> I disagree strongly that the spec even allows Torvald's interpretation.
> Torvald's claim is essentially that an implementation can consider an
> unspecified set of threads beyond those which "have blocked" per the
> specification of pthread_cond_wait to also "have blocked" on the condition.

No it's not unspecified. The specification requires a lower bound on this set.
If you think that this is not just a lower bound, argue against the reasons I
gave for this, don't just repeat your opinion here, please.

> Not
> only is there no language in the standard to support this (the only definition
> of "blocked" on a condition variable is the one we've cited);

Which is the lower bound. And this is a meaningful requirement, and provides
cond vars that are useful.

> it would also
> make the specification of pthread_cond_signal completely useless, as the "at
> least one" could always be taken to mean "the one invisible thread your
> application can't see that's always blocked on every possible condition
> variable".

You do see that there is a difference between this and requiring "blocked" but
not requiring an upper bound based on happens before?

> This is the pinnacle of absurdity in an attempt to language-lawyer
> out of fixing a bug.

Frankly, I don't care what you think that my motivations are. And I also don't
speculate here about your motivations, nor about your abilities to distinguish
an implication from equivalence. So please stop making such statements.

What I care about is whether this is indeed a bug or not.  Taking this question
to the standards body for clarification is the right way to go if people think
that the standard should require something else, or be more precise is what is
allowed or not.

> The fact of the matter is that POSIX, along with common sense and the entire
> intended usage of condition variables, requires pthread_cond_signal to unblock
> at least one thread that "has blocked", in the sense of the blocking that
> happens atomically with unlocking the mutex as described in the specification
> of pthread_cond_wait.

That doesn't conflict with what I said. You mention an entirely different point
here.

> The situation we're looking at here is that the authors of NPTL came up with a
> clever hack to reduce spurious wakeups in pthread_cond_wait, but failed to
> realize the hack was broken in some corner cases, and now Torvald is unwilling
> to admit that the hack is broken and take it out.

See above. Aside from this being impolite, speculation like this does not
belong in a bug report.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[siddhesh at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

Siddhesh Poyarekar <siddhesh at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |siddhesh at redhat dot com

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #31 from Rich Felker <bugdal at aerifal dot cx> 2012-09-21 08:52:51 UTC ---
Such "speculation" does belong in a bug report so that there is public record
of this behavior of trying to weasel out of conformance requirements. Public
opinion counts, and there should be a cost in public opinion to software
maintainers who refuse to fix bugs and try to argue that their bugs are not
bugs.

Certainly I cannot read your mind to prove claims about your motivation. It
really just boils down to a case of Occam's razor. When fixing the issue would
basically amount to an all-minuses patch that greatly simplifies the code, yet
the maintainers refuse to do it, the simplest explanation is that somebody has
an attachment to the code and the work that went into writing it. If your
motivation is something else, like perhaps concerns about making a mistake and
breaking something in the process of fixing it, why not say that outright
rather than leaving everybody stuck having to speculate about your motivations?
Then the pros and cons of fixing it can be argued rationally. Or do you claim
you have no further motivation here than "I believe the standard allows
low-quality implementations with bad properties like this, so I want to
exercise my right to do a bad job and still claim conformance"?

With the motivation topic out of the way, let's get back to the requirements of
the standard. My understanding is that you claim "the threads that are blocked
on the specified condition variable cond" is a set consisting of at least those
threads which provably (by virtue of the mutex providing ordering) called
pthread_cond_[timed]wait before the caller of pthread_cond_signal obtained the
mutex, but which also may contain other threads. Not, as I originally accused
you of, a completely arbitrary set of other threads, but rather threads which
are "about to" wait on the condition variable in the immediate future after the
signaling thread unlocks the mutex. Is this a correct assessment of your
position?

If so, can you clarify what condition would qualify such threads for membership
in this set? Certainly it can't be any thread that could ever conceivably wait
on the condition variable at any later point in the program flow; if nothing
else, that set is self-referential and thus not even a set (because which
threads are candidates for membership may depend on which thread the signal
unblocked).

My claim that the set of candidate threads pthread_cond_signal can unblock is a
fixed set is based on the following:

1. The status of being blocked on a condition variable is defined only in the
specification of pthread_cond_[timed]wait. I think we both agree on this. There
is no way a thread is ever blocked on a condition variable except by calling
pthread_cond_[timed]wait on it.

2. Sequencing of events between threads is not defined in general, but the use
of mutexes with condition variables imposes a sequencing. In particular, from
the point of view of any other thread, a given thread's status as being blocked
on a condition variable is acquired after it obtains the mutex and before
pthread_cond_[timed]wait releases the mutex. The former sequencing requirement
comes from the fact that you can only call pthread_cond_[timed]wait with the
mutex held, and the fact that pthread_cond_[timed]wait is the function
specified to block; the latter sequencing requirement is the atomicity of
blocking and unlocking the mutex.

3. The pthread_cond_signal function "shall unblock at least one of the threads
that are blocked on the specified condition variable". There is no language
about queuing an unblock request; the language of the standard is "shall
unblock". This means that even if the mechanism is some sort of queued request,
in the sense of the formal, abstract machine, one of the threads in the set of
blocked threads goes from blocked status to unblocked status during the call to
pthread_cond_signal (and, from the stantpoint of observable sequencing, between
the calling thread's calls to pthread_mutex_lock and pthread_mutex_unlock).
Since the mutex is locked during this time, there is no way additional threads
can become blocked on the condition variable. On the other hand, some could
become unblocked due to spurious wakes, so the set could shrink, but it could
not grow.

If you still claim my reasoning is wrong, please cite the specific steps you
believe are hand-waving or misinterpretation of the standard.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[triegel at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #32 from Torvald Riegel <triegel at redhat dot com> 2012-09-21 15:44:30 UTC ---
(In reply to comment #28)
> (In reply to comment #27)
> > I disagree strongly that the spec even allows Torvald's interpretation.
> > Torvald's claim is essentially that an implementation can consider an
> > unspecified set of threads beyond those which "have blocked" per the
> > specification of pthread_cond_wait to also "have blocked" on the condition.
> 
> Yes, that's what he claims.

Not quite, as I point out in comment #30.

> Anyway, this whole dispute has been reduced to the question of which threads
> are eligible for wakeup, so I've taken the liberty to post a clarification
> request to the Austin Group, asking them to add explicit text explaining which
> threads should be considered blocked with respect to a pthread_cond_signal()
> call. The clarification request is at
> http://austingroupbugs.net/view.php?id=609. Torvald, please correct me if have
> inadvertently misrepresented your position.

Thanks.  I have added a note there that summarizes the interpretation that the
current implementation is based on.  Let's see what they think about this
issue.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[mihaylov.mihail at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #33 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2012-10-18 06:26:22 UTC ---
(In reply to comment #32)
> (In reply to comment #28)
> ....
> ....
> > Anyway, this whole dispute has been reduced to the question of which threads
> > are eligible for wakeup, so I've taken the liberty to post a clarification
> > request to the Austin Group, asking them to add explicit text explaining which
> > threads should be considered blocked with respect to a pthread_cond_signal()
> > call. The clarification request is at
> > http://austingroupbugs.net/view.php?id=609. Torvald, please correct me if have
> > inadvertently misrepresented your position.
> 
> Thanks.  I have added a note there that summarizes the interpretation that the
> current implementation is based on.  Let's see what they think about this
> issue.

The Austin Group have reached an official position. They have decided to make
changes to some of the texts related to condition variables. I believe that the
changes as they announced them yesterday invalidate glibc's interpretation of
the spec.

Let me point out that these changes do not add new requirements to the spec.
They just make explicit the requirements that were already suggested by the
spec.

In my opinion, at this point it is already clear that NPTL's implementation of
condition variables does not conform to the POSIX spec, therefore this bug is
actually really a bug. I hope that the NPTL team will acknowledge it as such.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #34 from Rich Felker <bugdal at aerifal dot cx> 2012-10-18 12:25:16 UTC ---
It should be noted that no changes were made to the requirements the standard
places on implementations; the changes made are only clarifications, since
apparently the original language was not clear enough.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[triegel at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|drepper.fsp at gmail dot    |triegel at redhat dot com
                   |com                         |

--- Comment #35 from Torvald Riegel <triegel at redhat dot com> 2012-10-24 20:25:32 UTC ---
(In reply to comment #33)
> The Austin Group have reached an official position. They have decided to make
> changes to some of the texts related to condition variables. I believe that the
> changes as they announced them yesterday invalidate glibc's interpretation of
> the spec.

I agree.  Those changes disallow glibc's current behavior.

> Let me point out that these changes do not add new requirements to the spec.
> They just make explicit the requirements that were already suggested by the
> spec.

I disagree.  It's a specification -- it has to be explicit.

(In reply to comment #34)
> It should be noted that no changes were made to the requirements the standard
> places on implementations; the changes made are only clarifications, since
> apparently the original language was not clear enough.

How is that not a change in the spec:
http://austingroupbugs.net/view.php?id=609#c1403 ?  Are we talking about the
same thing here?

Apparently, the original language was not clear enough.  Otherwise, why change
the spec?  If it were clear enough, an interpretation explanation or something
like that would have been sufficient, right.  They even say that they see the
need to "produce some interpretation text to precede these changes".

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #36 from Rich Felker <bugdal at aerifal dot cx> 2012-10-25 04:07:39 UTC ---
The note #0001403 you cited begins:

"In the Oct 17th conference call we agreed to make the following changes.
Further work is needed to produce some interpretation text to precede these
changes."

Said "interpretation text to precede these changes", as I understand it, is an
explanation of how the current text is meant to be interpreted. The "following
changes" then are clarifications to appear in the TC or next version of the
standard, but the interpretation is (or will be) that the current standard
already requires exactly the same thing, at least from an observable-behavior
standpoint.

As I have stated before, I do not see any way one could interpret the current
glibc behavior as conformant. Under the current glibc behavior, events that
should be synchronized by a mutex observably/provably occur in an order
different from the order the synchronization imposes.

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[scot4spam at yahoo dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

Scot Salmon <scot4spam at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |scot4spam at yahoo dot com

-- 
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.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[jackie.rosen at hushmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13165

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #37 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[dancol at dancol dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=13165

Daniel Colascione <dancol at dancol dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dancol at dancol dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[schwab at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=13165

Andreas Schwab <schwab at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jackie.rosen at hushmail dot com   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13165

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[triegel at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #39 from Torvald Riegel <triegel at redhat dot com> ---
That's not sufficient.  Or maybe I'm not seeing the obvious thing here -- but
if it's obvious, could you give a proof why what you described is sufficient? 
(And we don't want ABA issues also...)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #40 from Rich Felker <bugdal at aerifal dot cx> ---
Indeed, I think I was wrong on this, and probably just misread the code. Sorry
for the noise.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[kkersten at cray dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13165

Kris Kersten <kkersten at cray dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kkersten at cray dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

[triegel at redhat dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 255047 bytes --]

https://sourceware.org/bugzilla/show_bug.cgi?id=13165

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.25

--- Comment #43 from Torvald Riegel <triegel at redhat dot com> ---
Fixed in master.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35440-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 10:14:13 2017
Return-Path: <glibc-bugs-return-35440-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 116611 invoked by alias); 2 Jan 2017 10:14:12 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 105277 invoked by uid 48); 2 Jan 2017 10:13:59 -0000
From: "bernd.edlinger at hotmail dot de" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug stdio/21004] fread/fwrite does not handle EINTR correctly
Date: Mon, 02 Jan 2017 10:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: stdio
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21004-131-NRbsfzXkCB@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21004-131@http.sourceware.org/bugzilla/>
References: <bug-21004-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00001.txt.bz2
Content-length: 282

https://sourceware.org/bugzilla/show_bug.cgi?id=21004

--- Comment #3 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
What exactly would break by retrying EINTR
that is not already broken?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35441-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 10:15:59 2017
Return-Path: <glibc-bugs-return-35441-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 18400 invoked by alias); 2 Jan 2017 10:15:59 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 15197 invoked by uid 48); 2 Jan 2017 10:15:46 -0000
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug stdio/21004] fread/fwrite does not handle EINTR correctly
Date: Mon, 02 Jan 2017 10:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: stdio
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21004-131-eW9h9yrE94@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21004-131@http.sourceware.org/bugzilla/>
References: <bug-21004-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00002.txt.bz2
Content-length: 457

https://sourceware.org/bugzilla/show_bug.cgi?id=21004

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Bernd Edlinger from comment #3)
> What exactly would break by retrying EINTR
> that is not already broken?

Code which uses EINTR to exit a blocked fread, with a signal handler which sets
a global variable checked by the caller of fread.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35442-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 10:25:32 2017
Return-Path: <glibc-bugs-return-35442-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 36655 invoked by alias); 2 Jan 2017 10:25:32 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 36517 invoked by uid 48); 2 Jan 2017 10:25:19 -0000
From: "bernd.edlinger at hotmail dot de" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug stdio/21004] fread/fwrite does not handle EINTR correctly
Date: Mon, 02 Jan 2017 10:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: stdio
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21004-131-wyziAmSEp9@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21004-131@http.sourceware.org/bugzilla/>
References: <bug-21004-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00003.txt.bz2
Content-length: 668

https://sourceware.org/bugzilla/show_bug.cgi?id=21004

--- Comment #5 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Florian Weimer from comment #4)
> (In reply to Bernd Edlinger from comment #3)
> > What exactly would break by retrying EINTR
> > that is not already broken?
> 
> Code which uses EINTR to exit a blocked fread, with a signal handler which
> sets a global variable checked by the caller of fread.

but this is always a race condition, if the signal does
not interrupt a system call.  Are there really programs
that do that kind of programming?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35443-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 10:28:13 2017
Return-Path: <glibc-bugs-return-35443-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 39677 invoked by alias); 2 Jan 2017 10:28:13 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 39502 invoked by uid 48); 2 Jan 2017 10:28:00 -0000
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug stdio/21004] fread/fwrite does not handle EINTR correctly
Date: Mon, 02 Jan 2017 10:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: stdio
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21004-131-fPPdWzFCXa@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21004-131@http.sourceware.org/bugzilla/>
References: <bug-21004-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00004.txt.bz2
Content-length: 884

https://sourceware.org/bugzilla/show_bug.cgi?id=21004

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Bernd Edlinger from comment #5)
> (In reply to Florian Weimer from comment #4)
> > (In reply to Bernd Edlinger from comment #3)
> > > What exactly would break by retrying EINTR
> > > that is not already broken?
> > 
> > Code which uses EINTR to exit a blocked fread, with a signal handler which
> > sets a global variable checked by the caller of fread.
> 
> but this is always a race condition, if the signal does
> not interrupt a system call.

In this case, the flag is still set by the signal handler.

> Are there really programs that do that kind of programming?

It is the standard idiom for reducing the amount of code which runs in a signal
handler.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35444-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 10:49:05 2017
Return-Path: <glibc-bugs-return-35444-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 47904 invoked by alias); 2 Jan 2017 10:49:05 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 47759 invoked by uid 48); 2 Jan 2017 10:48:52 -0000
From: "bernd.edlinger at hotmail dot de" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug stdio/21004] fread/fwrite does not handle EINTR correctly
Date: Mon, 02 Jan 2017 10:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: stdio
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21004-131-KxY3IelwEy@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21004-131@http.sourceware.org/bugzilla/>
References: <bug-21004-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00005.txt.bz2
Content-length: 1343

https://sourceware.org/bugzilla/show_bug.cgi?id=21004

--- Comment #7 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Florian Weimer from comment #6)
> (In reply to Bernd Edlinger from comment #5)
> > (In reply to Florian Weimer from comment #4)
> > > (In reply to Bernd Edlinger from comment #3)
> > > > What exactly would break by retrying EINTR
> > > > that is not already broken?
> > > 
> > > Code which uses EINTR to exit a blocked fread, with a signal handler which
> > > sets a global variable checked by the caller of fread.
> > 
> > but this is always a race condition, if the signal does
> > not interrupt a system call.
> 
> In this case, the flag is still set by the signal handler.
> 

Yes. But if the signal interrupts before the internal read
the read is called and may wait infinitely, that is what
I meant with race condition.

> > Are there really programs that do that kind of programming?
> 
> It is the standard idiom for reducing the amount of code which runs in a
> signal handler.

OTOH if they call sigaction without SA_RESTART they should know
what that means.

Bit if signal() is used it always means SA_RESTART (BSD semantic)
today, is that right, or does that depend on _BSD_SOURCE or
something?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35445-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 12:53:34 2017
Return-Path: <glibc-bugs-return-35445-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 56935 invoked by alias); 2 Jan 2017 12:53:34 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 56837 invoked by uid 48); 2 Jan 2017 12:53:21 -0000
From: "bernd.edlinger at hotmail dot de" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug stdio/21004] fread/fwrite does not handle EINTR correctly
Date: Mon, 02 Jan 2017 12:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: stdio
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21004-131-BrvLyvM9O2@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21004-131@http.sourceware.org/bugzilla/>
References: <bug-21004-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00006.txt.bz2
Content-length: 494

https://sourceware.org/bugzilla/show_bug.cgi?id=21004

--- Comment #8 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
One other thing that mitigates the effect of EINTR handling in stdio is
that at least linux does never return EINTR on disk files and even
NFS files mounted without the intr option.

So additionally to having signals without SA_RESTART it needs
a blocking I/O on a character device.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35446-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 14:18:01 2017
Return-Path: <glibc-bugs-return-35446-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 46324 invoked by alias); 2 Jan 2017 14:18:00 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 33030 invoked by uid 48); 2 Jan 2017 14:17:52 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/21014] New: i686 memchr overflows internal pointer check
Date: Mon, 02 Jan 2017 14:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: 2.14
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-21014-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00007.txt.bz2
Content-length: 869

https://sourceware.org/bugzilla/show_bug.cgi?id=21014

            Bug ID: 21014
           Summary: i686 memchr overflows internal pointer check
           Product: glibc
           Version: 2.14
            Status: NEW
          Severity: normal
          Priority: P2
         Component: string
          Assignee: unassigned at sourceware dot org
          Reporter: adhemerval.zanella at linaro dot org
  Target Milestone: ---

Similar to BZ#19387 and BZ#20971, both i686 memchr optimized assembly
implementations [1] [2] do not handle the size overflow correctly.

This is shown by the new tests added by commit 3daef2c8ee4df29, where both
implementation fails with size as SIZE_MAX.

[1] sysdeps/i386/i686/multiarch/memchr-sse2-bsf.S
[2] sysdeps/i386/i686/multiarch/memchr-sse2.S

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35447-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 14:18:14 2017
Return-Path: <glibc-bugs-return-35447-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 69333 invoked by alias); 2 Jan 2017 14:18:13 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 44857 invoked by uid 48); 2 Jan 2017 14:18:00 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/21014] i686 memchr overflows internal pointer check
Date: Mon, 02 Jan 2017 14:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: 2.14
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-21014-131-seaZeY7Gsi@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21014-131@http.sourceware.org/bugzilla/>
References: <bug-21014-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00008.txt.bz2
Content-length: 482

https://sourceware.org/bugzilla/show_bug.cgi?id=21014

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |adhemerval.zanella at linaro dot o
                   |                            |rg

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35448-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 15:27:48 2017
Return-Path: <glibc-bugs-return-35448-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 98848 invoked by alias); 2 Jan 2017 15:27:48 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 98372 invoked by uid 48); 2 Jan 2017 15:27:35 -0000
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/21015] New: Document and fix --enable-bind-now
Date: Mon, 02 Jan 2017 15:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone flagtypes.name
Message-ID: <bug-21015-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00009.txt.bz2
Content-length: 748

https://sourceware.org/bugzilla/show_bug.cgi?id=21015

            Bug ID: 21015
           Summary: Document and fix --enable-bind-now
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
  Target Milestone: ---
             Flags: security-

The --enable-bind-now configure option is currently undocumented and only
applies to libc.so.6 (instead of all installed DSOs).

Enabling BIND_NOW will give us full RELRO and some additional security
hardening.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35449-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 15:55:21 2017
Return-Path: <glibc-bugs-return-35449-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 77539 invoked by alias); 2 Jan 2017 15:55:20 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 76807 invoked by uid 48); 2 Jan 2017 15:55:12 -0000
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/21015] Document and fix --enable-bind-now
Date: Mon, 02 Jan 2017 15:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: fweimer at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-21015-131-0sdo8tJjpw@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21015-131@http.sourceware.org/bugzilla/>
References: <bug-21015-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00010.txt.bz2
Content-length: 464

https://sourceware.org/bugzilla/show_bug.cgi?id=21015

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at sourceware dot org   |fweimer at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35450-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 16:05:01 2017
Return-Path: <glibc-bugs-return-35450-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 123629 invoked by alias); 2 Jan 2017 16:04:59 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 123502 invoked by uid 48); 2 Jan 2017 16:04:47 -0000
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/20844] getaddrinfo() fails in some instances with AF_UNSPEC set
Date: Mon, 02 Jan 2017 16:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: network
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: WORKSFORME
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-20844-131-0bmARflWvZ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20844-131@http.sourceware.org/bugzilla/>
References: <bug-20844-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00011.txt.bz2
Content-length: 621

https://sourceware.org/bugzilla/show_bug.cgi?id=20844

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
My best guess is that this is a known issue in the VirtualBox DNS forwarder
implementation, and not a glibc bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35451-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 16:06:02 2017
Return-Path: <glibc-bugs-return-35451-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 126321 invoked by alias); 2 Jan 2017 16:06:02 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 125647 invoked by uid 48); 2 Jan 2017 16:05:48 -0000
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug malloc/20425] unbalanced and poor utilization of memory in glibc arenas may cause memory bloat and subsequent OOM
Date: Mon, 02 Jan 2017 16:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: malloc
X-Bugzilla-Version: 2.12
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: WORKSFORME
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: fweimer at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-20425-131-ptKWmUkUTe@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20425-131@http.sourceware.org/bugzilla/>
References: <bug-20425-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00012.txt.bz2
Content-length: 562

https://sourceware.org/bugzilla/show_bug.cgi?id=20425

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #26 from Florian Weimer <fweimer at redhat dot com> ---
We cannot fix this problem with a proper reproducer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35452-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 16:57:52 2017
Return-Path: <glibc-bugs-return-35452-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 130118 invoked by alias); 2 Jan 2017 16:57:51 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 130010 invoked by uid 48); 2 Jan 2017 16:57:38 -0000
From: "danglin at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/21016] New: pthread_cond support is broken on hppa
Date: Mon, 02 Jan 2017 16:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.26
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: danglin at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone cf_gcchost cf_gcctarget cf_gccbuild
Message-ID: <bug-21016-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00013.txt.bz2
Content-length: 6449

https://sourceware.org/bugzilla/show_bug.cgi?id=21016

            Bug ID: 21016
           Summary: pthread_cond support is broken on hppa
           Product: glibc
           Version: 2.26
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: danglin at gcc dot gnu.org
                CC: deller at gmx dot de, drepper.fsp at gmail dot com,
                    triegel at redhat dot com
  Target Milestone: ---
              Host: hppa-unknown-linux-gnu
            Target: hppa-unknown-linux-gnu
             Build: hppa-unknown-linux-gnu

Trunk build fails here:

gcc ../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c -c -std=gnu11
-fgnu89-in
line  -O2 -Wall -Werror -Wundef -Wwrite-strings -fmerge-all-constants
-fno-stack
-protector -frounding-math -g -Wstrict-prototypes -Wold-style-definition    
-ft
ls-model=initial-exec      -I../include -I/home/dave/gnu/glibc/objdir/nptl 
-I/home/dave/gnu/glibc/objdir  -I../sysdeps/unix/sysv/linux/hppa 
-I../sysdeps/hppa/
nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux 
-I../sy
sdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet 
-I..
/sysdeps/unix/sysv  -I../sysdeps/unix  -I../sysdeps/posix 
-I../sysdeps/hppa/hpp
a1.1  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/flt-32 
-I../sysdeps/ieee75
4/dbl-64  -I../sysdeps/hppa/fpu  -I../sysdeps/hppa  -I../sysdeps/ieee754 
-I../s
ysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem
/usr/lib/gcc/hppa-linux-g
nu/6/include -isystem /usr/lib/gcc/hppa-linux-gnu/6/include-fixed -isystem
/usr/
include  -D_LIBC_REENTRANT -include /home/dave/gnu/glibc/objdir/libc-modules.h
-
DMODULE_NAME=libpthread -include ../include/libc-symbols.h       -o
/home/dave/g
nu/glibc/objdir/nptl/pthread_cond_init.o -MD -MP -MF
/home/dave/gnu/glibc/objdir/nptl/pthread_cond_init.o.dt -MT
/home/dave/gnu/glibc/objdir/nptl/pthread_cond_i
nit.o
In file included from ./pthreadP.h:30:0,
                 from ../sysdeps/unix/sysv/linux/hppa/pthreadP.h:1,            
    from ../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c:24,
                 from ../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c:21:
../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c: In function
‘__pthread_cond_init’:
../sysdeps/unix/sysv/linux/hppa/internaltypes.h:51:14: error: ‘struct
<anonymous>’ has no member named ‘__wseq’
   var->__data.__wseq = 0;      \
              ^
../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c:30:3: note: in expansion of
macro ‘cond_compat_clear’
   cond_compat_clear (cond);
   ^~~~~~~~~~~~~~~~~
../sysdeps/unix/sysv/linux/hppa/internaltypes.h:52:14: error: ‘struct
<anonymous>’ has no member named ‘__signals_sent’; did you mean ‘__total_seq’?
   var->__data.__signals_sent = 0;     \
              ^
../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c:30:3: note: in expansion of
macro ‘cond_compat_clear’
   cond_compat_clear (cond);
   ^~~~~~~~~~~~~~~~~
../sysdeps/unix/sysv/linux/hppa/internaltypes.h:53:14: error: ‘struct
<anonymous>’ has no member named ‘__confirmed’
   var->__data.__confirmed = 0;      \
              ^
../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c:30:3: note: in expansion of
macro ‘cond_compat_clear’
   cond_compat_clear (cond);
   ^~~~~~~~~~~~~~~~~
../sysdeps/unix/sysv/linux/hppa/internaltypes.h:54:14: error: ‘struct
<anonymous>’ has no member named ‘__generation’
   var->__data.__generation = 0;      \
              ^
../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c:30:3: note: in expansion of
macro ‘cond_compat_clear’
   cond_compat_clear (cond);
   ^~~~~~~~~~~~~~~~~
../sysdeps/unix/sysv/linux/hppa/internaltypes.h:56:14: error: ‘struct
<anonymous>’ has no member named ‘__quiescence_waiters’; did you mean
‘__nwaiters’?
   var->__data.__quiescence_waiters = 0;     \
              ^
../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c:30:3: note: in expansion of
macro ‘cond_compat_clear’
   cond_compat_clear (cond);
   ^~~~~~~~~~~~~~~~~
../sysdeps/unix/sysv/linux/hppa/internaltypes.h:57:14: error: ‘struct
<anonymous>’ has no member named ‘__clockid’; did you mean ‘__lock’?
   var->__data.__clockid = 0;      \
              ^
../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c:30:3: note: in expansion of
macro ‘cond_compat_clear’
   cond_compat_clear (cond);
   ^~~~~~~~~~~~~~~~~
../sysdeps/unix/sysv/linux/hppa/internaltypes.h:50:7: error: unused variable
‘tmp’ [-Werror=unused-variable]
   int tmp = 0;        \
       ^
../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c:30:3: note: in expansion of
macro ‘cond_compat_clear’
   cond_compat_clear (cond);
   ^~~~~~~~~~~~~~~~~
In file included from ../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c:39:0,
                 from ../sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c:21:
./pthread_cond_init.c: In function ‘__pthread_cond_init_internal’:
./pthread_cond_init.c:38:17: error: ‘struct <anonymous>’ has no member named
‘__wrefs’
     cond->__data.__wrefs |= __PTHREAD_COND_SHARED_MASK;
                 ^
./pthread_cond_init.c:44:17: error: ‘struct <anonymous>’ has no member named
‘__wrefs’
     cond->__data.__wrefs |= __PTHREAD_COND_CLOCK_MONOTONIC_MASK;
                 ^
cc1: all warnings being treated as errors
/home/dave/gnu/glibc/objdir/sysd-rules:9: recipe for target
'/home/dave/gnu/glibc/objdir/nptl/pthread_cond_init.o' failed
make[2]: *** [/home/dave/gnu/glibc/objdir/nptl/pthread_cond_init.o] Error 1
make[2]: Leaving directory '/home/dave/gnu/glibc/glibc/nptl'
Makefile:215: recipe for target 'nptl/subdir_lib' failed
make[1]: *** [nptl/subdir_lib] Error 2
make[1]: Leaving directory '/home/dave/gnu/glibc/glibc'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35453-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 16:59:23 2017
Return-Path: <glibc-bugs-return-35453-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 702 invoked by alias); 2 Jan 2017 16:59:23 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 514 invoked by uid 48); 2 Jan 2017 16:59:10 -0000
From: "danglin at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/21016] pthread_cond support is broken on hppa
Date: Mon, 02 Jan 2017 16:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.26
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: danglin at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21016-131-gl1t3pBkk6@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21016-131@http.sourceware.org/bugzilla/>
References: <bug-21016-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00014.txt.bz2
Content-length: 321

https://sourceware.org/bugzilla/show_bug.cgi?id=21016

--- Comment #1 from John David Anglin <danglin at gcc dot gnu.org> ---
I believe this was introduced by the following patch:
https://sourceware.org/ml/libc-alpha/2016-05/msg00605.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35454-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 18:51:58 2017
Return-Path: <glibc-bugs-return-35454-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 127879 invoked by alias); 2 Jan 2017 18:51:58 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 127722 invoked by uid 48); 2 Jan 2017 18:51:45 -0000
From: "tuliom at linux dot vnet.ibm.com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug math/19839] [powerpc] hypot() crashing w/SIGILL at xxlxor on power7 systems
Date: Mon, 02 Jan 2017 18:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: math
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tuliom at linux dot vnet.ibm.com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-19839-131-P978kjZ3Ju@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-19839-131@http.sourceware.org/bugzilla/>
References: <bug-19839-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00015.txt.bz2
Content-length: 584

https://sourceware.org/bugzilla/show_bug.cgi?id=19839

Tulio Magno Quites Machado Filho <tuliom at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tuliom at linux dot vnet.ibm.com

--- Comment #4 from Tulio Magno Quites Machado Filho <tuliom at linux dot vnet.ibm.com> ---
Hi Mike,

Is this still happening in more recent kernels?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35456-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 19:54:22 2017
Return-Path: <glibc-bugs-return-35456-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 51656 invoked by alias); 2 Jan 2017 19:54:21 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 50667 invoked by uid 48); 2 Jan 2017 19:54:09 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/21014] i686 memchr overflows internal pointer check
Date: Mon, 02 Jan 2017 19:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: 2.14
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-21014-131-6ArCJZmaWH@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21014-131@http.sourceware.org/bugzilla/>
References: <bug-21014-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00017.txt.bz2
Content-length: 613

https://sourceware.org/bugzilla/show_bug.cgi?id=21014

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.25

--- Comment #2 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Fixed by 23d27709a423a.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35455-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 19:54:01 2017
Return-Path: <glibc-bugs-return-35455-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 50390 invoked by alias); 2 Jan 2017 19:54:00 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 50301 invoked by uid 55); 2 Jan 2017 19:53:48 -0000
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/21014] i686 memchr overflows internal pointer check
Date: Mon, 02 Jan 2017 19:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: 2.14
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21014-131-84dX2u9uQ6@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21014-131@http.sourceware.org/bugzilla/>
References: <bug-21014-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00016.txt.bz2
Content-length: 2080

https://sourceware.org/bugzilla/show_bug.cgi?id=21014

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  23d27709a423aec32821e9a5198a10267107bae2 (commit)
      from  62210e7eb1b270c72c2ee61a14015285cd817262 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=23d27709a423aec32821e9a5198a10267107bae2

commit 23d27709a423aec32821e9a5198a10267107bae2
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Mon Jan 2 12:20:21 2017 -0200

    Fix i686 memchr for large input sizes

    Similar to BZ#19387 and BZ#20971, both i686 memchr optimized assembly
    implementations (memchr-sse2-bsf and memchr-sse2) do not handle the
    size overflow correctly.

    It is shown by the new tests added by commit 3daef2c8ee4df29, where
    both implementation fails with size as SIZE_MAX.

    This patch uses a similar strategy used on 3daef2c8ee4df2, where
    saturared math is used for overflow case.

    Checked on i686-linux-gnu.

        [BZ #21014]
        * sysdeps/i386/i686/multiarch/memchr-sse2-bsf.S (MEMCHR): Avoid
overflow
        in pointer addition.
        * sysdeps/i386/i686/multiarch/memchr-sse2.S (MEMCHR): Likewise.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                     |    7 +++++++
 sysdeps/i386/i686/multiarch/memchr-sse2-bsf.S |   10 ++++++++--
 sysdeps/i386/i686/multiarch/memchr-sse2.S     |    8 +++++++-
 3 files changed, 22 insertions(+), 3 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35457-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 20:22:01 2017
Return-Path: <glibc-bugs-return-35457-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 125878 invoked by alias); 2 Jan 2017 20:22:00 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 125665 invoked by uid 48); 2 Jan 2017 20:21:48 -0000
From: "triegel at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/21016] pthread_cond support is broken on hppa
Date: Mon, 02 Jan 2017 20:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.26
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: triegel at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-21016-131-yIP3L4Hncz@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21016-131@http.sourceware.org/bugzilla/>
References: <bug-21016-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00018.txt.bz2
Content-length: 840

https://sourceware.org/bugzilla/show_bug.cgi?id=21016

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |codonell at redhat dot com

--- Comment #2 from Torvald Riegel <triegel at redhat dot com> ---
Carlos has said he would take care of it.  I'm aware of two issues blocking
this: atomics don't work in all cases (stores should use the kernel helper
too), and the additional compatibility requirements for old initializers
(IIRC).  To get the condvar files to compile, just copy over the new
pthread_cond_t members from, say, x86 pthreadtypes.h to hppa's pthreadtypes.h.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35458-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 21:04:41 2017
Return-Path: <glibc-bugs-return-35458-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 48121 invoked by alias); 2 Jan 2017 21:04:40 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 48034 invoked by uid 48); 2 Jan 2017 21:04:28 -0000
From: "tetra2005 at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21018] New: Add memcchr function
Date: Mon, 02 Jan 2017 21:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tetra2005 at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone
Message-ID: <bug-21018-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00019.txt.bz2
Content-length: 1002

https://sourceware.org/bugzilla/show_bug.cgi?id=21018

            Bug ID: 21018
           Summary: Add memcchr function
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: tetra2005 at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Recent FreeBSD have a nice complement for standard memchr function - memcchr
(https://www.freebsd.org/cgi/man.cgi?query=memcchr). It e.g. allows user to
efficiently check whether buffer is zeroed out. Would it make sense to add
something like this to Glibc as well (yes, I can volunteer)?

Here's a motivational GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69908 (which also references
stackoverflow proving that problem is not that uncommon).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35459-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 21:06:38 2017
Return-Path: <glibc-bugs-return-35459-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 49515 invoked by alias); 2 Jan 2017 21:06:36 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 49415 invoked by uid 48); 2 Jan 2017 21:06:24 -0000
From: "tetra2005 at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/21018] Add memcchr function
Date: Mon, 02 Jan 2017 21:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tetra2005 at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc component
Message-ID: <bug-21018-131-rOJTF8KdJh@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21018-131@http.sourceware.org/bugzilla/>
References: <bug-21018-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00020.txt.bz2
Content-length: 456

https://sourceware.org/bugzilla/show_bug.cgi?id=21018

Yuri Gribov <tetra2005 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |will.newton at gmail dot com
          Component|libc                        |string

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35460-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 21:17:18 2017
Return-Path: <glibc-bugs-return-35460-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 78191 invoked by alias); 2 Jan 2017 21:17:17 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 78060 invoked by uid 48); 2 Jan 2017 21:17:05 -0000
From: "tetra2005 at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/21018] Add memcchr function
Date: Mon, 02 Jan 2017 21:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tetra2005 at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-21018-131-PLqW2xEigR@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21018-131@http.sourceware.org/bugzilla/>
References: <bug-21018-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00021.txt.bz2
Content-length: 396

https://sourceware.org/bugzilla/show_bug.cgi?id=21018

Yuri Gribov <tetra2005 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tetra2005 at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35461-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 22:59:36 2017
Return-Path: <glibc-bugs-return-35461-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 74484 invoked by alias); 2 Jan 2017 22:59:36 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 74367 invoked by uid 48); 2 Jan 2017 22:59:23 -0000
From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21019] New: [mips] n32 lseek incorrect on overflow
Date: Mon, 02 Jan 2017 22:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jsm28 at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone cf_gcchost
Message-ID: <bug-21019-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00022.txt.bz2
Content-length: 1045

https://sourceware.org/bugzilla/show_bug.cgi?id=21019

            Bug ID: 21019
           Summary: [mips] n32 lseek incorrect on overflow
           Product: glibc
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: jsm28 at gcc dot gnu.org
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---
              Host: mips64*-*-linux*

The MIPS n32 version of lseek fails to detect results that overflow 32-bit
off_t.  Formerly (before Adhemerval's lseek consolidation) it incorrectly
aliased lseek64, so returning results outside the range of the return type; now
it truncates the 64-bit return from the lseek syscall to 32 bits (and now,
after that consolidation, lseek64 wrongly truncates as well, but that bug
hasn't appeared in a release so this report is specifically for lseek not
lseek64).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35462-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 23:11:18 2017
Return-Path: <glibc-bugs-return-35462-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 104809 invoked by alias); 2 Jan 2017 23:11:18 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 103645 invoked by uid 55); 2 Jan 2017 23:11:02 -0000
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21019] [mips] n32 lseek incorrect on overflow
Date: Mon, 02 Jan 2017 23:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21019-131-pXAB73nkGK@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21019-131@http.sourceware.org/bugzilla/>
References: <bug-21019-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00023.txt.bz2
Content-length: 3360

https://sourceware.org/bugzilla/show_bug.cgi?id=21019

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  df19fdcfec7143073b50f9f01af712528bed6d26 (commit)
      from  4179178bf0cfafe72c00647b79e69e47bd5c6a89 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=df19fdcfec7143073b50f9f01af712528bed6d26

commit df19fdcfec7143073b50f9f01af712528bed6d26
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Mon Jan 2 23:09:25 2017 +0000

    Fix MIPS n32 lseek, lseek64 (bug 21019).

    The lseek consolidation broke lseek64 for MIPS n32, so resulting in
    io/test-lfs failing with an incorrect return from ftello64.  This
    configuration uses the lseek syscall with a 64-bit return value; as
    the C syscall macros return long, they cannot be used in this case and
    so an assembly implementation is needed; accordingly, this patch adds
    lseek64 back to syscalls.list for this configuration.

    lseek was also broken, truncating the result without checking for
    overflow.  lseek however was already broken before the consolidation;
    it aliased lseek64 so would return an out-of-range value, resulting in
    architecturally undefined behavior in the caller if it tried to use a
    non-sign-extended value with a 32-bit instruction.  This patch adds a
    custom lseek implementation in C for n32, which calls __lseek64 to get
    the 64-bit value then checks for overflow.

    Because the prior lseek breakage did not show in test results, and the
    lseek64 breakage showed only indirectly through tests of ftello64,
    test coverage was clearly inadequate.  This patch extends
    io/test-lfs.c to test the lseek64 return value (at a point where it
    has already seeked over 2GB into a file), and then to test the lseek
    return value (with the latter's expectations depending on whether
    off_t is smaller than off64_t).

    Tested for mips64 n32.  Also tested test-lfs for x86_64 and x86, where
    as expected it passes.

        [BZ #21019]
        * sysdeps/unix/sysv/linux/mips/mips64/n32/syscalls.list (lseek64):
        New syscall entry.
        * sysdeps/unix/sysv/linux/mips/mips64/n32/lseek.c: New file.
        * io/test-lfs.c (do_test): Test offset returned from lseek64 and
        lseek.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                          |    7 +++++
 io/test-lfs.c                                      |   21 +++++++++++++++
 .../epoll_create.c => mips/mips64/n32/lseek.c}     |   28 +++++++++----------
 .../unix/sysv/linux/mips/mips64/n32/syscalls.list  |    4 +++
 4 files changed, 45 insertions(+), 15 deletions(-)
 copy sysdeps/unix/sysv/linux/{generic/epoll_create.c =>
mips/mips64/n32/lseek.c} (68%)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35463-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 02 23:11:51 2017
Return-Path: <glibc-bugs-return-35463-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 105243 invoked by alias); 2 Jan 2017 23:11:51 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 105195 invoked by uid 48); 2 Jan 2017 23:11:47 -0000
From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21019] [mips] n32 lseek incorrect on overflow
Date: Mon, 02 Jan 2017 23:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jsm28 at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-21019-131-vLI5IHRj3E@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21019-131@http.sourceware.org/bugzilla/>
References: <bug-21019-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00024.txt.bz2
Content-length: 567

https://sourceware.org/bugzilla/show_bug.cgi?id=21019

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.25

--- Comment #2 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Fixed for 2.25.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35464-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Jan 03 16:26:14 2017
Return-Path: <glibc-bugs-return-35464-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 54376 invoked by alias); 3 Jan 2017 16:26:13 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 50507 invoked by uid 55); 3 Jan 2017 16:26:00 -0000
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/19390] Integer overflow in strncat
Date: Tue, 03 Jan 2017 16:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: 2.22
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security+
X-Bugzilla-Changed-Fields:
Message-ID: <bug-19390-131-tUzCcWBcOD@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-19390-131@http.sourceware.org/bugzilla/>
References: <bug-19390-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00025.txt.bz2
Content-length: 2318

https://sourceware.org/bugzilla/show_bug.cgi?id=19390

--- Comment #9 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  8dad72997af2be0dc72a4bc7dbe82d85c90334fc (commit)
      from  d4d629e6187e33050902824a94498b6096eacac9 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8dad72997af2be0dc72a4bc7dbe82d85c90334fc

commit 8dad72997af2be0dc72a4bc7dbe82d85c90334fc
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Tue Jan 3 12:19:12 2017 -0200

    Fix x86 strncat optimized implementation for large sizes

    Similar to BZ#19387, BZ#21014, and BZ#20971, both x86 sse2 strncat
    optimized assembly implementations do not handle the size overflow
    correctly.

    The x86_64 one is in fact an issue with strcpy-sse2-unaligned, but
    that is triggered also with strncat optimized implementation.

    This patch uses a similar strategy used on 3daef2c8ee4df2, where
    saturared math is used for overflow case.

    Checked on x86_64-linux-gnu and i686-linux-gnu.  It fixes BZ #19390.

        [BZ #19390]
        * string/test-strncat.c (test_main): Add tests with SIZE_MAX as
        maximum string size.
        * sysdeps/i386/i686/multiarch/strcat-sse2.S (STRCAT): Avoid overflow
        in pointer addition.
        * sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S (STRCPY):
        Likewise.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                        |   10 ++++++++++
 string/test-strncat.c                            |   15 +++++++++++++++
 sysdeps/i386/i686/multiarch/strcat-sse2.S        |    2 ++
 sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S |    2 ++
 4 files changed, 29 insertions(+), 0 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35466-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Jan 03 16:26:54 2017
Return-Path: <glibc-bugs-return-35466-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 55141 invoked by alias); 3 Jan 2017 16:26:53 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 55069 invoked by uid 48); 3 Jan 2017 16:26:45 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/19390] Integer overflow in strncat
Date: Tue, 03 Jan 2017 16:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: 2.22
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags: security+
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-19390-131-CyoteMhEgY@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-19390-131@http.sourceware.org/bugzilla/>
References: <bug-19390-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00027.txt.bz2
Content-length: 561

https://sourceware.org/bugzilla/show_bug.cgi?id=19390

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Fixed by 8dad72997af2be.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35465-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Jan 03 16:26:35 2017
Return-Path: <glibc-bugs-return-35465-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 54771 invoked by alias); 3 Jan 2017 16:26:35 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 54646 invoked by uid 48); 3 Jan 2017 16:26:22 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/19390] Integer overflow in strncat
Date: Tue, 03 Jan 2017 16:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: 2.22
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags: security+
X-Bugzilla-Changed-Fields: cc assigned_to target_milestone
Message-ID: <bug-19390-131-dvtNyLdIi6@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-19390-131@http.sourceware.org/bugzilla/>
References: <bug-19390-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00026.txt.bz2
Content-length: 674

https://sourceware.org/bugzilla/show_bug.cgi?id=19390

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg
           Assignee|unassigned at sourceware dot org   |adhemerval.zanella at linaro dot o
                   |                            |rg
   Target Milestone|---                         |2.25

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35467-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Jan 03 19:24:40 2017
Return-Path: <glibc-bugs-return-35467-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 80306 invoked by alias); 3 Jan 2017 19:24:32 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 78942 invoked by uid 55); 3 Jan 2017 19:24:04 -0000
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/20822] race condition in __lll_unlock_elision on powerpc
Date: Tue, 03 Jan 2017 19:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-20822-131-nGFF7uo21s@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20822-131@http.sourceware.org/bugzilla/>
References: <bug-20822-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00028.txt.bz2
Content-length: 1749

https://sourceware.org/bugzilla/show_bug.cgi?id=20822

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  e9a96ea1aca4ebaa7c86e8b83b766f118d689d0f (commit)
      from  daaff5cc793acdd4f8667fca3b901647b4c34363 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=e9a96ea1aca4ebaa7c86e8b83b766f118d689d0f

commit e9a96ea1aca4ebaa7c86e8b83b766f118d689d0f
Author: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Date:   Tue Jan 3 17:16:02 2017 -0200

    powerpc: Fix write-after-destroy in lock elision [BZ #20822]

    The update of *adapt_count after the release of the lock causes a race
    condition when thread A unlocks, thread B continues and destroys the
    mutex, and thread A writes to *adapt_count.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                         |   13 +++++++++++++
 sysdeps/unix/sysv/linux/powerpc/elision-lock.c    |   10 +++++++---
 sysdeps/unix/sysv/linux/powerpc/elision-trylock.c |    7 ++++---
 sysdeps/unix/sysv/linux/powerpc/elision-unlock.c  |   15 +++++++++------
 4 files changed, 33 insertions(+), 12 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35468-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Jan 03 19:26:20 2017
Return-Path: <glibc-bugs-return-35468-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 89133 invoked by alias); 3 Jan 2017 19:26:19 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 88979 invoked by uid 48); 3 Jan 2017 19:26:07 -0000
From: "tuliom at linux dot vnet.ibm.com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/20822] race condition in __lll_unlock_elision on powerpc
Date: Tue, 03 Jan 2017 19:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tuliom at linux dot vnet.ibm.com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: tuliom at linux dot vnet.ibm.com
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status assigned_to target_milestone
Message-ID: <bug-20822-131-Mjt4n78pyQ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20822-131@http.sourceware.org/bugzilla/>
References: <bug-20822-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00029.txt.bz2
Content-length: 550

https://sourceware.org/bugzilla/show_bug.cgi?id=20822

Tulio Magno Quites Machado Filho <tuliom at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at sourceware dot org   |tuliom at linux dot vnet.ibm.com
   Target Milestone|---                         |2.25

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35469-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Jan 03 20:42:11 2017
Return-Path: <glibc-bugs-return-35469-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 49550 invoked by alias); 3 Jan 2017 20:42:11 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 48795 invoked by uid 55); 3 Jan 2017 20:41:57 -0000
From: "joseph at codesourcery dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/20822] race condition in __lll_unlock_elision on powerpc
Date: Tue, 03 Jan 2017 20:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joseph at codesourcery dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: tuliom at linux dot vnet.ibm.com
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-20822-131-Be8tkYmII8@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20822-131@http.sourceware.org/bugzilla/>
References: <bug-20822-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00030.txt.bz2
Content-length: 286

https://sourceware.org/bugzilla/show_bug.cgi?id=20822

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
If the commit fixes the bug, it should be marked as FIXED.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35470-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Jan 03 21:18:29 2017
Return-Path: <glibc-bugs-return-35470-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 74343 invoked by alias); 3 Jan 2017 21:18:28 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 74131 invoked by uid 48); 3 Jan 2017 21:18:16 -0000
From: "cybernenea11 at yandex dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug localedata/20862] mo_MD@cyrillic: new locale
Date: Tue, 03 Jan 2017 21:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: localedata
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: cybernenea11 at yandex dot com
X-Bugzilla-Status: WAITING
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-20862-131-mPs8MVFFyq@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20862-131@http.sourceware.org/bugzilla/>
References: <bug-20862-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00031.txt.bz2
Content-length: 342

https://sourceware.org/bugzilla/show_bug.cgi?id=20862

--- Comment #6 from Vlad <cybernenea11 at yandex dot com> ---
Created attachment 9737
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9737&action=edit
Moldovan Cyrillic language locale rev 0.3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35471-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Jan 03 21:25:27 2017
Return-Path: <glibc-bugs-return-35471-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 105948 invoked by alias); 3 Jan 2017 21:25:26 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 105790 invoked by uid 48); 3 Jan 2017 21:25:14 -0000
From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21022] New: [microblaze] __backtrace get_frame_size namespace
Date: Tue, 03 Jan 2017 21:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jsm28 at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone cf_gcchost
Message-ID: <bug-21022-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00032.txt.bz2
Content-length: 740

https://sourceware.org/bugzilla/show_bug.cgi?id=21022

            Bug ID: 21022
           Summary: [microblaze] __backtrace get_frame_size namespace
           Product: glibc
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: jsm28 at gcc dot gnu.org
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---
              Host: microblaze*-*-*

The MicroBlaze implementation of __backtrace uses an inline function
get_frame_size which is not static, causing many linknamespace tests to fail.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35472-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 01:07:11 2017
Return-Path: <glibc-bugs-return-35472-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 59957 invoked by alias); 4 Jan 2017 01:07:10 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 59666 invoked by uid 55); 4 Jan 2017 01:06:58 -0000
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21022] [microblaze] __backtrace get_frame_size namespace
Date: Wed, 04 Jan 2017 01:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21022-131-8jlySi9KOp@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21022-131@http.sourceware.org/bugzilla/>
References: <bug-21022-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00033.txt.bz2
Content-length: 1717

https://sourceware.org/bugzilla/show_bug.cgi?id=21022

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  2b18fe78fe7217430ed42d3284636c732793e352 (commit)
      from  785fcbaef39a82f7bf2e60de0b10df0f2f09a6d9 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=2b18fe78fe7217430ed42d3284636c732793e352

commit 2b18fe78fe7217430ed42d3284636c732793e352
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Wed Jan 4 01:06:04 2017 +0000

    Fix MicroBlaze __backtrace get_frame_size namespace (bug 21022).

    Many linknamespace tests fail for MicroBlaze because __backtrace (as
    brought in by libc_fatal.c) uses an inline function get_frame_size
    which is not declared static.  This patch fixes it to be declared
    static.

    Tested (compilation tests) with build-many-glibcs.py.

        [BZ #21022]
        * sysdeps/microblaze/backtrace.c (get_frame_size): Make static.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                      |    5 +++++
 sysdeps/microblaze/backtrace.c |    2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35473-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 01:07:43 2017
Return-Path: <glibc-bugs-return-35473-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 60517 invoked by alias); 4 Jan 2017 01:07:43 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 60337 invoked by uid 48); 4 Jan 2017 01:07:29 -0000
From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21022] [microblaze] __backtrace get_frame_size namespace
Date: Wed, 04 Jan 2017 01:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jsm28 at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-21022-131-HBJoddhdTO@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21022-131@http.sourceware.org/bugzilla/>
References: <bug-21022-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00034.txt.bz2
Content-length: 567

https://sourceware.org/bugzilla/show_bug.cgi?id=21022

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.25

--- Comment #2 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Fixed for 2.25.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35474-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 11:34:54 2017
Return-Path: <glibc-bugs-return-35474-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 123114 invoked by alias); 4 Jan 2017 11:34:53 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 122983 invoked by uid 48); 4 Jan 2017 11:34:40 -0000
From: "tuliom at linux dot vnet.ibm.com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/20822] race condition in __lll_unlock_elision on powerpc
Date: Wed, 04 Jan 2017 11:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tuliom at linux dot vnet.ibm.com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: tuliom at linux dot vnet.ibm.com
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-20822-131-0No4h3hwF1@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20822-131@http.sourceware.org/bugzilla/>
References: <bug-20822-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00035.txt.bz2
Content-length: 620

https://sourceware.org/bugzilla/show_bug.cgi?id=20822

Tulio Magno Quites Machado Filho <tuliom at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Tulio Magno Quites Machado Filho <tuliom at linux dot vnet.ibm.com> ---
Fixed in 2.25.
Backport for 2.23 and 2.24 will be prepared soon.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35475-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 12:24:35 2017
Return-Path: <glibc-bugs-return-35475-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 38970 invoked by alias); 4 Jan 2017 12:24:33 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 38848 invoked by uid 48); 4 Jan 2017 12:24:18 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/21018] Add memcchr function
Date: Wed, 04 Jan 2017 12:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-21018-131-bGvHWFDY6c@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21018-131@http.sourceware.org/bugzilla/>
References: <bug-21018-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00036.txt.bz2
Content-length: 1229

https://sourceware.org/bugzilla/show_bug.cgi?id=21018

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
I am still skeptical how common this specific function is based solely on
stackoverflow reports.  FreeBSD usage itself seems not really widespread and
only occurs in basically two places [1] (it does not invalidate the possible
usefulness of the symbol, but show that it usage might be somewhat limited).

Also, it does not seems to be reimplemented in many places (not at least with
same name) on other projects [2].

If you want to pursuit the possible inclusion on glibc, I would recommend start
a discussion on libc-alpha maillist.

[1] https://github.com/freebsd/freebsd/search?utf8=%E2%9C%93&q=memcchr
[2] https://codesearch.debian.net/search?q=memcchr

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35476-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 12:39:04 2017
Return-Path: <glibc-bugs-return-35476-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 73568 invoked by alias); 4 Jan 2017 12:39:04 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 72962 invoked by uid 48); 4 Jan 2017 12:38:52 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/19586] IFUNC selection logic requires improvement for string and memory routines for x86_64 arch.
Date: Wed, 04 Jan 2017 12:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: dep_changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: WAITING
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-19586-131-ppXyWItd2Z@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-19586-131@http.sourceware.org/bugzilla/>
References: <bug-19586-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00037.txt.bz2
Content-length: 555

https://sourceware.org/bugzilla/show_bug.cgi?id=19586
Bug 19586 depends on bug 18880, which changed state.

Bug 18880 Summary: Wrong selector in x86_64/multiarch/memcpy.S
https://sourceware.org/bugzilla/show_bug.cgi?id=18880

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35477-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 12:39:04 2017
Return-Path: <glibc-bugs-return-35477-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 73620 invoked by alias); 4 Jan 2017 12:39:04 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 72924 invoked by uid 48); 4 Jan 2017 12:38:49 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/18880] Wrong selector in x86_64/multiarch/memcpy.S
Date: Wed, 04 Jan 2017 12:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: 2.24
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-18880-131-NAa9QA7p0g@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-18880-131@http.sourceware.org/bugzilla/>
References: <bug-18880-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00038.txt.bz2
Content-length: 702

https://sourceware.org/bugzilla/show_bug.cgi?id=18880

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg
         Resolution|---                         |FIXED

--- Comment #21 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Fixed by 14a1d7cc4c4fd5ee8.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35478-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 12:44:04 2017
Return-Path: <glibc-bugs-return-35478-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 84217 invoked by alias); 4 Jan 2017 12:44:03 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 84026 invoked by uid 48); 4 Jan 2017 12:43:48 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/19776] Improve sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S
Date: Wed, 04 Jan 2017 12:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-19776-131-DFyBiYdPUY@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-19776-131@http.sourceware.org/bugzilla/>
References: <bug-19776-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00039.txt.bz2
Content-length: 725

https://sourceware.org/bugzilla/show_bug.cgi?id=19776

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg
         Resolution|---                         |FIXED

--- Comment #71 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Fixed by c867597bff2562180a18da4b8dba89d24e8b65c4.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35479-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 14:20:22 2017
Return-Path: <glibc-bugs-return-35479-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 104321 invoked by alias); 4 Jan 2017 14:20:22 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 104116 invoked by uid 48); 4 Jan 2017 14:20:08 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/20558] POSIX bcopy/bzero decls do not implement Object Size Checking
Date: Wed, 04 Jan 2017 14:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-20558-131-EYHe56FPrl@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20558-131@http.sourceware.org/bugzilla/>
References: <bug-20558-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00040.txt.bz2
Content-length: 1175

https://sourceware.org/bugzilla/show_bug.cgi?id=20558

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
From features.h, default if other than _GNU_SOURCE or _DEFAULT_SOURCE is
defined _DEFAULT_SOURCE is used.  This is the case for the compiler usage on
first case (gcc -O2 -D_FORTIFY_SOURCE=2).

Now, if one explicit specific _POSIX_SOURCE (second case), _DEFAULT_SOURCE is
then not defined and then __USE_MISC is also not defined. __USE_MISC sets if
the fortified macros for bzero/bcopy will be used.

This is the expected behavior imho opinion and the way to use the fortified
wrappers for bzero/bcopy is to explicit defines _DEFAULT_SOURCE or __USE_MISC
when _POSIX_SOURCE is used.

This is not a bug IMHO.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35480-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 14:22:01 2017
Return-Path: <glibc-bugs-return-35480-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 105648 invoked by alias); 4 Jan 2017 14:22:00 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 105372 invoked by uid 48); 4 Jan 2017 14:21:47 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/20558] POSIX bcopy/bzero decls do not implement Object Size Checking
Date: Wed, 04 Jan 2017 14:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-20558-131-iStTNXZrGM@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20558-131@http.sourceware.org/bugzilla/>
References: <bug-20558-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00041.txt.bz2
Content-length: 482

https://sourceware.org/bugzilla/show_bug.cgi?id=20558

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |adhemerval.zanella at linaro dot o
                   |                            |rg

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35481-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 16:26:59 2017
Return-Path: <glibc-bugs-return-35481-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 104797 invoked by alias); 4 Jan 2017 16:26:59 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 104191 invoked by uid 48); 4 Jan 2017 16:26:45 -0000
From: "bruno at clisp dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence
Date: Wed, 04 Jan 2017 16:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: bruno at clisp dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-13701-131-IKOpKKqqVD@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13701-131@http.sourceware.org/bugzilla/>
References: <bug-13701-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00042.txt.bz2
Content-length: 3400

https://sourceware.org/bugzilla/show_bug.cgi?id=13701

Bruno Haible <bruno at clisp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bruno at clisp dot org

--- Comment #4 from Bruno Haible <bruno at clisp dot org> ---
There is also a second test case from the Linux test project, This one
considers readers and writers that have the same assigned priority:

$ wget
https://raw.githubusercontent.com/linux-test-project/ltp/master/testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-2.c
$ wget
https://raw.githubusercontent.com/linux-test-project/ltp/master/testcases/open_posix_testsuite/include/posixtest.h
$ gcc -O -Wall 2-2.c -lpthread
$ ./a.out 
main: attempt read lock
main: acquired read lock
main: create wr_thread, with priority: 2
wr_thread: attempt write lock
main: create rd_thread, with priority: 2
rd_thread: attempt read lock
rd_thread: acquired read lock
rd_thread: unlock read lock
Test FAILED: rd_thread did not block on read lock, when a reader owns the lock,
and an equal priority writer is waiting for the lock

Re comment 3:
> if Thread Execution Scheduling is supported (and glibc claims it is)
Yes. The symbol _POSIX_THREAD_PRIORITY_SCHEDULING is defined by glibc. It is
actually defined in <bits/posix_opt.h> with a comment:

/* We provide priority scheduling for threads.  */
#define _POSIX_THREAD_PRIORITY_SCHEDULING       200809L

The value is a positive constant.
Per http://pubs.opengroup.org/onlinepubs/007904875/basedefs/xbd_chap02.html and
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html this
means that glibc supports the Thread Priority Scheduling option of POSIX at
compile time and at run time.

The test activates the SCHED_FIFO on all of its threads. Therefore the premises
of the sentence "If the Thread Execution Scheduling option is supported, and
the threads involved in the lock are executing with the scheduling policies
SCHED_FIFO or SCHED_RR, the calling thread shall not acquire the lock if a
writer holds the lock or if writers of higher or equal priority are blocked on
the lock; otherwise, the calling thread shall acquire the lock." from
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_rdlock.html
are fulfilled. And the writer and readers in this test case have equal
priority.

> Implementing the special requirements for Thread Execution Scheduling seems difficult, especially in an efficient way
Implementing the handling of readers and writers of different priority (test
case 2-1.c) is some work, indeed. But the handling of readers and writers of
equal priority is nearly complete in glibc: The non-portable flag
PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP does it. Only the functions
pthread_rwlock_init and pthread_rwlockattr_init would have to be changed.

rwlocks without the "writers get the rwlock in preference to readers [of the
same priority]" guarantee are quite unreliable (no way to guarantee that
writers will not get starve, except if there's only 1 reader thread - but then
one can just use a normal mutex as well), I'm arguing in
http://lists.gnu.org/archive/html/bug-gnulib/2017-01/msg00037.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35482-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 16:30:50 2017
Return-Path: <glibc-bugs-return-35482-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 18344 invoked by alias); 4 Jan 2017 16:30:45 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 3630 invoked by uid 48); 4 Jan 2017 16:30:29 -0000
From: "bruno at clisp dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence
Date: Wed, 04 Jan 2017 16:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: bruno at clisp dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-13701-131-cxBbvU6StI@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13701-131@http.sourceware.org/bugzilla/>
References: <bug-13701-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00043.txt.bz2
Content-length: 500

https://sourceware.org/bugzilla/show_bug.cgi?id=13701

--- Comment #5 from Bruno Haible <bruno at clisp dot org> ---
By the way, there's also the bug that PTHREAD_RWLOCK_PREFER_WRITER_NP does not
behave like one would intuitively except: it still prefers readers. See the
BUGS section of
http://man7.org/linux/man-pages/man3/pthread_rwlockattr_setkind_np.3.html. (I
checked the glibc code: the man page is right.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35483-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 16:48:34 2017
Return-Path: <glibc-bugs-return-35483-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 54408 invoked by alias); 4 Jan 2017 16:48:32 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 54288 invoked by uid 55); 4 Jan 2017 16:48:19 -0000
From: "joseph at codesourcery dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/20558] POSIX bcopy/bzero decls do not implement Object Size Checking
Date: Wed, 04 Jan 2017 16:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joseph at codesourcery dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-20558-131-AZv5qr0Xlv@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20558-131@http.sourceware.org/bugzilla/>
References: <bug-20558-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00044.txt.bz2
Content-length: 536

https://sourceware.org/bugzilla/show_bug.cgi?id=20558

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Fortification should be orthogonal to other feature test macros.  That is, 
any function should be fortified if that function is declared, 
fortification for that function is supported and fortification is enabled.  
This should be independent of which header the declaration is obtained 
from.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35484-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 18:11:13 2017
Return-Path: <glibc-bugs-return-35484-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 22898 invoked by alias); 4 Jan 2017 18:11:13 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 22759 invoked by uid 48); 4 Jan 2017 18:10:59 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/20558] POSIX bcopy/bzero decls do not implement Object Size Checking
Date: Wed, 04 Jan 2017 18:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-20558-131-nMxCUo3ltl@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20558-131@http.sourceware.org/bugzilla/>
References: <bug-20558-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00045.txt.bz2
Content-length: 536

https://sourceware.org/bugzilla/show_bug.cgi?id=20558

--- Comment #3 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
In this case I think the definitions to declare bzero/bcopy on string/string.h
is out the sync of the ones on strings.h.  The former just use __USE_MISC to
declare the bzero/etc. where the latter also adds !defined __USE_XOPEN2K8.  My
understanding of the conform tests is the latter should be the correct one.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35485-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 18:17:39 2017
Return-Path: <glibc-bugs-return-35485-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 36175 invoked by alias); 4 Jan 2017 18:17:39 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 36012 invoked by uid 55); 4 Jan 2017 18:17:26 -0000
From: "joseph at codesourcery dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/20558] POSIX bcopy/bzero decls do not implement Object Size Checking
Date: Wed, 04 Jan 2017 18:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joseph at codesourcery dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-20558-131-9AkwoQrLz6@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20558-131@http.sourceware.org/bugzilla/>
References: <bug-20558-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00046.txt.bz2
Content-length: 613

https://sourceware.org/bugzilla/show_bug.cgi?id=20558

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
No standard includes those functions in string.h, only in strings.h.  
Thus __USE_MISC is correct in string.h; they can't be declared in string.h 
in strict conformance modes for any standard, whereas XSI POSIX before 
2008 includes these functions in strings.h (and non-XSI doesn't include 
strings.h at all before 2008) so !defined __USE_XOPEN2K8 is appropriate 
there.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35486-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 18:25:53 2017
Return-Path: <glibc-bugs-return-35486-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 108656 invoked by alias); 4 Jan 2017 18:25:53 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 107533 invoked by uid 48); 4 Jan 2017 18:25:37 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/20558] POSIX bcopy/bzero decls do not implement Object Size Checking
Date: Wed, 04 Jan 2017 18:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-20558-131-N7PkWsetrw@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20558-131@http.sourceware.org/bugzilla/>
References: <bug-20558-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00047.txt.bz2
Content-length: 555

https://sourceware.org/bugzilla/show_bug.cgi?id=20558

--- Comment #5 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
So, at least then for string.h, the fortification omission of bzero/bcopy seems
correct: string3.h is included in string.h and then the fortified version is
just guarded by __USE_MISC.

I think correct solution would be to add a new fortified header meant to be
included only by strings.h with the fortified macros for bzero/bcopy.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35487-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 21:02:34 2017
Return-Path: <glibc-bugs-return-35487-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 121337 invoked by alias); 4 Jan 2017 21:02:34 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 121143 invoked by uid 55); 4 Jan 2017 21:02:21 -0000
From: "dave.anglin at bell dot net" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/21016] pthread_cond support is broken on hppa
Date: Wed, 04 Jan 2017 21:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.26
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dave.anglin at bell dot net
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21016-131-USYPK876kN@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21016-131@http.sourceware.org/bugzilla/>
References: <bug-21016-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00048.txt.bz2
Content-length: 1956

https://sourceware.org/bugzilla/show_bug.cgi?id=21016

--- Comment #3 from dave.anglin at bell dot net ---
On 2017-01-02, at 3:21 PM, triegel at redhat dot com wrote:

> Carlos has said he would take care of it.  I'm aware of two issues blocking
> this: atomics don't work in all cases (stores should use the kernel helper
> too), and the additional compatibility requirements for old initializers
> (IIRC).  To get the condvar files to compile, just copy over the new
> pthread_cond_t members from, say, x86 pthreadtypes.h to hppa's pthreadtypes.h.


I had a successful build by copying over the pthread_cond_t initial member from
x86.
I kept the old hppa member for the moment to get the same current alignment. 
Fortunately,
the sizes are the same (48).  I updated PTHREAD_COND_INITIALIZER to default.

I removed the LinuxThreads compatibility code although this is still a work in
progress:

        modified:   sysdeps/hppa/nptl/bits/pthreadtypes.h
        deleted:    sysdeps/unix/sysv/linux/hppa/internaltypes.h
        modified:   sysdeps/unix/sysv/linux/hppa/pthread.h
        deleted:    sysdeps/unix/sysv/linux/hppa/pthread_cond_broadcast.c
        deleted:    sysdeps/unix/sysv/linux/hppa/pthread_cond_destroy.c
        modified:   sysdeps/unix/sysv/linux/hppa/pthread_cond_init.c
        deleted:    sysdeps/unix/sysv/linux/hppa/pthread_cond_signal.c
        deleted:    sysdeps/unix/sysv/linux/hppa/pthread_cond_wait.c

Would like to get rid of pthread_cond_init.c and use default.

There is essentially zero code still using LinuxThreads in Debian, so I can't
see any reason to
try and retain compatibility with it.  With new union, I don't see how to
reliably check for the
LinuxThreads initializer.

In gcc, we use the kernel helper for stores so hopefully implementing this
shouldn't be hard.

--
John David Anglin       dave.anglin@bell.net

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35488-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 23:09:12 2017
Return-Path: <glibc-bugs-return-35488-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 96939 invoked by alias); 4 Jan 2017 23:09:12 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 96781 invoked by uid 48); 4 Jan 2017 23:08:58 -0000
From: "triegel at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence
Date: Wed, 04 Jan 2017 23:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: triegel at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-13701-131-lOMFpXwdJU@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13701-131@http.sourceware.org/bugzilla/>
References: <bug-13701-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00049.txt.bz2
Content-length: 278

https://sourceware.org/bugzilla/show_bug.cgi?id=13701

--- Comment #6 from Torvald Riegel <triegel at redhat dot com> ---
Raised this as a POSIX bug:
http://austingroupbugs.net/view.php?id=1111

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35489-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 23:09:58 2017
Return-Path: <glibc-bugs-return-35489-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 98272 invoked by alias); 4 Jan 2017 23:09:58 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 98109 invoked by uid 48); 4 Jan 2017 23:09:45 -0000
From: "triegel at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence
Date: Wed, 04 Jan 2017 23:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: triegel at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: see_also
Message-ID: <bug-13701-131-0xVIfe6r1U@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13701-131@http.sourceware.org/bugzilla/>
References: <bug-13701-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00050.txt.bz2
Content-length: 467

https://sourceware.org/bugzilla/show_bug.cgi?id=13701

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |http://austingroupbugs.net/
                   |                            |view.php?id=1111

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35490-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jan 04 23:12:20 2017
Return-Path: <glibc-bugs-return-35490-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 100932 invoked by alias); 4 Jan 2017 23:12:19 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 100679 invoked by uid 48); 4 Jan 2017 23:12:06 -0000
From: "triegel at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence
Date: Wed, 04 Jan 2017 23:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: triegel at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-13701-131-30ejDEs5bH@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13701-131@http.sourceware.org/bugzilla/>
References: <bug-13701-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00051.txt.bz2
Content-length: 861

https://sourceware.org/bugzilla/show_bug.cgi?id=13701

--- Comment #7 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Bruno Haible from comment #5)
> By the way, there's also the bug that PTHREAD_RWLOCK_PREFER_WRITER_NP does
> not behave like one would intuitively except: it still prefers readers. See
> the BUGS section of
> http://man7.org/linux/man-pages/man3/pthread_rwlockattr_setkind_np.3.html.
> (I checked the glibc code: the man page is right.)

I have built a new, more scalable rwlock last year that should be committed
soon and that supports this mode (though there's not a lot the implementation
can do because of recursive rdlocks being allowed -- and we're certainly not
going to track which reader exactly has acquired a particular rdlock).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35491-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 01:24:04 2017
Return-Path: <glibc-bugs-return-35491-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 26407 invoked by alias); 5 Jan 2017 01:24:03 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 26191 invoked by uid 48); 5 Jan 2017 01:23:50 -0000
From: "bruno at clisp dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence
Date: Thu, 05 Jan 2017 01:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: bruno at clisp dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-13701-131-1OkZ2em06z@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13701-131@http.sourceware.org/bugzilla/>
References: <bug-13701-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00052.txt.bz2
Content-length: 555

https://sourceware.org/bugzilla/show_bug.cgi?id=13701

--- Comment #8 from Bruno Haible <bruno at clisp dot org> ---
(In reply to Torvald Riegel from comment #7)
> we're certainly not going to track which reader exactly has acquired a
> particular rdlock
It could be done by allocating a variable in thread-local storage
(pthread_key_create). But I agree that such an implementation would be costly
in pthread_rwlock_init (since pthread_key_create does a linear search).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35492-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 10:51:25 2017
Return-Path: <glibc-bugs-return-35492-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 80218 invoked by alias); 5 Jan 2017 10:51:22 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 79721 invoked by uid 48); 5 Jan 2017 10:51:09 -0000
From: "james410 at cowgill dot org.uk" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21026] New: [MIPS] readahead syscall is broken on n64
Date: Thu, 05 Jan 2017 10:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: james410 at cowgill dot org.uk
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone
Message-ID: <bug-21026-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00053.txt.bz2
Content-length: 1405

https://sourceware.org/bugzilla/show_bug.cgi?id=21026

            Bug ID: 21026
           Summary: [MIPS] readahead syscall is broken on n64
           Product: glibc
           Version: 2.24
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: james410 at cowgill dot org.uk
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

The readahead syscall is broken on mips n64. The 64-bit offset argument is
split across 2 registers when it should be passed in a single register. I've
only checked this with glibc 2.24.

I added some code to the kernel to check the arguments it was receiving and it
prints this for the 3 mips architectures:

# cat readahead.c
#define _GNU_SOURCE
#include <fcntl.h>

int main(void)
{
        readahead(42, 1234567890987654321, 6543210);
        return 0;
}
# ./readahead-32 
[  648.838746] sys_readahead(fd = 42, off = 1234567890987654321, count =
6543210)
# ./readahead-n32
[  652.595124] sys_readahead(fd = 42, off = 1234567890987654321, count =
6543210)
# ./readahead-n64
[  654.767523] sys_readahead(fd = 42, off = 2976652465, count = 287445236)

Note that:
1234567890987654321 = 2976652465 | 287445236 << 32

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35493-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 11:35:03 2017
Return-Path: <glibc-bugs-return-35493-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 73066 invoked by alias); 5 Jan 2017 11:35:02 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 66064 invoked by uid 48); 5 Jan 2017 11:34:49 -0000
From: "james410 at cowgill dot org.uk" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21026] [MIPS] readahead syscall is broken on n64
Date: Thu, 05 Jan 2017 11:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: james410 at cowgill dot org.uk
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21026-131-2MyBV0zxVt@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21026-131@http.sourceware.org/bugzilla/>
References: <bug-21026-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00054.txt.bz2
Content-length: 563

https://sourceware.org/bugzilla/show_bug.cgi?id=21026

--- Comment #1 from James Cowgill <james410 at cowgill dot org.uk> ---
Hmm, should there be an Implies file at
sysdeps/unix/sysv/linux/mips/mips64/n64/Implies containing
unix/sysv/linux/wordsize-64 ? Or is that going to have much larger
consequences.

If not, I would guess the readahead line needs to be copied from
sysdeps/unix/sysv/linux/wordsize-64/syscalls.list into
sysdeps/unix/sysv/linux/mips/mips64/n64/syscalls.list

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35494-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 12:05:54 2017
Return-Path: <glibc-bugs-return-35494-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 27713 invoked by alias); 5 Jan 2017 12:05:54 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 27056 invoked by uid 48); 5 Jan 2017 12:05:48 -0000
From: "triegel at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence
Date: Thu, 05 Jan 2017 12:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: triegel at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-13701-131-U9IY36YeIB@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13701-131@http.sourceware.org/bugzilla/>
References: <bug-13701-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00055.txt.bz2
Content-length: 791

https://sourceware.org/bugzilla/show_bug.cgi?id=13701

--- Comment #9 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Bruno Haible from comment #8)
> (In reply to Torvald Riegel from comment #7)
> > we're certainly not going to track which reader exactly has acquired a
> > particular rdlock
> It could be done by allocating a variable in thread-local storage
> (pthread_key_create). But I agree that such an implementation would be
> costly in pthread_rwlock_init (since pthread_key_create does a linear
> search).

It's not just that.  If a thread acquires more than one rwlock as a reader, it
has to track a set of acquired rwlocks, and query inclusion in this set on
every rdlock call.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35495-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 13:20:22 2017
Return-Path: <glibc-bugs-return-35495-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 48615 invoked by alias); 5 Jan 2017 13:20:22 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 41787 invoked by uid 48); 5 Jan 2017 13:20:10 -0000
From: "ldv at sourceware dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21026] [MIPS] readahead syscall is broken on n64
Date: Thu, 05 Jan 2017 13:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ldv at sourceware dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-21026-131-HDgZKx18cM@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21026-131@http.sourceware.org/bugzilla/>
References: <bug-21026-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00056.txt.bz2
Content-length: 702

https://sourceware.org/bugzilla/show_bug.cgi?id=21026

Dmitry V. Levin <ldv at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2017-01-05
                 CC|                            |ldv at sourceware dot org
     Ever confirmed|0                           |1

--- Comment #2 from Dmitry V. Levin <ldv at sourceware dot org> ---
I suppose this bug was found by readahead.test from strace test suite.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35496-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 13:26:03 2017
Return-Path: <glibc-bugs-return-35496-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 70787 invoked by alias); 5 Jan 2017 13:26:03 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 70345 invoked by uid 48); 5 Jan 2017 13:25:49 -0000
From: "james410 at cowgill dot org.uk" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21026] [MIPS] readahead syscall is broken on n64
Date: Thu, 05 Jan 2017 13:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: james410 at cowgill dot org.uk
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21026-131-nGYgjIyhI5@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21026-131@http.sourceware.org/bugzilla/>
References: <bug-21026-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00057.txt.bz2
Content-length: 342

https://sourceware.org/bugzilla/show_bug.cgi?id=21026

--- Comment #3 from James Cowgill <james410 at cowgill dot org.uk> ---
(In reply to Dmitry V. Levin from comment #2)
> I suppose this bug was found by readahead.test from strace test suite.

Yes it was :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35497-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 14:06:10 2017
Return-Path: <glibc-bugs-return-35497-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 78662 invoked by alias); 5 Jan 2017 14:06:10 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 78532 invoked by uid 55); 5 Jan 2017 14:05:57 -0000
From: "joseph at codesourcery dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21026] [MIPS] readahead syscall is broken on n64
Date: Thu, 05 Jan 2017 14:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joseph at codesourcery dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21026-131-8QeeEGaCX1@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21026-131@http.sourceware.org/bugzilla/>
References: <bug-21026-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00058.txt.bz2
Content-length: 776

https://sourceware.org/bugzilla/show_bug.cgi?id=21026

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
sysdeps/unix/sysv/linux/wordsize-64 cannot be used for n64 because it 
implies struct stat = struct stat64, which is not the case for n64.

I suppose https://sourceware.org/ml/libc-alpha/2016-09/msg00527.html needs 
to be reviewed (with a careful check against the kernel ABI for all 
supported glibc configurations).  Unfortunately I don't see a way for the 
glibc testsuite to verify correctness here (by passing function arguments 
that would produce a different return from the syscall if the arguments 
are passed incorrectly).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35498-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 15:25:36 2017
Return-Path: <glibc-bugs-return-35498-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 49235 invoked by alias); 5 Jan 2017 15:25:36 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 49151 invoked by uid 48); 5 Jan 2017 15:25:23 -0000
From: "ldv at sourceware dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21026] [MIPS] readahead syscall is broken on n64
Date: Thu, 05 Jan 2017 15:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ldv at sourceware dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21026-131-VC3PO6eBx1@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21026-131@http.sourceware.org/bugzilla/>
References: <bug-21026-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00059.txt.bz2
Content-length: 1244

https://sourceware.org/bugzilla/show_bug.cgi?id=21026

--- Comment #5 from Dmitry V. Levin <ldv at sourceware dot org> ---
(In reply to joseph@codesourcery.com from comment #4)
> sysdeps/unix/sysv/linux/wordsize-64 cannot be used for n64 because it 
> implies struct stat = struct stat64, which is not the case for n64.

Anyway, readahead should be added, it's a straightforward fix.

> I suppose https://sourceware.org/ml/libc-alpha/2016-09/msg00527.html needs 
> to be reviewed (with a careful check against the kernel ABI for all 
> supported glibc configurations).

I'm afraid this is too late for 2.25, and the bug is quite user visible: it
breaks strace test suite.

> Unfortunately I don't see a way for the 
> glibc testsuite to verify correctness here (by passing function arguments 
> that would produce a different return from the syscall if the arguments 
> are passed incorrectly).

Yes, readahead is not a regular syscall that would produce different return
values.  Anyway, one can use strace, it's better than nothing.  For most of
architectures supported by glibc it's verified to be correct wrt decoding of
readahead syscall.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35499-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 16:07:30 2017
Return-Path: <glibc-bugs-return-35499-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 81896 invoked by alias); 5 Jan 2017 16:07:28 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 81668 invoked by uid 48); 5 Jan 2017 16:07:15 -0000
From: "roche at httrack dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/20116] use after free in pthread_create
Date: Thu, 05 Jan 2017 16:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.3.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: critical
X-Bugzilla-Who: roche at httrack dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: carlos at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-20116-131-fmMVqDotIu@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20116-131@http.sourceware.org/bugzilla/>
References: <bug-20116-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00060.txt.bz2
Content-length: 549

https://sourceware.org/bugzilla/show_bug.cgi?id=20116

Xavier Roche <roche at httrack dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roche at httrack dot com

--- Comment #10 from Xavier Roche <roche at httrack dot com> ---
Bug also confirmed on our side. High load seem to amplify probability of crash,
though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35501-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 17:37:45 2017
Return-Path: <glibc-bugs-return-35501-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 62869 invoked by alias); 5 Jan 2017 17:37:45 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 62251 invoked by uid 48); 5 Jan 2017 17:37:32 -0000
From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21026] [MIPS] readahead syscall is broken on n64
Date: Thu, 05 Jan 2017 17:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jsm28 at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-21026-131-2nDcIGM5UQ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21026-131@http.sourceware.org/bugzilla/>
References: <bug-21026-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00062.txt.bz2
Content-length: 567

https://sourceware.org/bugzilla/show_bug.cgi?id=21026

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.25

--- Comment #7 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Fixed for 2.25.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35500-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 17:37:04 2017
Return-Path: <glibc-bugs-return-35500-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 59687 invoked by alias); 5 Jan 2017 17:37:04 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 58515 invoked by uid 55); 5 Jan 2017 17:36:52 -0000
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21026] [MIPS] readahead syscall is broken on n64
Date: Thu, 05 Jan 2017 17:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21026-131-kC6tsOZgXm@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21026-131@http.sourceware.org/bugzilla/>
References: <bug-21026-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00061.txt.bz2
Content-length: 1943

https://sourceware.org/bugzilla/show_bug.cgi?id=21026

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  30733525c6867c160261db1afade6326000f9f75 (commit)
      from  3ecd616cc1782210d09c9678ec1a48899f19145b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=30733525c6867c160261db1afade6326000f9f75

commit 30733525c6867c160261db1afade6326000f9f75
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Thu Jan 5 17:35:53 2017 +0000

    Fix MIPS n64 readahead (bug 21026).

    As noted in bug 20126, MIPS n64 uses an incorrect implementation of
    readahead intended for 32-bit systems.  This patch adds a
    syscalls.list entry to fix this.  An updated version of the
    consolidation patch
    <https://sourceware.org/ml/libc-alpha/2016-09/msg00527.html> could
    remove this syscalls.list entry again.

    Tested with compilation (only) for mips64; the nature of the syscall
    doesn't allow for a glibc test to detect this issue.

        [BZ #21026]
        * sysdeps/unix/sysv/linux/mips/mips64/n64/syscalls.list
        (readahead): New syscall entry.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                          |    6 ++++++
 .../unix/sysv/linux/mips/mips64/n64/syscalls.list  |    2 ++
 2 files changed, 8 insertions(+), 0 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35502-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 18:42:03 2017
Return-Path: <glibc-bugs-return-35502-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 99326 invoked by alias); 5 Jan 2017 18:42:03 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 99209 invoked by uid 55); 5 Jan 2017 18:41:50 -0000
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/20558] POSIX bcopy/bzero decls do not implement Object Size Checking
Date: Thu, 05 Jan 2017 18:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-20558-131-dRTvmZaJ3k@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20558-131@http.sourceware.org/bugzilla/>
References: <bug-20558-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00063.txt.bz2
Content-length: 3193

https://sourceware.org/bugzilla/show_bug.cgi?id=20558

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  38765ab68f329fd84a5984decc8953f8c89d6e5c (commit)
      from  983a9637f730fa265e228509d090c4c5f031d713 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=38765ab68f329fd84a5984decc8953f8c89d6e5c

commit 38765ab68f329fd84a5984decc8953f8c89d6e5c
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Thu Jan 5 10:07:24 2017 -0200

    Use fortify macros for b{zero,copy} along decl from strings.h

    As described in BZ#20558, bzero and bcopy declaration can only benefit
    from fortified macros when decl came from string.h and when __USE_MISC
    is defined (default behaviour).

    This is due no standard includes those functions in string.h, so they
    are only declared if __USE_MISC is defined (as pointed out in comment 4).
    However fortification should be orthogona to other features test macros,
    i.e, any function should be fortified if that function is declared.

    To fix this behavior, the patch moved the bzero, bcopy, and
    __explicit_bzero_chk to a common header (string/bits/strings_fortified.h)
    and explicit fortified inclusion macros similar to string.h is added
    on strings.h.  This allows to get fortified declarions by only including
    strings.h.

    Checked on x86_64-linux-gnu and along on a bootstrap installation to check
    if the fortified are correctly triggered with example from bug report.

        [BZ #20558]
        * string/bits/string3.h [__USE_MISC] (bcopy): Move to
        strings_fortified.h.
        [__USE_MISC] (bzero): Likewise.
        [__USE_MISC] (explicit_bzero): Likewise.
        * string/strings.h: Include strings_fortified.h.
        * string/Makefile (headers): Add strings_fortified.h.
        * string/bits/strings_fortified.h: New file.
        * include/bits/strings_fortified.h: Likewise.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                          |   12 +++++++
 include/bits/strings_fortified.h                   |    1 +
 string/Makefile                                    |    3 +-
 string/bits/string3.h                              |   21 +-----------
 .../bits/strings_fortified.h                       |   35 +++++++++----------
 string/strings.h                                   |    8 ++++
 6 files changed, 41 insertions(+), 39 deletions(-)
 create mode 100644 include/bits/strings_fortified.h
 copy sysdeps/arm/tst-armtlsdesclocmod.c => string/bits/strings_fortified.h
(55%)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35503-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 18:42:24 2017
Return-Path: <glibc-bugs-return-35503-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 99645 invoked by alias); 5 Jan 2017 18:42:23 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 99590 invoked by uid 48); 5 Jan 2017 18:42:13 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug string/20558] POSIX bcopy/bzero decls do not implement Object Size Checking
Date: Thu, 05 Jan 2017 18:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: string
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-20558-131-DGHOtXqIgv@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20558-131@http.sourceware.org/bugzilla/>
References: <bug-20558-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00064.txt.bz2
Content-length: 619

https://sourceware.org/bugzilla/show_bug.cgi?id=20558

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.25

--- Comment #7 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Fixed by 38765ab68f329fd84a5.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35504-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 22:48:37 2017
Return-Path: <glibc-bugs-return-35504-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 105109 invoked by alias); 5 Jan 2017 22:48:34 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 39676 invoked by uid 48); 5 Jan 2017 22:47:55 -0000
From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug math/21028] New: Fallback fesetexceptflag should always succeed
Date: Thu, 05 Jan 2017 22:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: math
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jsm28 at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-21028-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00065.txt.bz2
Content-length: 896

https://sourceware.org/bugzilla/show_bug.cgi?id=21028

            Bug ID: 21028
           Summary: Fallback fesetexceptflag should always succeed
           Product: glibc
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

The fallback implementation of fesetexceptflag currently fails if any
exceptions are specified.  It should always succeed, because the exception
state is always that all exceptions (if any are defined in <fenv.h> but not
supported in this configuration) are always clear, just as fallback
fetestexcept always succeeds and fallback fesetenv always succeeds unless asked
to set FE_NOMASK_ENV.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35505-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 23:17:16 2017
Return-Path: <glibc-bugs-return-35505-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 118048 invoked by alias); 5 Jan 2017 23:17:15 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 117311 invoked by uid 55); 5 Jan 2017 23:17:03 -0000
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug math/21028] Fallback fesetexceptflag should always succeed
Date: Thu, 05 Jan 2017 23:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: math
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21028-131-eiDKpGnMUD@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21028-131@http.sourceware.org/bugzilla/>
References: <bug-21028-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00066.txt.bz2
Content-length: 2200

https://sourceware.org/bugzilla/show_bug.cgi?id=21028

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  f68fcd95d34d2f2ac286b9ebb64e3a07e36a20cf (commit)
      from  38765ab68f329fd84a5984decc8953f8c89d6e5c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f68fcd95d34d2f2ac286b9ebb64e3a07e36a20cf

commit f68fcd95d34d2f2ac286b9ebb64e3a07e36a20cf
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Thu Jan 5 23:15:47 2017 +0000

    Make fallback fesetexceptflag always succeed (bug 21028).

    The fallback implementation of fesetexceptflag currently fails if any
    exceptions are specified.  It should always succeed, because the
    exception state is always that all exceptions (if any are defined in
    <fenv.h> but not supported in this configuration) are always clear,
    just as fallback fetestexcept always succeeds and fallback fesetenv
    always succeeds unless asked to set FE_NOMASK_ENV.

    This patch fixes it accordingly.  Together with the patch to
    test-fexcept.c to allow feraiseexcept to fail in another place, this
    stops that test from failing for MIPS soft-float.

    Tested for mips64 soft-float.

        [BZ #21028]
        * math/fsetexcptflg.c (__fesetexceptflag): Always return 0.
        * math/test-fexcept.c (test_set): Allow failure of feraiseexcept
        if EXCEPTION_TESTS returns false.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog           |    7 +++++++
 math/fsetexcptflg.c |    5 +++--
 math/test-fexcept.c |    8 +++++++-
 3 files changed, 17 insertions(+), 3 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35506-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jan 05 23:17:35 2017
Return-Path: <glibc-bugs-return-35506-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 119119 invoked by alias); 5 Jan 2017 23:17:35 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 118446 invoked by uid 48); 5 Jan 2017 23:17:22 -0000
From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug math/21028] Fallback fesetexceptflag should always succeed
Date: Thu, 05 Jan 2017 23:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: math
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jsm28 at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-21028-131-G8qtLvnOCY@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21028-131@http.sourceware.org/bugzilla/>
References: <bug-21028-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00067.txt.bz2
Content-length: 567

https://sourceware.org/bugzilla/show_bug.cgi?id=21028

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.25

--- Comment #2 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Fixed for 2.25.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35507-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Jan 06 09:45:55 2017
Return-Path: <glibc-bugs-return-35507-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 15629 invoked by alias); 6 Jan 2017 09:45:55 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 15521 invoked by uid 48); 6 Jan 2017 09:45:42 -0000
From: "0xe2.0x9a.0x9b at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug admin/5012] Why must glibc be compiled with optimizations enabled?
Date: Fri, 06 Jan 2017 09:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: admin
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: 0xe2.0x9a.0x9b at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: carlos at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-5012-131-AL7wgR0bbf@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-5012-131@http.sourceware.org/bugzilla/>
References: <bug-5012-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00068.txt.bz2
Content-length: 429

https://sourceware.org/bugzilla/show_bug.cgi?id=5012

Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |0xe2.0x9a.0x9b at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35508-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Jan 06 10:10:43 2017
Return-Path: <glibc-bugs-return-35508-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 62856 invoked by alias); 6 Jan 2017 10:10:42 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 62364 invoked by uid 48); 6 Jan 2017 10:10:37 -0000
From: "0xe2.0x9a.0x9b at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21029] New: glibc-2.23 (and later) fails to compile with -fno-omit-frame-pointer on i386
Date: Fri, 06 Jan 2017 10:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: 0xe2.0x9a.0x9b at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone attachments.created
Message-ID: <bug-21029-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00069.txt.bz2
Content-length: 1638

https://sourceware.org/bugzilla/show_bug.cgi?id=21029

            Bug ID: 21029
           Summary: glibc-2.23 (and later) fails to compile with
                    -fno-omit-frame-pointer on i386
           Product: glibc
           Version: 2.23
            Status: UNCONFIRMED
          Severity: normal
          Priority: P1
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: 0xe2.0x9a.0x9b at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 9741
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9741&action=edit
Gentoo build log: sys-libs:glibc-2.23-r3:20170106-093416.log

I am compiling all packages on my machines with -fno-omit-frame-pointer because
it enables debuggers and performance measurement tools (gdb, perf record,
valgrind memcheck, valgrind callgrind).

However, glibc-2.23 fails to compile on my system:

../sysdeps/unix/sysv/linux/posix_fallocate.c: In function 'posix_fallocate':
../sysdeps/unix/sysv/linux/posix_fallocate.c:39:1: error: bp cannot be used in
asm here

../sysdeps/unix/sysv/linux/posix_fallocate64.c: In function
'__posix_fallocate64_l64':
../sysdeps/unix/sysv/linux/posix_fallocate64.c:42:1: error: bp cannot be used
in asm here

This bug is most likely caused by sysdeps/unix/sysv/linux/i386/sysdep.h:570:

# define LOADREGS_6(arg1, arg2, arg3, arg4, arg5, arg6) \
        register unsigned int _a6 asm ("ebp") = (unsigned int) (arg6); \
        LOADREGS_5 (arg1, arg2, arg3, arg4, arg5)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35509-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Jan 06 20:11:27 2017
Return-Path: <glibc-bugs-return-35509-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 55724 invoked by alias); 6 Jan 2017 20:11:27 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 37392 invoked by uid 48); 6 Jan 2017 20:11:13 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21029] glibc-2.23 (and later) fails to compile with -fno-omit-frame-pointer on i386
Date: Fri, 06 Jan 2017 20:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-21029-131-sRsLOhpDvP@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21029-131@http.sourceware.org/bugzilla/>
References: <bug-21029-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00070.txt.bz2
Content-length: 1144

https://sourceware.org/bugzilla/show_bug.cgi?id=21029

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
AFAIK it is not an issue because 'ebp' is this context is used on kernel ABI to
pass the 6th argument (the file sysdeps/unix/sysv/linux/i386/sysdep.h contains
a comment about the linux convention for i686).

Unless there is a compiler option to make easier to create syscall macros (so
compiler can restore ebp somehow), you will need to explict disable
-fno-omit-frame-pointer on these files.

Another option would to code this syscalls in asm, but I will advise against
since to make i386 to use the generic code is exactly to avoid the
proliferation of such implementations.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35510-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Jan 06 20:22:03 2017
Return-Path: <glibc-bugs-return-35510-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 5069 invoked by alias); 6 Jan 2017 20:22:02 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 4971 invoked by uid 48); 6 Jan 2017 20:21:49 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug build/20615] glibc build fails when using --with-cpu=power9 --enable-multi-arch
Date: Fri, 06 Jan 2017 20:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: build
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: tuliom at linux dot vnet.ibm.com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-20615-131-L1V7LS8Yyc@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20615-131@http.sourceware.org/bugzilla/>
References: <bug-20615-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00071.txt.bz2
Content-length: 685

https://sourceware.org/bugzilla/show_bug.cgi?id=20615

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #2 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
I could not reproduce it on master (f68fcd95d34d2f2ac) with gcc 6.2.1 and
binutils 2.27.0.20161129. Is this still happening?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35511-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Jan 06 21:06:17 2017
Return-Path: <glibc-bugs-return-35511-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 50523 invoked by alias); 6 Jan 2017 21:06:16 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 50328 invoked by uid 48); 6 Jan 2017 21:06:05 -0000
From: "schwab@linux-m68k.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug build/20729] glibc-2.24 fails to build for i486 with -Os
Date: Fri, 06 Jan 2017 21:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: build
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-20729-131-x55ZzuyhI5@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20729-131@http.sourceware.org/bugzilla/>
References: <bug-20729-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00072.txt.bz2
Content-length: 528

https://sourceware.org/bugzilla/show_bug.cgi?id=20729

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |0xe2.0x9a.0x9b at gmail dot com

--- Comment #28 from Andreas Schwab <schwab@linux-m68k.org> ---
*** Bug 21029 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35512-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Jan 06 21:06:17 2017
Return-Path: <glibc-bugs-return-35512-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 50535 invoked by alias); 6 Jan 2017 21:06:17 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 50298 invoked by uid 48); 6 Jan 2017 21:06:04 -0000
From: "schwab@linux-m68k.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21029] glibc-2.23 (and later) fails to compile with -fno-omit-frame-pointer on i386
Date: Fri, 06 Jan 2017 21:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-21029-131-dIDI8doh57@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21029-131@http.sourceware.org/bugzilla/>
References: <bug-21029-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00073.txt.bz2
Content-length: 589

https://sourceware.org/bugzilla/show_bug.cgi?id=21029

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
Fixed in commit 6b1df8b27f.

*** This bug has been marked as a duplicate of bug 20729 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35513-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Jan 07 10:15:35 2017
Return-Path: <glibc-bugs-return-35513-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 112933 invoked by alias); 7 Jan 2017 10:15:34 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 110097 invoked by uid 48); 7 Jan 2017 10:15:18 -0000
From: "0xe2.0x9a.0x9b at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21029] glibc-2.23 (and later) fails to compile with -fno-omit-frame-pointer on i386
Date: Sat, 07 Jan 2017 10:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: 0xe2.0x9a.0x9b at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21029-131-aqplzIYrHr@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21029-131@http.sourceware.org/bugzilla/>
References: <bug-21029-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00074.txt.bz2
Content-length: 1802

https://sourceware.org/bugzilla/show_bug.cgi?id=21029

--- Comment #3 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail dot com> ---
(In reply to Adhemerval Zanella from comment #1)
> AFAIK it is not an issue because 'ebp' is this context is used on kernel ABI
> to pass the 6th argument (the file sysdeps/unix/sysv/linux/i386/sysdep.h
> contains a comment about the linux convention for i686).

It's an issue as long as it is fixable in glibc. The fact is, it *is* fixable
in glibc.

It's an issue as long as it is fixable in gcc. The fact is, it *is* fixable in
gcc.

It's an issue as long as it is fixable in the Linux kernel. The fact is, it
*is* fixable in Linux kernel.

It's an issue as long as it is fixable on my machine alone. The fact is, it
*is* fixable on my machine alone.

The question is: which software component is the easiest to change and will
have the most impact on the world.

> Unless there is a compiler option to make easier to create syscall macros
> (so compiler can restore ebp somehow), you will need to explict disable
> -fno-omit-frame-pointer on these files.
> 
> Another option would to code this syscalls in asm, but I will advise against
> since to make i386 to use the generic code is exactly to avoid the
> proliferation of such implementations.

The best solution is the update the definition of INTERNAL_SYSCALL with
something like this:

    LOADREGS_##nr(args)
    asm volatile (
    PUSHREGS_ASM_##nr(args)
    "call *%%gs:%P2"
    POPREGS_ASM_##nr
    : "=a" (resultvar)

#define PUSHREGS_ASM_5(args...) "" // empty
#define PUSHREGS_ASM_6(args...) "push %%ebp; mov arg6, %%ebp;"

#define POPREGS_ASM_5 "" // empty
#define POPREGS_ASM_6 "pop %%ebp"

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35514-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Jan 07 10:19:39 2017
Return-Path: <glibc-bugs-return-35514-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 7864 invoked by alias); 7 Jan 2017 10:19:39 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 7728 invoked by uid 48); 7 Jan 2017 10:19:25 -0000
From: "0xe2.0x9a.0x9b at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21029] glibc-2.23 (and later) fails to compile with -fno-omit-frame-pointer on i386
Date: Sat, 07 Jan 2017 10:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: 0xe2.0x9a.0x9b at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21029-131-myAHg2StfD@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21029-131@http.sourceware.org/bugzilla/>
References: <bug-21029-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00075.txt.bz2
Content-length: 608

https://sourceware.org/bugzilla/show_bug.cgi?id=21029

--- Comment #4 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail dot com> ---
(In reply to Andreas Schwab from comment #2)
> Fixed in commit 6b1df8b27f.
> 
> *** This bug has been marked as a duplicate of bug 20729 ***

https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=6b1df8b27f

6b1df8b27f is inferior to the solution I provided in my previous comment.
Please revert 6b1df8b27f and commit a patch based on my proposal. Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35515-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Jan 07 10:53:29 2017
Return-Path: <glibc-bugs-return-35515-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 37851 invoked by alias); 7 Jan 2017 10:53:29 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 37679 invoked by uid 48); 7 Jan 2017 10:53:16 -0000
From: "0xe2.0x9a.0x9b at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21029] glibc-2.23 (and later) fails to compile with -fno-omit-frame-pointer on i386
Date: Sat, 07 Jan 2017 10:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: 0xe2.0x9a.0x9b at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-21029-131-rLgJlsZXR2@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21029-131@http.sourceware.org/bugzilla/>
References: <bug-21029-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00076.txt.bz2
Content-length: 872

https://sourceware.org/bugzilla/show_bug.cgi?id=21029

--- Comment #5 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail dot com> ---
(In reply to Jan Ziak (http://atom-symbol.net) from comment #3)
> The best solution is the update the definition of INTERNAL_SYSCALL with
> something like this:
> 
>     LOADREGS_##nr(args)
>     asm volatile (
>     PUSHREGS_ASM_##nr(args)
>     "call *%%gs:%P2"
>     POPREGS_ASM_##nr
>     : "=a" (resultvar)
> 
> #define PUSHREGS_ASM_5(args...) "" // empty
> #define PUSHREGS_ASM_6(args...) "push %%ebp; mov arg6, %%ebp;"
> 
> #define POPREGS_ASM_5 "" // empty
> #define POPREGS_ASM_6 "pop %%ebp"

#define PUSHREGS_ASM_6(args...) "pushl arg6; push %%ebp; mov 4(%%esp), %%ebp;"

#define POPREGS_ASM_6 "pop %%ebp; add $4, %%esp"

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35516-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Jan 07 13:35:49 2017
Return-Path: <glibc-bugs-return-35516-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 3568 invoked by alias); 7 Jan 2017 13:35:49 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 3409 invoked by uid 48); 7 Jan 2017 13:35:36 -0000
From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/21029] glibc-2.23 (and later) fails to compile with -fno-omit-frame-pointer on i386
Date: Sat, 07 Jan 2017 13:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adhemerval.zanella at linaro dot org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on resolution everconfirmed
Message-ID: <bug-21029-131-FDxIOfBr2N@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21029-131@http.sourceware.org/bugzilla/>
References: <bug-21029-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00077.txt.bz2
Content-length: 6016

https://sourceware.org/bugzilla/show_bug.cgi?id=21029

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2017-01-07
         Resolution|DUPLICATE                   |---
     Ever confirmed|0                           |1

--- Comment #6 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Jan Ziak (http://atom-symbol.net) from comment #3)
> (In reply to Adhemerval Zanella from comment #1)
> > AFAIK it is not an issue because 'ebp' is this context is used on kernel ABI
> > to pass the 6th argument (the file sysdeps/unix/sysv/linux/i386/sysdep.h
> > contains a comment about the linux convention for i686).
> 
> It's an issue as long as it is fixable in glibc. The fact is, it *is*
> fixable in glibc.
> 
> It's an issue as long as it is fixable in gcc. The fact is, it *is* fixable
> in gcc.
> 
> It's an issue as long as it is fixable in the Linux kernel. The fact is, it
> *is* fixable in Linux kernel.
> 
> It's an issue as long as it is fixable on my machine alone. The fact is, it
> *is* fixable on my machine alone.
> 
> The question is: which software component is the easiest to change and will
> have the most impact on the world.

It was a bad wording from my part, my idea is since we already have a solution
for correct 6-argument passing for compiler that might use the 6th argument
passing it should not be an issue on GLIBC.

However I wrongly assumed this could not be accomplished on this code, which it
wrong.

> 
> > Unless there is a compiler option to make easier to create syscall macros
> > (so compiler can restore ebp somehow), you will need to explict disable
> > -fno-omit-frame-pointer on these files.
> > 
> > Another option would to code this syscalls in asm, but I will advise against
> > since to make i386 to use the generic code is exactly to avoid the
> > proliferation of such implementations.
> 
> The best solution is the update the definition of INTERNAL_SYSCALL with
> something like this:
> 
>     LOADREGS_##nr(args)
>     asm volatile (
>     PUSHREGS_ASM_##nr(args)
>     "call *%%gs:%P2"
>     POPREGS_ASM_##nr
>     : "=a" (resultvar)
> 
> #define PUSHREGS_ASM_5(args...) "" // empty
> #define PUSHREGS_ASM_6(args...) "push %%ebp; mov arg6, %%ebp;"
> 
> #define POPREGS_ASM_5 "" // empty
> #define POPREGS_ASM_6 "pop %%ebp"

Your solution is wrong and do not address the issue in question.  This snippet
is not related to C macros for syscall macros, but rather to auto-generated
syscalls which is code and implemented directly in assembly.

Six argument syscalls from C macros were fixed by a9fe4c5aa8e53ee3 and then
optimized on 98ad631cd0a77.  The optimization takes in consideration than if
you are using GCC 5, the compiler an properly spill %ebx when needed, we can
inline syscalls with 6 arguments.

The problem is it does not take in consideration that for fomit-frame-pointer
compiler option on i686 we can not use this optimization (as for PROF which was
corrected by 95b097779a6).

I could get a working build with the scratch patch:

-----

diff --git a/sysdeps/unix/sysv/linux/i386/Makefile
b/sysdeps/unix/sysv/linux/i386/Makefile
index 9609752..cd5bb43 100644
--- a/sysdeps/unix/sysv/linux/i386/Makefile
+++ b/sysdeps/unix/sysv/linux/i386/Makefile
@@ -3,7 +3,7 @@ default-abi := 32

 # %ebp is used to pass the 6th argument to system calls, so these
 # system calls are incompatible with a frame pointer.
-uses-6-syscall-arguments = -fomit-frame-pointer
+uses-6-syscall-arguments = -DNO_OPTIMIZE_FOR_GCC_5 

 ifeq ($(subdir),misc)
 sysdep_routines += ioperm iopl vm86
@@ -24,6 +24,7 @@ CFLAGS-semtimedop.os += $(uses-6-syscall-arguments)
 endif

 ifeq ($(subdir),elf)
+sysdep-dl-routines += libc-do-syscall
 sysdep-others += lddlibc4
 install-bin += lddlibc4
 endif
@@ -61,6 +62,8 @@ ifeq ($(subdir),nptl)
 # pull in __syscall_error routine
 libpthread-routines += sysdep
 libpthread-shared-only-routines += sysdep
+CFLAGS-pthread_cond_wait.o += $(uses-6-syscall-arguments)
+CFLAGS-pthread_cond_wait.os += $(uses-6-syscall-arguments)
 CFLAGS-pthread_rwlock_timedrdlock.o += $(uses-6-syscall-arguments)
 CFLAGS-pthread_rwlock_timedrdlock.os += $(uses-6-syscall-arguments)
 CFLAGS-pthread_rwlock_timedwrlock.o += $(uses-6-syscall-arguments)
diff --git a/sysdeps/unix/sysv/linux/i386/libc-do-syscall.S
b/sysdeps/unix/sysv/linux/i386/libc-do-syscall.S
index f706c6d..ef9e513 100644
--- a/sysdeps/unix/sysv/linux/i386/libc-do-syscall.S
+++ b/sysdeps/unix/sysv/linux/i386/libc-do-syscall.S
@@ -18,7 +18,7 @@

 #include <sysdep.h>

-#ifndef OPTIMIZE_FOR_GCC_5
+//#ifndef OPTIMIZE_FOR_GCC_5

 /* %eax, %ecx, %edx and %esi contain the values expected by the kernel.
    %edi points to a structure with the values of %ebx, %edi and %ebp.  */
@@ -50,4 +50,4 @@ ENTRY (__libc_do_syscall)
        cfi_restore (ebx)
        ret
 END (__libc_do_syscall)
-#endif
+//#endif
diff --git a/sysdeps/unix/sysv/linux/i386/sysdep.h
b/sysdeps/unix/sysv/linux/i386/sysdep.h
index baf4642..e35cc02 100644
--- a/sysdeps/unix/sysv/linux/i386/sysdep.h
+++ b/sysdeps/unix/sysv/linux/i386/sysdep.h
@@ -46,7 +46,7 @@
    to compile glibc.  Disable GCC 5 optimization when compiling for
    profiling since asm ("ebp") can't be used to put the 6th argument
    in %ebp for syscall.  */
-#if __GNUC_PREREQ (5,0) && !defined PROF
+#if __GNUC_PREREQ (5,0) && !defined PROF && !defined NO_OPTIMIZE_FOR_GCC_5
 # define OPTIMIZE_FOR_GCC_5
 #endif

-----

It is not optimal since we want NO_OPTIMIZE_FOR_GCC_5 only when
omit-frame-pointer is used and it will require most likely an configure check
to do so. I will think in a better solution.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35517-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Jan 07 19:29:23 2017
Return-Path: <glibc-bugs-return-35517-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 85920 invoked by alias); 7 Jan 2017 19:29:23 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 85827 invoked by uid 48); 7 Jan 2017 19:29:10 -0000
From: "leo at yuriev dot ru" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/21031] New: pthread_key_delete() race with thread finalization
Date: Sat, 07 Jan 2017 19:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: leo at yuriev dot ru
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone
Message-ID: <bug-21031-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00078.txt.bz2
Content-length: 1229

https://sourceware.org/bugzilla/show_bug.cgi?id=21031

            Bug ID: 21031
           Summary: pthread_key_delete() race with thread finalization
           Product: glibc
           Version: 2.24
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: leo at yuriev dot ru
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

A race condition could occur between the pthread_key_delete() and the
__nptl_deallocate_tsd().

For instance, __nptl_deallocate_tsd() could call a destructor for the key,
immediately before the pthread_key_delete() invalidates it (from an another
thread), and will continue destructor execution after the completion of
pthread_key_delete().

>From a user code this looks as if the corresponding destructor executes after
the key has been removed by pthread_key_delete(), and there is no way to know
whether was destructor called/executed or not.

Suggest add pthread_rwlock_rdlock() for __nptl_deallocate_tsd() and
pthread_rwlock_wrlock() for pthread_key_delete().

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35518-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Jan 07 20:14:47 2017
Return-Path: <glibc-bugs-return-35518-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 54182 invoked by alias); 7 Jan 2017 20:14:47 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 54099 invoked by uid 48); 7 Jan 2017 20:14:34 -0000
From: "leo at yuriev dot ru" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/21032] New: pthread_key_create() destructors and DSO unloading
Date: Sat, 07 Jan 2017 20:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: leo at yuriev dot ru
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone
Message-ID: <bug-21032-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00079.txt.bz2
Content-length: 1108

https://sourceware.org/bugzilla/show_bug.cgi?id=21032

            Bug ID: 21032
           Summary: pthread_key_create() destructors and DSO unloading
           Product: glibc
           Version: 2.24
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: leo at yuriev dot ru
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

The pthread_key_create() and __nptl_deallocate_tsd() do not track the
references to destructor's DSO like the __cxa_thread_atexit_impl().

Therefore the DSO, which holds a destructor's code, could be unloaded before
destructor execution or before deleting a corresponding key.

So in a complex environment there is no way to know whether it is safe to
unload a particular DSO or some tls-destructors are still left.

Suggest this should be fixed or documented, e.g. that the pthread_create_key()
with a destructor should not be used from lib.so.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35519-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Jan 07 20:15:43 2017
Return-Path: <glibc-bugs-return-35519-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 56301 invoked by alias); 7 Jan 2017 20:15:42 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 55197 invoked by uid 48); 7 Jan 2017 20:15:30 -0000
From: "leo at yuriev dot ru" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/21032] pthread_key_create() destructors and segfault after a DSO unloading
Date: Sat, 07 Jan 2017 20:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.24
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: leo at yuriev dot ru
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: short_desc
Message-ID: <bug-21032-131-iBdOGXYCGQ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-21032-131@http.sourceware.org/bugzilla/>
References: <bug-21032-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00080.txt.bz2
Content-length: 528

https://sourceware.org/bugzilla/show_bug.cgi?id=21032

Leo Yuriev <leo at yuriev dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|pthread_key_create()        |pthread_key_create()
                   |destructors and DSO         |destructors and segfault
                   |unloading                   |after a DSO unloading

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35521-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 09 11:04:50 2017
Return-Path: <glibc-bugs-return-35521-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 22396 invoked by alias); 9 Jan 2017 11:04:50 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 22304 invoked by uid 48); 9 Jan 2017 11:04:37 -0000
From: "tuliom at linux dot vnet.ibm.com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug build/20615] glibc build fails when using --with-cpu=power9 --enable-multi-arch
Date: Mon, 09 Jan 2017 11:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: build
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tuliom at linux dot vnet.ibm.com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: tuliom at linux dot vnet.ibm.com
X-Bugzilla-Target-Milestone: 2.25
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: target_milestone
Message-ID: <bug-20615-131-ymMGry9rL9@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20615-131@http.sourceware.org/bugzilla/>
References: <bug-20615-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00082.txt.bz2
Content-length: 401

https://sourceware.org/bugzilla/show_bug.cgi?id=20615

Tulio Magno Quites Machado Filho <tuliom at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |2.25

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35520-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 09 11:04:34 2017
Return-Path: <glibc-bugs-return-35520-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 22021 invoked by alias); 9 Jan 2017 11:04:33 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 21880 invoked by uid 48); 9 Jan 2017 11:04:20 -0000
From: "tuliom at linux dot vnet.ibm.com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug build/20615] glibc build fails when using --with-cpu=power9 --enable-multi-arch
Date: Mon, 09 Jan 2017 11:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: build
X-Bugzilla-Version: 2.23
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tuliom at linux dot vnet.ibm.com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: tuliom at linux dot vnet.ibm.com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-20615-131-VzuHNTbAQS@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-20615-131@http.sourceware.org/bugzilla/>
References: <bug-20615-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00081.txt.bz2
Content-length: 663

https://sourceware.org/bugzilla/show_bug.cgi?id=20615

Tulio Magno Quites Machado Filho <tuliom at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Tulio Magno Quites Machado Filho <tuliom at linux dot vnet.ibm.com> ---
This issue was fixed by commit 1850ce5a2ea3b908b26165e7e951cd4334129f07 which
forgot to mention this bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35522-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 09 11:10:53 2017
Return-Path: <glibc-bugs-return-35522-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 38133 invoked by alias); 9 Jan 2017 11:10:52 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 36024 invoked by uid 48); 9 Jan 2017 11:10:39 -0000
From: "raji at linux dot vnet.ibm.com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug build/15998] [powerpc] Set arch_minimum_kernel for powerpc LE
Date: Mon, 09 Jan 2017 11:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: build
X-Bugzilla-Version: 2.18
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: raji at linux dot vnet.ibm.com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-15998-131-dMZpNGHvlC@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-15998-131@http.sourceware.org/bugzilla/>
References: <bug-15998-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2017-01/txt/msg00083.txt.bz2
Content-length: 406

https://sourceware.org/bugzilla/show_bug.cgi?id=15998

Rajalakshmi <raji at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |raji at linux dot vnet.ibm.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-35523-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jan 09 14:49:49 2017
Return-Path: <glibc-bugs-return-35523-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 56982 invoked by alias); 9 Jan 2017 14:49:48 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 56947 invoked by uid 89); 9 Jan 2017 14:49:48 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 testsºYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=mounted, Executed, 2632
X-HELO: mail-wm0-f46.google.com
Received: from mail-wm0-f46.google.com (HELO mail-wm0-f46.google.com) (74.125.82.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jan 2017 14:49:46 +0000
Received: by mail-wm0-f46.google.com with SMTP id c206so34812554wme.0        for <glibc-bugs@sourceware.org>; Mon, 09 Jan 2017 06:49:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d\x1e100.net; s 161025;        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;        bh=grJOCOI2+CfiyRVuowno7QDDAGLqZnbPSjCeeWTQRMM=;        b=pC+feHG36mB3DsF8OKn7BkPcWumBR/VF51RYjv8AUkW32sGGwTH41wr2VDHdUry34c         YptEicVWTOsw1nN+mO2/z0OGCs8+37IsLvTTEZgw3kpPFA3GAxVGLPmIzFGSarNC5BGH         /bo7pyGCtADUs4i0UG1ltO3TYeRJwn8dHlmJWAoyUy736XN5k+ukIbRykiPgrug9rj2R         9piGUksbGHsfR8G9pXYnUGxZUYa18V7pi6A4LGt/t7Kpk8pIekUnQdMsG9xdmbyf6q9W         BYuLwVLmaibPttIJtD5TG9R/feZh3Oc2HKzN0XKX6jRF5zYyC6JzpkR/rwz3w+5GEH6b         RP1Q=X-Gm-Message-State: AIkVDXKrjj6z4NIs9yE7mT6sC0BbhOvK8Etw+DrYzNJJebET7ozGCAcSg84ngeBQB/2dbplCXVm8kWMSqNJdqQ=X-Received: by 10.28.1.216 with SMTP id 207mr5066036wmb.7.1483973383887; Mon, 09 Jan 2017 06:49:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.159.234 with HTTP; Mon, 9 Jan 2017 06:49:43 -0800 (PST)
From: RAJESH DASARI <raajeshdasari@gmail.com>
Date: Mon, 09 Jan 2017 14:49:00 -0000
Message-ID: <CAPXMrf_tdrrXf56oozEi70oW8oEKh=0NaS5QASQNJwqS5i6APQ@mail.gmail.com>
Subject: chroot kernel too old error with glibc 2.24
To: glibc-bugs@sourceware.org
Content-Type: text/plain; charset=UTF-8
X-SW-Source: 2017-01/txt/msg00084.txt.bz2
Content-length: 739

Hi ,

I am getting the kernel too old error when trying to install the
4.4.20 kernel image (with glibc2.24) .
My  machine which is mips based and has 2.6.34 kernel installed , i am
trying to install the  new kernel(4.4.20) which has 2.24 glibc version
.


1 . I mounted the latest kernel image on /mnt/latest
2. Executed chroot to that image path
# chroot /mnt/latest
FATAL: kernel too old

I see that in 2.24 release notes, it is mentioned that the minimum
Linux kernel version that this version of the GNU C Library can be
used with is 3.2.

 I am sure this is not a bug in glibc , but could some one help me how
to get rid of this problem ,
I have compiled glibc with --enable-kernel=2.6.32 option but still no help.


Thanks,
Rajesh.