diff mbox series

nptl: Use SA_RESTART for SIGCANCEL handler

Message ID 20210617125241.1415287-1-adhemerval.zanella@linaro.org
State Committed
Headers
Series nptl: Use SA_RESTART for SIGCANCEL handler |

Checks

Context Check Description
dj/TryBot-apply_patch success Patch applied to master at the time it was sent

Commit Message

Adhemerval Zanella Netto June 17, 2021, 12:52 p.m. UTC 
  The usage of signals to implementation pthread cancellation is an
implementation detail and should not be visible through cancellation
entrypoints.

However now that pthread_cancel always send the SIGCANCEL, some
entrypoint might be interruptable and return EINTR to the caller
(for instance on sem_wait).

Using SA_RESTART hides this, since the cancellation handler should
either act uppon cancellation (if asynchronous cancellation is enable)
or ignore the cancellation internal signal.

Checked on x86_64-linux-gnu and i686-linux-gnu.
---
 nptl/pthread_cancel.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Comments

Andreas Schwab June 17, 2021, 1:03 p.m. UTC | #1 
On Jun 17 2021, Adhemerval Zanella via Libc-alpha wrote:

> diff --git a/nptl/pthread_cancel.c b/nptl/pthread_cancel.c
> index 0698cd2046..cc25ff21f3 100644
> --- a/nptl/pthread_cancel.c
> +++ b/nptl/pthread_cancel.c
> @@ -72,7 +72,11 @@ __pthread_cancel (pthread_t th)
>      {
>        struct sigaction sa;
>        sa.sa_sigaction = sigcancel_handler;
> -      sa.sa_flags = SA_SIGINFO;
> +      /* The signal handle should be non-interruptible to avoid the risk of

            The signal handler should be non-interrupting

Andreas.
Adhemerval Zanella Netto June 17, 2021, 1:04 p.m. UTC | #2 
On 17/06/2021 10:03, Andreas Schwab wrote:
> On Jun 17 2021, Adhemerval Zanella via Libc-alpha wrote:
> 
>> diff --git a/nptl/pthread_cancel.c b/nptl/pthread_cancel.c
>> index 0698cd2046..cc25ff21f3 100644
>> --- a/nptl/pthread_cancel.c
>> +++ b/nptl/pthread_cancel.c
>> @@ -72,7 +72,11 @@ __pthread_cancel (pthread_t th)
>>      {
>>        struct sigaction sa;
>>        sa.sa_sigaction = sigcancel_handler;
>> -      sa.sa_flags = SA_SIGINFO;
>> +      /* The signal handle should be non-interruptible to avoid the risk of
> 
>             The signal handler should be non-interrupting

Ack, I fixed it locally.
Florian Weimer June 18, 2021, 11:38 a.m. UTC | #3 
* Adhemerval Zanella via Libc-alpha:

> The usage of signals to implementation pthread cancellation is an
> implementation detail and should not be visible through cancellation
> entrypoints.
>
> However now that pthread_cancel always send the SIGCANCEL, some
> entrypoint might be interruptable and return EINTR to the caller
> (for instance on sem_wait).
>
> Using SA_RESTART hides this, since the cancellation handler should
> either act uppon cancellation (if asynchronous cancellation is enable)
> or ignore the cancellation internal signal.

I think this still needs a NEWS entry because there have been kernel
bugs in this area (e.g. in CIFS).

> Checked on x86_64-linux-gnu and i686-linux-gnu.
> ---
>  nptl/pthread_cancel.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/nptl/pthread_cancel.c b/nptl/pthread_cancel.c
> index 0698cd2046..cc25ff21f3 100644
> --- a/nptl/pthread_cancel.c
> +++ b/nptl/pthread_cancel.c
> @@ -72,7 +72,11 @@ __pthread_cancel (pthread_t th)
>      {
>        struct sigaction sa;
>        sa.sa_sigaction = sigcancel_handler;
> -      sa.sa_flags = SA_SIGINFO;
> +      /* The signal handle should be non-interruptible to avoid the risk of
> +	 spurious EINTR caused by SIGCANCEL sent to process or if
> +	 pthread_cancel() is called while cancellation is disabled in the
> +	 target thread.  */
> +      sa.sa_flags = SA_SIGINFO | SA_RESTART;
>        __sigemptyset (&sa.sa_mask);
>        __libc_sigaction (SIGCANCEL, &sa, NULL);
>        atomic_store_relaxed (&init_sigcancel, 1);

I really don't feel comfortable reviewing this.  However I think it is
still consistent with the (buggy) SYSCALL_CANCEL implementation:

        int sc_cancel_oldtype = LIBC_CANCEL_ASYNC ();                        \
        sc_ret = INLINE_SYSCALL_CALL (__VA_ARGS__);                          \
        LIBC_CANCEL_RESET (sc_cancel_oldtype);                               \

We temporary enable async cancellation, in which case we unwind through
the signal handler if canceled.  We do not rely on a EINTR error return
from the system call and a cancellation check outside of the signal
handler.  So adding SA_RESTART should really be okay.

Thanks,
Florian
Adhemerval Zanella Netto June 22, 2021, 6:30 p.m. UTC | #4 
On 18/06/2021 08:38, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
> 
>> The usage of signals to implementation pthread cancellation is an
>> implementation detail and should not be visible through cancellation
>> entrypoints.
>>
>> However now that pthread_cancel always send the SIGCANCEL, some
>> entrypoint might be interruptable and return EINTR to the caller
>> (for instance on sem_wait).
>>
>> Using SA_RESTART hides this, since the cancellation handler should
>> either act uppon cancellation (if asynchronous cancellation is enable)
>> or ignore the cancellation internal signal.
> 
> I think this still needs a NEWS entry because there have been kernel
> bugs in this area (e.g. in CIFS).

Ok, I have added the following on "Deprecated and removed features, and 
other changes affecting compatibility"

* The pthread cancellation handler is now setup with SA_RESTART.  It should
  not be visible to application since the cancellation handler should either 
  act uppon cancellation (if asynchronous cancellation is enabled) or
  ignore the cancellation internal signal.

> 
>> Checked on x86_64-linux-gnu and i686-linux-gnu.
>> ---
>>  nptl/pthread_cancel.c | 6 +++++-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/nptl/pthread_cancel.c b/nptl/pthread_cancel.c
>> index 0698cd2046..cc25ff21f3 100644
>> --- a/nptl/pthread_cancel.c
>> +++ b/nptl/pthread_cancel.c
>> @@ -72,7 +72,11 @@ __pthread_cancel (pthread_t th)
>>      {
>>        struct sigaction sa;
>>        sa.sa_sigaction = sigcancel_handler;
>> -      sa.sa_flags = SA_SIGINFO;
>> +      /* The signal handle should be non-interruptible to avoid the risk of
>> +	 spurious EINTR caused by SIGCANCEL sent to process or if
>> +	 pthread_cancel() is called while cancellation is disabled in the
>> +	 target thread.  */
>> +      sa.sa_flags = SA_SIGINFO | SA_RESTART;
>>        __sigemptyset (&sa.sa_mask);
>>        __libc_sigaction (SIGCANCEL, &sa, NULL);
>>        atomic_store_relaxed (&init_sigcancel, 1);
> 
> I really don't feel comfortable reviewing this.  However I think it is
> still consistent with the (buggy) SYSCALL_CANCEL implementation:
> 
>         int sc_cancel_oldtype = LIBC_CANCEL_ASYNC ();                        \
>         sc_ret = INLINE_SYSCALL_CALL (__VA_ARGS__);                          \
>         LIBC_CANCEL_RESET (sc_cancel_oldtype);                               \
> 
> We temporary enable async cancellation, in which case we unwind through
> the signal handler if canceled.  We do not rely on a EINTR error return
> from the system call and a cancellation check outside of the signal
> handler.  So adding SA_RESTART should really be okay.

Yes, we still cancel the thread even for partial results (BZ#12683).
Florian Weimer June 22, 2021, 6:33 p.m. UTC | #5 
* Adhemerval Zanella:

> On 18/06/2021 08:38, Florian Weimer wrote:
>> * Adhemerval Zanella via Libc-alpha:
>> 
>>> The usage of signals to implementation pthread cancellation is an
>>> implementation detail and should not be visible through cancellation
>>> entrypoints.
>>>
>>> However now that pthread_cancel always send the SIGCANCEL, some
>>> entrypoint might be interruptable and return EINTR to the caller
>>> (for instance on sem_wait).
>>>
>>> Using SA_RESTART hides this, since the cancellation handler should
>>> either act uppon cancellation (if asynchronous cancellation is enable)
>>> or ignore the cancellation internal signal.
>> 
>> I think this still needs a NEWS entry because there have been kernel
>> bugs in this area (e.g. in CIFS).
>
> Ok, I have added the following on "Deprecated and removed features, and 
> other changes affecting compatibility"
>
> * The pthread cancellation handler is now setup with SA_RESTART.  It should
>   not be visible to application since the cancellation handler should either 
>   act uppon cancellation (if asynchronous cancellation is enabled) or
>   ignore the cancellation internal signal.

The key change is: The cancellation signal is now sent in more cases,
but this should be transparent to the application due to SA_RESTART.

Thanks,
Florian
Adhemerval Zanella Netto June 22, 2021, 6:50 p.m. UTC | #6 
On 22/06/2021 15:33, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 18/06/2021 08:38, Florian Weimer wrote:
>>> * Adhemerval Zanella via Libc-alpha:
>>>
>>>> The usage of signals to implementation pthread cancellation is an
>>>> implementation detail and should not be visible through cancellation
>>>> entrypoints.
>>>>
>>>> However now that pthread_cancel always send the SIGCANCEL, some
>>>> entrypoint might be interruptable and return EINTR to the caller
>>>> (for instance on sem_wait).
>>>>
>>>> Using SA_RESTART hides this, since the cancellation handler should
>>>> either act uppon cancellation (if asynchronous cancellation is enable)
>>>> or ignore the cancellation internal signal.
>>>
>>> I think this still needs a NEWS entry because there have been kernel
>>> bugs in this area (e.g. in CIFS).
>>
>> Ok, I have added the following on "Deprecated and removed features, and 
>> other changes affecting compatibility"
>>
>> * The pthread cancellation handler is now setup with SA_RESTART.  It should
>>   not be visible to application since the cancellation handler should either 
>>   act uppon cancellation (if asynchronous cancellation is enabled) or
>>   ignore the cancellation internal signal.
> 
> The key change is: The cancellation signal is now sent in more cases,
> but this should be transparent to the application due to SA_RESTART.

I am not sure if we really need to describe this implementation detail
on a NEWS entry.
Florian Weimer June 22, 2021, 6:52 p.m. UTC | #7 
* Adhemerval Zanella:

> On 22/06/2021 15:33, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> On 18/06/2021 08:38, Florian Weimer wrote:
>>>> * Adhemerval Zanella via Libc-alpha:
>>>>
>>>>> The usage of signals to implementation pthread cancellation is an
>>>>> implementation detail and should not be visible through cancellation
>>>>> entrypoints.
>>>>>
>>>>> However now that pthread_cancel always send the SIGCANCEL, some
>>>>> entrypoint might be interruptable and return EINTR to the caller
>>>>> (for instance on sem_wait).
>>>>>
>>>>> Using SA_RESTART hides this, since the cancellation handler should
>>>>> either act uppon cancellation (if asynchronous cancellation is enable)
>>>>> or ignore the cancellation internal signal.
>>>>
>>>> I think this still needs a NEWS entry because there have been kernel
>>>> bugs in this area (e.g. in CIFS).
>>>
>>> Ok, I have added the following on "Deprecated and removed features, and 
>>> other changes affecting compatibility"
>>>
>>> * The pthread cancellation handler is now setup with SA_RESTART.  It should
>>>   not be visible to application since the cancellation handler should either 
>>>   act uppon cancellation (if asynchronous cancellation is enabled) or
>>>   ignore the cancellation internal signal.
>> 
>> The key change is: The cancellation signal is now sent in more cases,
>> but this should be transparent to the application due to SA_RESTART.
>
> I am not sure if we really need to describe this implementation detail
> on a NEWS entry.

It's the cause of additional EINTR errors.  People who have that buggy
CIFS module and use thread cancellation could see those spurious EINTR
errors.  Right, without mentioning EINTR it is probably not useful. 8-/

Thanks,
Florian
Adhemerval Zanella Netto June 22, 2021, 7:50 p.m. UTC | #8 
On 22/06/2021 15:52, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 22/06/2021 15:33, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> On 18/06/2021 08:38, Florian Weimer wrote:
>>>>> * Adhemerval Zanella via Libc-alpha:
>>>>>
>>>>>> The usage of signals to implementation pthread cancellation is an
>>>>>> implementation detail and should not be visible through cancellation
>>>>>> entrypoints.
>>>>>>
>>>>>> However now that pthread_cancel always send the SIGCANCEL, some
>>>>>> entrypoint might be interruptable and return EINTR to the caller
>>>>>> (for instance on sem_wait).
>>>>>>
>>>>>> Using SA_RESTART hides this, since the cancellation handler should
>>>>>> either act uppon cancellation (if asynchronous cancellation is enable)
>>>>>> or ignore the cancellation internal signal.
>>>>>
>>>>> I think this still needs a NEWS entry because there have been kernel
>>>>> bugs in this area (e.g. in CIFS).
>>>>
>>>> Ok, I have added the following on "Deprecated and removed features, and 
>>>> other changes affecting compatibility"
>>>>
>>>> * The pthread cancellation handler is now setup with SA_RESTART.  It should
>>>>   not be visible to application since the cancellation handler should either 
>>>>   act uppon cancellation (if asynchronous cancellation is enabled) or
>>>>   ignore the cancellation internal signal.
>>>
>>> The key change is: The cancellation signal is now sent in more cases,
>>> but this should be transparent to the application due to SA_RESTART.
>>
>> I am not sure if we really need to describe this implementation detail
>> on a NEWS entry.
> 
> It's the cause of additional EINTR errors.  People who have that buggy
> CIFS module and use thread cancellation could see those spurious EINTR
> errors.  Right, without mentioning EINTR it is probably not useful. 8-/

What about:

* The pthread cancellation handler is now installed with SA_RESTART
  and pthread_cancel will always send the internal SIGCANCEL on a
  cancellation request.  It should not be visible to application since 
  the cancellation handler should either act upon cancellation (if 
  asynchronous cancellation is enabled) or ignore the cancellation 
  internal signal.  However there is buggy kernel interfaces (for
  instance some CIFS modules) that could still see spurious EINTR
  error when cancellation interrupts a blocking syscall.
Florian Weimer June 22, 2021, 7:51 p.m. UTC | #9 
* Adhemerval Zanella:

> * The pthread cancellation handler is now installed with SA_RESTART
>   and pthread_cancel will always send the internal SIGCANCEL on a
>   cancellation request.  It should not be visible to application since 
>   the cancellation handler should either act upon cancellation (if 
>   asynchronous cancellation is enabled) or ignore the cancellation 
>   internal signal.  However there is buggy kernel interfaces (for
>   instance some CIFS modules) that could still see spurious EINTR
>   error when cancellation interrupts a blocking syscall.

Suggest: “some CIFS [versions]”

Rest looks okay to me, thanks.

Florian
Adhemerval Zanella Netto June 22, 2021, 7:58 p.m. UTC | #10 
On 22/06/2021 16:51, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> * The pthread cancellation handler is now installed with SA_RESTART
>>   and pthread_cancel will always send the internal SIGCANCEL on a
>>   cancellation request.  It should not be visible to application since 
>>   the cancellation handler should either act upon cancellation (if 
>>   asynchronous cancellation is enabled) or ignore the cancellation 
>>   internal signal.  However there is buggy kernel interfaces (for

It should be 'there are' here.

>>   instance some CIFS modules) that could still see spurious EINTR
>>   error when cancellation interrupts a blocking syscall.
> 
> Suggest: “some CIFS [versions]”
> 
> Rest looks okay to me, thanks.

Ack, I will change and push upstream.
diff mbox series

Patch

diff --git a/nptl/pthread_cancel.c b/nptl/pthread_cancel.c
index 0698cd2046..cc25ff21f3 100644
--- a/nptl/pthread_cancel.c
+++ b/nptl/pthread_cancel.c
@@ -72,7 +72,11 @@  __pthread_cancel (pthread_t th)
     {
       struct sigaction sa;
       sa.sa_sigaction = sigcancel_handler;
-      sa.sa_flags = SA_SIGINFO;
+      /* The signal handle should be non-interruptible to avoid the risk of
+	 spurious EINTR caused by SIGCANCEL sent to process or if
+	 pthread_cancel() is called while cancellation is disabled in the
+	 target thread.  */
+      sa.sa_flags = SA_SIGINFO | SA_RESTART;
       __sigemptyset (&sa.sa_mask);
       __libc_sigaction (SIGCANCEL, &sa, NULL);
       atomic_store_relaxed (&init_sigcancel, 1);