This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fix race in tst-mqueue5
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Carlos O'Donell <carlos at redhat dot com>, "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Date: Wed, 13 Jan 2016 12:00:37 -0200
- Subject: Re: Fix race in tst-mqueue5
- Authentication-results: sourceware.org; auth=none
- References: <569552C6 dot 8050200 at linux dot vnet dot ibm dot com> <5695AF3D dot 3020303 at redhat dot com>
On 12-01-2016 23:58, Carlos O'Donell wrote:
> On 01/12/2016 02:23 PM, Paul E. Murphy wrote:
>> This seems to fix the test for ppc, and probably others too.
>
> Had you considered the 'sleep (1);' on line 394 as another source of problems?
>
> Must it be the case that by the time '(void) pthread_barrier_wait (b3);' returns,
> the SIGRTMIN has been delivered and handled? Why isn't 'sigwait' required to make
> this test operate without a race bewtween checking 'rtmin_cnt != 2' and the signal
> arriving and being handled?
My understanding is let's say due some scheduling the main thread of child process
calls 'mq_notify' before the 'mqrecv' on child thread in child process. In this
case a notification will be send, since eventually child thread in child process
will call 'mqrecv'. This will trigger 'rtmin_handler' and the test at 413 will fail.
I do not know how often this scenario might arise, but it might happen on a heavy
loaded machine.
This is similar of a fix I added on 'nptl/tst-cancel{20,21}.c' where it used a sleep
to add some 'synchronization'. I don't know which a better solution to synchronize
with a thread syscall that will block.
>
> While I agree that any fix that makes tst-mqueue5 fail less spuriously is a good
> thing, I'm curious about your review of the test as a whole (now that I've looked
> at it again).
>
I would say to just remove the spurious synchronization issues, specially the ones
that might arise with the use of 'sleep' in bad ways.
> Cheers,
> Carlos.
>