public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, Christian Brauner <brauner@kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fs: don't block write during exec on pre-content watched files
Date: Mon, 9 Dec 2024 08:56:30 -0500	[thread overview]
Message-ID: <20241209135630.GA2840216@perftesting> (raw)
In-Reply-To: <CAOQ4uxjyFOy0JCPJ2y4Sm-goRK9xtf_6jkWEEq_vzxPO-FmnCA@mail.gmail.com>

On Thu, Dec 05, 2024 at 02:28:25PM +0100, Amir Goldstein wrote:
> On Thu, Dec 5, 2024 at 1:55 PM Jan Kara <jack@suse.cz> wrote:
> >
> > On Thu 28-11-24 15:25:32, Amir Goldstein wrote:
> > > Commit 2a010c412853 ("fs: don't block i_writecount during exec") removed
> > > the legacy behavior of getting ETXTBSY on attempt to open and executable
> > > file for write while it is being executed.
> > >
> > > This commit was reverted because an application that depends on this
> > > legacy behavior was broken by the change.
> > >
> > > We need to allow HSM writing into executable files while executed to
> > > fill their content on-the-fly.
> > >
> > > To that end, disable the ETXTBSY legacy behavior for files that are
> > > watched by pre-content events.
> > >
> > > This change is not expected to cause regressions with existing systems
> > > which do not have any pre-content event listeners.
> > >
> > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> >
> > OK, I've picked up the patch to fsnotify_hsm branch with Christian's ack
> > and updated comments from Amir. Still waiting for Josef to give this a
> > final testing from their side but I've pulled the branch into for_next so
> > that it gets some exposure in linux-next as well.
> 
> Cool. I just pushed a test to my LTP fan_hsm branch for ETXTBSY.
> 
> It checks for the expected ETXTBSY with yes or no pre-content watchers,
> but it checks failure to execute a file open for write, not actually to open
> a file for write in the context of PRE_ACCESS event during execution.
> 
> So yeh, a test of the actual use case of large lazy populated
> executables from Josef
> is required, but at least we have basic sanity test coverage and now we will get
> some extra linux-next testing coverage which is great.

Sorry guys, holidays and then some PTO and other things conspired against me
being useful.  I just built and tested Jan's branch as of 10 minutes ago and
everything works.  Thanks for picking up my slack, I'll be actually responsive
for the next two weeks and then I'll disappear again until Jan 6th,

Josef

      reply	other threads:[~2024-12-09 13:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-28 14:25 [PATCH] fs: don't block write during exec on pre-content watched files Amir Goldstein
2024-11-28 14:34 ` Mateusz Guzik
2024-11-28 16:57   ` Amir Goldstein
2024-11-28 17:00     ` Mateusz Guzik
2024-11-29 10:57       ` Amir Goldstein
2024-11-29 15:52         ` Mateusz Guzik
2024-12-03 17:24 ` Jan Kara
2024-12-04 10:56   ` Christian Brauner
2024-12-04 11:06     ` Mateusz Guzik
2024-12-04 11:19       ` Christian Brauner
2024-12-05 12:55 ` Jan Kara
2024-12-05 13:28   ` Amir Goldstein
2024-12-09 13:56     ` Josef Bacik [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241209135630.GA2840216@perftesting \
    --to=josef@toxicpanda.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox