public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [PATCH] nptl: Use SA_RESTART for SIGCANCEL handler
Date: Tue, 22 Jun 2021 20:52:21 +0200	[thread overview]
Message-ID: <877dilbul6.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <8c620913-8cbe-b0ee-d232-f8c7a58263dd@linaro.org> (Adhemerval Zanella's message of "Tue, 22 Jun 2021 15:50:41 -0300")

* 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


  reply	other threads:[~2021-06-22 18:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-17 12:52 Adhemerval Zanella
2021-06-17 13:03 ` Andreas Schwab
2021-06-17 13:04   ` Adhemerval Zanella
2021-06-18 11:38 ` Florian Weimer
2021-06-22 18:30   ` Adhemerval Zanella
2021-06-22 18:33     ` Florian Weimer
2021-06-22 18:50       ` Adhemerval Zanella
2021-06-22 18:52         ` Florian Weimer [this message]
2021-06-22 19:50           ` Adhemerval Zanella
2021-06-22 19:51             ` Florian Weimer
2021-06-22 19:58               ` Adhemerval Zanella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877dilbul6.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).