On Sun 31-08-25 20:22:44, David Laight wrote: > On Wed, 27 Aug 2025 16:05:51 +0300 (MSK) > Alexander Monakov <amonakov@xxxxxxxxx> 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?) fput() is offloaded to task work (i.e., it happens on exit of a task to userspace). But I don't think it impacts this particular problem in a significant way. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
