Ciao Thomas,
this new version of the preempt-rt patch seems to be a good step forward
with respect to a problem I have in a benchmark application I am running
on top of a kernel v2.6.29.4 patched with it on a quad-core Intel(R)
Xeon(R) machine. Within this benchmark I am making use of pthreads and
semaphores and sometime it happens that a call to "sem_wait()" returns
"-1" and sets the "errno" to "512" - which corresponds to "ERESTARTSYS"
- which up to my poor kernel knowledge should never be delivered to the
user space.
Now, with the new version of the preempt-rt patch, the frequency of
these odd "sem_wait()" return values has notably diminished, though not
completely stopped. So, I thought it might be interesting for you if I
share a workaround with you which seems to eliminate the odd
"sem_wait()" return values (as it did work already for preempt-rt patch
version rt17). Note, that this for sure is not a bug fix, but just a
workaround for which I am even not a 100% sure that it is semantically
correct, but maybe it gives you a hint on what might still go wrong in
the RT patch. Pls. find attach the "rcsdiff" output on file
"kernel/futex.c" containing the workaround.
Best regards,
Wolfgang Betz
===================================================================
RCS file: kernel/RCS/futex.c,v
retrieving revision 1.1
diff -r1.1 kernel/futex.c
1839a1840,1849
> // betzw: added WARN_ON(!signal_pending(current))
> if(!signal_pending(current)) {
> static unsigned int warn_count = 1;
>
> // WARN_ON(!signal_pending(current));
> printk(KERN_WARNING "=====> betzw: futex_wait warning #%u\n", warn_count++);
>
> // betzw: trial for a workaround
> set_tsk_thread_flag(current,TIF_SIGPENDING);
> }
2600a2611,2619
>
> // betzw: added WARN_ON(!signal_pending(current))
> if((ret < -256) && !signal_pending(current)) {
> static unsigned int warn_count = 1;
>
> // WARN_ON(!signal_pending(current));
> printk(KERN_WARNING "=====> betzw: do_futex warning (ret: %d, cmd: %d) #%u\n", -ret, cmd, warn_count++);
> }
>
