Async cacellation and pthread_cleanup_push

Async cacellation and pthread_cleanup_push

[Andreas Schwab]

Is pthread_cleanup_push supposed to work together with async
cancellation?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Async cacellation and pthread_cleanup_push

[Florian Weimer via Libc-alpha]

* Andreas Schwab:

> Is pthread_cleanup_push supposed to work together with async
> cancellation?

In our implementation?  I think so.  POSIX doesn't require it, though.

Thanks,
Florian

Re: Async cacellation and pthread_cleanup_push

[Andreas Schwab]

On Aug 04 2021, Florian Weimer wrote:

> * Andreas Schwab:
>
>> Is pthread_cleanup_push supposed to work together with async
>> cancellation?
>
> In our implementation?  I think so.

I don't see how that can work with -fexceptions or in C++, though.  Is
that supported?

> POSIX doesn't require it, though.

Chapter and verse?  Then the LTP test is INVALID.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Async cacellation and pthread_cleanup_push

[Florian Weimer via Libc-alpha]

* Andreas Schwab:

> On Aug 04 2021, Florian Weimer wrote:
>
>> * Andreas Schwab:
>>
>>> Is pthread_cleanup_push supposed to work together with async
>>> cancellation?
>>
>> In our implementation?  I think so.
>
> I don't see how that can work with -fexceptions or in C++, though.  Is
> that supported?

I think it is supposed to work, but it probably is unreliable.

>> POSIX doesn't require it, though.
>
> Chapter and verse?

2.9.5 Thread Cancellation, Thread Cancellation Cleanup Handlers and
Async-Cancel Safety.  The first section calls pthread_cleanup_push a
function, the second section does not list it.

> Then the LTP test is INVALID.

Which test?  It could be a test for Linux extension.

Thanks,
Florian

Re: Async cacellation and pthread_cleanup_push

[Andreas Schwab]

On Aug 04 2021, Florian Weimer wrote:

> * Andreas Schwab:
>
>> On Aug 04 2021, Florian Weimer wrote:
>>
>>> * Andreas Schwab:
>>>
>>>> Is pthread_cleanup_push supposed to work together with async
>>>> cancellation?
>>>
>>> In our implementation?  I think so.
>>
>> I don't see how that can work with -fexceptions or in C++, though.  Is
>> that supported?
>
> I think it is supposed to work, but it probably is unreliable.

Since the compiler puts the exception regions only over function calls
(and -fnon-call-exceptions only covers potentially trapping insns in
addition) the cleanup region will not be fully covered.

>>> POSIX doesn't require it, though.
>>
>> Chapter and verse?
>
> 2.9.5 Thread Cancellation, Thread Cancellation Cleanup Handlers and
> Async-Cancel Safety.  The first section calls pthread_cleanup_push a
> function, the second section does not list it.
>
>> Then the LTP test is INVALID.
>
> Which test?  It could be a test for Linux extension.

testcases/open_posix_testsuite/conformance/interfaces/pthread_cancel/3-1.c

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Async cacellation and pthread_cleanup_push

[Zack Weinberg via Libc-alpha]

On Wed, Aug 4, 2021, at 9:58 AM, Andreas Schwab wrote:
> Is pthread_cleanup_push supposed to work together with async
> cancellation?

Do you mean, is it supported for a sync cancellation to be enabled at the point of a call to pthread_cleanup_push? I am pretty sure that isn’t required to work and I would expect it to have race windows that are difficult to close.

zw

Re: Async cacellation and pthread_cleanup_push

[Petr Vorel]

Hi all,

> * Andreas Schwab:

> > On Aug 04 2021, Florian Weimer wrote:

> >> * Andreas Schwab:

> >>> Is pthread_cleanup_push supposed to work together with async
> >>> cancellation?

> >> In our implementation?  I think so.

> > I don't see how that can work with -fexceptions or in C++, though.  Is
> > that supported?

> I think it is supposed to work, but it probably is unreliable.

> >> POSIX doesn't require it, though.

> > Chapter and verse?

> 2.9.5 Thread Cancellation, Thread Cancellation Cleanup Handlers and
> Async-Cancel Safety.  The first section calls pthread_cleanup_push a
> function, the second section does not list it.

> > Then the LTP test is INVALID.

> Which test?  It could be a test for Linux extension.

FYI tests in testcases/open_posix_testsuite/ are POSIX tests
(not Linux specific).

Kind regards,
Petr

> Thanks,
> Florian

Re: Async cacellation and pthread_cleanup_push

[Petr Vorel]

Hi Florian,

> * Andreas Schwab:

> > Is pthread_cleanup_push supposed to work together with async
> > cancellation?

> In our implementation?  I think so.  POSIX doesn't require it, though.

Would you please share link to POSIX docs where it's stated?
It'd help us to fix LTP POSIX tests.

Kind regards,
Petr

> Thanks,
> Florian

Re: Async cacellation and pthread_cleanup_push

[Florian Weimer via Libc-alpha]

* Petr Vorel:

> Hi Florian,
>
>> * Andreas Schwab:
>
>> > Is pthread_cleanup_push supposed to work together with async
>> > cancellation?
>
>> In our implementation?  I think so.  POSIX doesn't require it, though.
>
> Would you please share link to POSIX docs where it's stated?
> It'd help us to fix LTP POSIX tests.

Not sure if you seen my earlier comment:

[Section] 2.9.5 Thread Cancellation, Thread Cancellation Cleanup
Handlers and Async-Cancel Safety.  The first section calls
pthread_cleanup_push a function, the second section does not list it.

The section number refers to  POSIX.1-2017.

I hope this clarifies the matter.

Thanks,
Florian

Re: Async cacellation and pthread_cleanup_push

[Florian Weimer via Libc-alpha]

* Andreas Schwab:

> On Aug 04 2021, Florian Weimer wrote:
>
>> * Andreas Schwab:
>>
>>> On Aug 04 2021, Florian Weimer wrote:
>>>
>>>> * Andreas Schwab:
>>>>
>>>>> Is pthread_cleanup_push supposed to work together with async
>>>>> cancellation?
>>>>
>>>> In our implementation?  I think so.
>>>
>>> I don't see how that can work with -fexceptions or in C++, though.  Is
>>> that supported?
>>
>> I think it is supposed to work, but it probably is unreliable.
>
> Since the compiler puts the exception regions only over function calls
> (and -fnon-call-exceptions only covers potentially trapping insns in
> addition) the cleanup region will not be fully covered.

I can see how this can happen in theory …

>>>> POSIX doesn't require it, though.
>>>
>>> Chapter and verse?
>>
>> 2.9.5 Thread Cancellation, Thread Cancellation Cleanup Handlers and
>> Async-Cancel Safety.  The first section calls pthread_cleanup_push a
>> function, the second section does not list it.
>>
>>> Then the LTP test is INVALID.
>>
>> Which test?  It could be a test for Linux extension.
>
> testcases/open_posix_testsuite/conformance/interfaces/pthread_cancel/3-1.c

… but I don't see how this applies to this particular test.

Thanks,
Florian

Re: Async cacellation and pthread_cleanup_push

[Petr Vorel]

Hi Florian,

> * Petr Vorel:

> > Hi Florian,

> >> * Andreas Schwab:

> >> > Is pthread_cleanup_push supposed to work together with async
> >> > cancellation?

> >> In our implementation?  I think so.  POSIX doesn't require it, though.

> > Would you please share link to POSIX docs where it's stated?
> > It'd help us to fix LTP POSIX tests.

> Not sure if you seen my earlier comment:

> [Section] 2.9.5 Thread Cancellation, Thread Cancellation Cleanup
> Handlers and Async-Cancel Safety.  The first section calls
> pthread_cleanup_push a function, the second section does not list it.

> The section number refers to  POSIX.1-2017.

> I hope this clarifies the matter.

Great, thanks a lot!

Kind regards,
Petr

> Thanks,
> Florian

Re: Async cacellation and pthread_cleanup_push

[Andreas Schwab]

On Aug 23 2021, Florian Weimer wrote:

> * Andreas Schwab:
>
>> On Aug 04 2021, Florian Weimer wrote:
>>
>>> * Andreas Schwab:
>>>
>>>> On Aug 04 2021, Florian Weimer wrote:
>>>>
>>>>> * Andreas Schwab:
>>>>>
>>>>>> Is pthread_cleanup_push supposed to work together with async
>>>>>> cancellation?
>>>>>
>>>>> In our implementation?  I think so.
>>>>
>>>> I don't see how that can work with -fexceptions or in C++, though.  Is
>>>> that supported?
>>>
>>> I think it is supposed to work, but it probably is unreliable.
>>
>> Since the compiler puts the exception regions only over function calls
>> (and -fnon-call-exceptions only covers potentially trapping insns in
>> addition) the cleanup region will not be fully covered.
>
> I can see how this can happen in theory …

This is not theory, it happens exactly here.

>> testcases/open_posix_testsuite/conformance/interfaces/pthread_cancel/3-1.c
>
> … but I don't see how this applies to this particular test.

There is a non-zero probability that the cancel signal arrives in
thread_func and sleep_loop while it is executing the unprotected
instructions outside of the .LEHB1 to .LEHE1 region:

        movl    $sem, %edi
        call    sem_post
        movq    $0, (%rsp)
        movq    $1000000, 8(%rsp)
        .p2align 4,,10
        .p2align 3
.L2:
        xorl    %esi, %esi
        movq    %rsp, %rdi
.LEHB1:
        call    nanosleep
        subl    $1, %ebx
        jne     .L2
        movl    $.LC0, %edi
        call    puts
.LEHE1:

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Async cacellation and pthread_cleanup_push

[Florian Weimer via Libc-alpha]

* Andreas Schwab:

> On Aug 23 2021, Florian Weimer wrote:
>
>> * Andreas Schwab:
>>
>>> On Aug 04 2021, Florian Weimer wrote:
>>>
>>>> * Andreas Schwab:
>>>>
>>>>> On Aug 04 2021, Florian Weimer wrote:
>>>>>
>>>>>> * Andreas Schwab:
>>>>>>
>>>>>>> Is pthread_cleanup_push supposed to work together with async
>>>>>>> cancellation?
>>>>>>
>>>>>> In our implementation?  I think so.
>>>>>
>>>>> I don't see how that can work with -fexceptions or in C++, though.  Is
>>>>> that supported?
>>>>
>>>> I think it is supposed to work, but it probably is unreliable.
>>>
>>> Since the compiler puts the exception regions only over function calls
>>> (and -fnon-call-exceptions only covers potentially trapping insns in
>>> addition) the cleanup region will not be fully covered.
>>
>> I can see how this can happen in theory …
>
> This is not theory, it happens exactly here.
>
>>> testcases/open_posix_testsuite/conformance/interfaces/pthread_cancel/3-1.c
>>
>> … but I don't see how this applies to this particular test.
>
> There is a non-zero probability that the cancel signal arrives in
> thread_func and sleep_loop while it is executing the unprotected
> instructions outside of the .LEHB1 to .LEHE1 region:
>
>         movl    $sem, %edi
>         call    sem_post
>         movq    $0, (%rsp)
>         movq    $1000000, 8(%rsp)
>         .p2align 4,,10
>         .p2align 3
> .L2:
>         xorl    %esi, %esi
>         movq    %rsp, %rdi
> .LEHB1:
>         call    nanosleep
>         subl    $1, %ebx
>         jne     .L2
>         movl    $.LC0, %edi
>         call    puts
> .LEHE1:

Odd.

Does this happen because sem_post is annotated with __THROWNL?

GCC should ignore __attribute__ ((nothrow)) with -fnon-call-exceptions.

Thanks,
Florian

Re: Async cacellation and pthread_cleanup_push

[Andreas Schwab]

On Aug 23 2021, Florian Weimer wrote:

> GCC should ignore __attribute__ ((nothrow)) with -fnon-call-exceptions.

Wouldn't help the test case since it doesn't use -fnon-call-exceptions.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Async cacellation and pthread_cleanup_push

[Florian Weimer via Libc-alpha]

* Andreas Schwab:

> On Aug 23 2021, Florian Weimer wrote:
>
>> GCC should ignore __attribute__ ((nothrow)) with -fnon-call-exceptions.
>
> Wouldn't help the test case since it doesn't use -fnon-call-exceptions.

I see, thanks.

We should probably take this to the GCC developers.  Or give up entirely
on asynchronous cancellation.

Florian