[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <i464joalmbxbu2yow2uvkbo3eioj3l4zihzzl2odegr4qqzr7u@4ycu45fecyz7>
Date: Mon, 1 Sep 2025 10:44:27 +0200
From: Jan Kara <jack@...e.cz>
To: David Laight <david.laight.linux@...il.com>
Cc: Alexander Monakov <amonakov@...ras.ru>, Theodore Ts'o <tytso@....edu>,
Al Viro <viro@...iv.linux.org.uk>, linux-fsdevel@...r.kernel.org,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: ETXTBSY window in __fput
On Sun 31-08-25 20:22:44, David Laight wrote:
> On Wed, 27 Aug 2025 16:05:51 +0300 (MSK)
> Alexander Monakov <amonakov@...ras.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?)
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@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists