Re: [PATCH] abort.3: Note that the glibc implementation is not async-signal-safe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tomáš, Gabriel,

On 2023-08-25 14:32, Tomáš Golembiovský wrote:
> On Thu, Aug 24, 2023 at 11:07:00PM +0100, Gabriel Ravier wrote:
>> On 8/22/23 17:26, Tomáš Golembiovský via Libc-alpha wrote:
>>> Hi,
>>>
>>> gentle reminder that this has not received any attention yet.
>> I assume this is because there are currently efforts to make glibc's
>> implementation async-signal-safe - which would make this proposed note quite
>> quickly inaccurate

I was actually waiting to see if anyone from glibc would comment.
As Tomáš said, I think this should be added even if glibc makes it
safe in the (near) future.  When that happens, we should move that
to the HISTORY section.

> 
> I suppose you're referring to this: 
> 
> https://inbox.sourceware.org/libc-alpha/20230803173436.4146900-1-adhemerval.zanella@xxxxxxxxxx/
> 
> I was not aware of that. Thanks for bringing that to my attention.
> 
>> (though the fact it has been async-signal-unsafe until
>> now still seems notable enough to be mentioned here).
> 
> Yes, even when this is fixed having a BUGS section with something like
> "In glibc X.Y.Z and earlier the function was not AS-safe.", might be a
> good idea.
> 
>     Tomas

Agree.  As no-one from glibc commented, I'll take that as an implicit ack.

> 
>>>
>>> Thanks,
>>>
>>>      Tomas
>>>
>>> On Wed, Jul 26, 2023 at 01:55:27PM +0200, Tomáš Golembiovský wrote:
>>>> See https://sourceware.org/bugzilla/show_bug.cgi?id=26275
>>>>
>>>> Cc: Carlos O'Donell <carlos@xxxxxxxxxx>
>>>> Cc: Glibc <libc-alpha@xxxxxxxxxxxxxx>
>>>> Signed-off-by: Tomáš Golembiovský <tgolembi@xxxxxxxxxx>
>>>> ---
>>>>   man3/abort.3         | 6 ++++++
>>>>   man7/signal-safety.7 | 5 +++++
>>>>   2 files changed, 11 insertions(+)
>>>>
>>>> diff --git a/man3/abort.3 b/man3/abort.3
>>>> index 0b57e10ed..827d5c9db 100644
>>>> --- a/man3/abort.3
>>>> +++ b/man3/abort.3
>>>> @@ -85,6 +85,12 @@ terminates the process without flushing streams.
>>>>   POSIX.1 permits either possible behavior, saying that
>>>>   .BR abort ()
>>>>   "may include an attempt to effect fclose() on all open streams".
>>>> +.SH BUGS
>>>> +The glibc implementation of
>>>> +.BR abort ()
>>>> +is not async-signal-safe,
>>>> +.\" FIXME . https://sourceware.org/bugzilla/show_bug.cgi?id=26275

What's that '.' for?

>>>> +in violation of the requirements of POSIX.1.

It seems to also be in violation of ISO C, per what the glibc bug claims.

Please also include the links to POSIX.1 and ISO C that confirm this.

Cheers,
Alex

>>>>   .SH SEE ALSO
>>>>   .BR gdb (1),
>>>>   .BR sigaction (2),
>>>> diff --git a/man7/signal-safety.7 b/man7/signal-safety.7
>>>> index 3d6ddc7eb..431a22f89 100644
>>>> --- a/man7/signal-safety.7
>>>> +++ b/man7/signal-safety.7
>>>> @@ -335,6 +335,11 @@ The glibc implementation of
>>>>   is not async-signal-safe because it uses
>>>>   .BR pthread_mutex_lock (3)
>>>>   internally.
>>>> +.IP \[bu]
>>>> +.\" FIXME . https://sourceware.org/bugzilla/show_bug.cgi?id=26275
>>>> +The glibc implementation of
>>>> +.BR abort (3)
>>>> +is not async-signal-safe.
>>>>   .SH SEE ALSO
>>>>   .BR sigaction (2),
>>>>   .BR signal (7),
>>>> -- 
>>>> 2.41.0
>>>>
>>
> 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux