Hi!
>
> If the feedback from the community is truly and finally that system() should
> not be used in these applications, then is there support for updating the man
> page to better communicate that?
>
Clarifying documenation might be the best way forward. Note you'd have
to do that anyway, s
On Fri, May 15, 2020 at 08:57:30AM -0700, Matthew Wilcox wrote:
> On Fri, May 15, 2020 at 10:23:17AM -0500, Nate Karstens wrote:
> > Series of 4 patches to implement close-on-fork. Tests have been
> > published to https://github.com/nkarstens/ltp/tree/close-on-fork
> > and cover close-on-fork funct
On Fri, May 15, 2020 at 06:28:20PM +, Karstens, Nate wrote:
> Our first attempt, which was to use the pthread_atfork() handlers, failed
> because system() is not required to call the handlers.
>
> Most of the feedback we're getting on this seems to say "don't use system(),
> it is unsafe for
...@vger.kernel.org;
linux-al...@vger.kernel.org; linux-par...@vger.kernel.org;
sparcli...@vger.kernel.org; netdev@vger.kernel.org;
linux-ker...@vger.kernel.org; Changli Gao ;
a.jo...@opengroup.org
Subject: Re: [PATCH v2] Implement close-on-fork
CAUTION - EXTERNAL EMAIL: Do not click any links or open any att
Karstens, Nate wrote:
> > already has a portable solution
>
> What is the solution?
sys_spawn(const char *path, const char **argv, const char **envv,
unsigned long clone_flags, unsigned int nfds, int *fds);
maybe?
David
; Jakub Kicinski
; Eric Dumazet ; David Laight
; linux-fsde...@vger.kernel.org;
linux-a...@vger.kernel.org; linux-al...@vger.kernel.org;
linux-par...@vger.kernel.org; sparcli...@vger.kernel.org;
netdev@vger.kernel.org; linux-ker...@vger.kernel.org; Changli Gao
Subject: Re: [PATCH v2] Implemen
On Fri, May 15, 2020 at 04:07:33PM +, Karstens, Nate wrote:
> Matthew,
>
> What alternative would you suggest?
>
> >From an earlier email:
>
> > ...nothing else addresses the underlying issue: there is no way to
> > prevent a fork() from duplicating the resource. The close-on-exec
> > flag p
On Fri, 2020-05-15 at 16:07 +, Karstens, Nate wrote:
> Matthew,
>
> What alternative would you suggest?
>
> From an earlier email:
>
> > ...nothing else addresses the underlying issue: there is no way to
> > prevent a fork() from duplicating the resource. The close-on-exec
> > flag partially
.org
Subject: Re: [PATCH v2] Implement close-on-fork
CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless
you trust the sender and know the content is safe.
On Fri, May 15, 2020 at 10:23:17AM -0500, Nate Karstens wrote:
> Series of 4 patches to implement close-on-fork.
On Fri, May 15, 2020 at 10:23:17AM -0500, Nate Karstens wrote:
> This functionality was approved by the Austin Common Standards
> Revision Group for inclusion in the next revision of the POSIX
> standard (see issue 1318 in the Austin Group Defect Tracker).
It penalizes every call of fork() in the
From: Eric Dumazet
> Sent: 15 May 2020 16:31
...
> Fast path in big and performance sensitive applications is not fork()
> and/or exec().
>
> This is open()/close() and others (socket(), accept(), ...)
>
> We do not want them to access extra cache lines for this new feature.
>
> Sorry, I will sa
On Fri, May 15, 2020 at 10:23:17AM -0500, Nate Karstens wrote:
> Series of 4 patches to implement close-on-fork. Tests have been
> published to https://github.com/nkarstens/ltp/tree/close-on-fork
> and cover close-on-fork functionality in the following syscalls:
[...]
> This functionality was app
12 matches
Mail list logo
