Re: ETXTBSY window in __fput

[David Laight <david.laight.linux@gmail.com>]

On Wed, 27 Aug 2025 16:05:51 +0300 (MSK)
Alexander Monakov <amonakov@ispras.ru> wrote:

> On Wed, 27 Aug 2025, Theodore Ts'o wrote:
> 
> > On Wed, Aug 27, 2025 at 10:22:14AM +0300, Alexander Monakov wrote:  
> > > 
> > > On Tue, 26 Aug 2025, Al Viro wrote:
> > >   
> > > > Egads...  Let me get it straight - you have a bunch of threads sharing descriptor
> > > > tables and some of them are forking (or cloning without shared descriptor tables)
> > > > while that is going on?  
> > > 
> > > I suppose if they could start a new process in a more straightforward manner,
> > > they would. But you cannot start a new process without fork. Anyway, I'm but
> > > a messenger here: the problem has been hit by various people in the Go community
> > > (and by Go team itself, at least twice). Here I'm asking about a potential
> > > shortcoming in __fput that exacerbates the problem.  
> > 
> > I'm assuming that the problem is showing up in real life when users
> > run a go problem using "go run" where the golang compiler freshly
> > writes the executable, and then fork/exec's the binary.  And using
> > multiple threads sharing descriptor tables was just to make a reliable
> > reproducer?  
> 
> You need at least two threads: while one thread does open-write-close-fork,
> there needs to be another thread that forks concurrently with the write.

Is this made worse by the code that defers fput to a worker thread?
(or am I misremembering things again?)

	David

> 
> Alexander
>