Linux-man Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] system.3: Indicate MT-Unsafe
@ 2020-10-06 16:15 Nate Karstens
  2020-10-06 17:26 ` Adhemerval Zanella
  0 siblings, 1 reply; 4+ messages in thread
From: Nate Karstens @ 2020-10-06 16:15 UTC (permalink / raw)
  To: mtk.manpages; +Cc: linux-man, libc-alpha, willy, Nate Karstens

The fact that system(3) does not support pthread_atfork(3) also means
that it is not thread safe. See the discussion for the proposal of a
close-on-fork flag in the 2020 April and May timeframe, especially:

https://lkml.org/lkml/2020/5/15/1067

Signed-off-by: Nate Karstens <nate.karstens@garmin.com>
---
 man3/system.3 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man3/system.3 b/man3/system.3
index aef40417a..8730fabd3 100644
--- a/man3/system.3
+++ b/man3/system.3
@@ -127,7 +127,7 @@ l l l.
 Interface	Attribute	Value
 T{
 .BR system ()
-T}	Thread safety	MT-Safe
+T}	Thread safety	MT-Unsafe
 .TE
 .SH CONFORMING TO
 POSIX.1-2001, POSIX.1-2008, C89, C99.
-- 
2.17.1


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] system.3: Indicate MT-Unsafe
  2020-10-06 16:15 [PATCH] system.3: Indicate MT-Unsafe Nate Karstens
@ 2020-10-06 17:26 ` Adhemerval Zanella
  2020-10-07 14:35   ` Karstens, Nate
  0 siblings, 1 reply; 4+ messages in thread
From: Adhemerval Zanella @ 2020-10-06 17:26 UTC (permalink / raw)
  To: Nate Karstens, mtk.manpages; +Cc: linux-man, libc-alpha, willy



On 06/10/2020 13:15, Nate Karstens via Libc-alpha wrote:
> The fact that system(3) does not support pthread_atfork(3) also means
> that it is not thread safe. See the discussion for the proposal of a
> close-on-fork flag in the 2020 April and May timeframe, especially:
> 
> https://lkml.org/lkml/2020/5/15/1067
> 
> Signed-off-by: Nate Karstens <nate.karstens@garmin.com>

Not sure if man pages characterizes file descriptor leak as mt-unsafe, at
least we don't have this concept on glibc manual.  In fact, I think adding
a MT-Unsafe mark to this potentially make any libc call that is not atomic
potentially MT-Unsafe, either when they do not concurrent trigger race
issues regarding memory semantic. At least I think it should add a 'race'
mark to indicate what exactly is MT-unsafe (as for other implementations).

> ---
>  man3/system.3 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/man3/system.3 b/man3/system.3
> index aef40417a..8730fabd3 100644
> --- a/man3/system.3
> +++ b/man3/system.3
> @@ -127,7 +127,7 @@ l l l.
>  Interface	Attribute	Value
>  T{
>  .BR system ()
> -T}	Thread safety	MT-Safe
> +T}	Thread safety	MT-Unsafe
>  .TE
>  .SH CONFORMING TO
>  POSIX.1-2001, POSIX.1-2008, C89, C99.
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [PATCH] system.3: Indicate MT-Unsafe
  2020-10-06 17:26 ` Adhemerval Zanella
@ 2020-10-07 14:35   ` Karstens, Nate
  2020-10-07 18:06     ` Adhemerval Zanella
  0 siblings, 1 reply; 4+ messages in thread
From: Karstens, Nate @ 2020-10-07 14:35 UTC (permalink / raw)
  To: Adhemerval Zanella, mtk.manpages; +Cc: linux-man, libc-alpha, willy

I'm fine with adding a "race" qualifier. Do you have any ideas on the type of race? I didn't see anything in the other man-pages that jumped out as being correct.

Thanks,

Nate

-----Original Message-----
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Sent: Tuesday, October 06, 2020 12:26
To: Karstens, Nate <Nate.Karstens@garmin.com>; mtk.manpages@gmail.com
Cc: linux-man@vger.kernel.org; libc-alpha@sourceware.org; willy@infradead.org
Subject: Re: [PATCH] system.3: Indicate MT-Unsafe

CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.


On 06/10/2020 13:15, Nate Karstens via Libc-alpha wrote:
> The fact that system(3) does not support pthread_atfork(3) also means
> that it is not thread safe. See the discussion for the proposal of a
> close-on-fork flag in the 2020 April and May timeframe, especially:
>
> https://urldefense.com/v3/__https://lkml.org/lkml/2020/5/15/1067__;!!E
> Jc4YC3iFmQ!D9YVAE760hT-YFoOT14KmIu4y2cjQb8ZflVgpX-3rxgBF2WvxyATUeQogZF
> Ffv2sIQ$
>
> Signed-off-by: Nate Karstens <nate.karstens@garmin.com>

Not sure if man pages characterizes file descriptor leak as mt-unsafe, at least we don't have this concept on glibc manual.  In fact, I think adding a MT-Unsafe mark to this potentially make any libc call that is not atomic potentially MT-Unsafe, either when they do not concurrent trigger race issues regarding memory semantic. At least I think it should add a 'race'
mark to indicate what exactly is MT-unsafe (as for other implementations).

> ---
>  man3/system.3 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/man3/system.3 b/man3/system.3 index aef40417a..8730fabd3
> 100644
> --- a/man3/system.3
> +++ b/man3/system.3
> @@ -127,7 +127,7 @@ l l l.
>  Interface    Attribute       Value
>  T{
>  .BR system ()
> -T}   Thread safety   MT-Safe
> +T}   Thread safety   MT-Unsafe
>  .TE
>  .SH CONFORMING TO
>  POSIX.1-2001, POSIX.1-2008, C89, C99.
>

________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] system.3: Indicate MT-Unsafe
  2020-10-07 14:35   ` Karstens, Nate
@ 2020-10-07 18:06     ` Adhemerval Zanella
  0 siblings, 0 replies; 4+ messages in thread
From: Adhemerval Zanella @ 2020-10-07 18:06 UTC (permalink / raw)
  To: Karstens, Nate, mtk.manpages; +Cc: linux-man, libc-alpha, willy

But calling system does not really incur in a race w.r.t the resources
of the caller itself and least glibc does handle concurrent sigactions 
calls and thread cancellation (by reaping the created process). I am
not sure about other libc implementation though.

The file leakage will be only for the spawn program itself and although 
it is might characterize as unsafe to call 'system' in multithread 
environment I don't think this characterize as MT-unsafe (and with 
FD_CLOEXEC/O_CLOEXEC system is indeed safe in this regarding).

So maybe document using a different markup to make it explicit?

On 07/10/2020 11:35, Karstens, Nate wrote:
> I'm fine with adding a "race" qualifier. Do you have any ideas on the type of race? I didn't see anything in the other man-pages that jumped out as being correct.
> 
> Thanks,
> 
> Nate
> 
> -----Original Message-----
> From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
> Sent: Tuesday, October 06, 2020 12:26
> To: Karstens, Nate <Nate.Karstens@garmin.com>; mtk.manpages@gmail.com
> Cc: linux-man@vger.kernel.org; libc-alpha@sourceware.org; willy@infradead.org
> Subject: Re: [PATCH] system.3: Indicate MT-Unsafe
> 
> CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
> 
> 
> On 06/10/2020 13:15, Nate Karstens via Libc-alpha wrote:
>> The fact that system(3) does not support pthread_atfork(3) also means
>> that it is not thread safe. See the discussion for the proposal of a
>> close-on-fork flag in the 2020 April and May timeframe, especially:
>>
>> https://urldefense.com/v3/__https://lkml.org/lkml/2020/5/15/1067__;!!E
>> Jc4YC3iFmQ!D9YVAE760hT-YFoOT14KmIu4y2cjQb8ZflVgpX-3rxgBF2WvxyATUeQogZF
>> Ffv2sIQ$
>>
>> Signed-off-by: Nate Karstens <nate.karstens@garmin.com>
> 
> Not sure if man pages characterizes file descriptor leak as mt-unsafe, at least we don't have this concept on glibc manual.  In fact, I think adding a MT-Unsafe mark to this potentially make any libc call that is not atomic potentially MT-Unsafe, either when they do not concurrent trigger race issues regarding memory semantic. At least I think it should add a 'race'
> mark to indicate what exactly is MT-unsafe (as for other implementations).
> 
>> ---
>>  man3/system.3 | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/man3/system.3 b/man3/system.3 index aef40417a..8730fabd3
>> 100644
>> --- a/man3/system.3
>> +++ b/man3/system.3
>> @@ -127,7 +127,7 @@ l l l.
>>  Interface    Attribute       Value
>>  T{
>>  .BR system ()
>> -T}   Thread safety   MT-Safe
>> +T}   Thread safety   MT-Unsafe
>>  .TE
>>  .SH CONFORMING TO
>>  POSIX.1-2001, POSIX.1-2008, C89, C99.
>>
> 
> ________________________________
> 
> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-06 16:15 [PATCH] system.3: Indicate MT-Unsafe Nate Karstens
2020-10-06 17:26 ` Adhemerval Zanella
2020-10-07 14:35   ` Karstens, Nate
2020-10-07 18:06     ` Adhemerval Zanella

Linux-man Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-man/0 linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ https://lore.kernel.org/linux-man \
		linux-man@vger.kernel.org
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-man


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git