From: Tyler Hicks <code@tyhicks.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>,
NeilBrown <neil@brown.name>, Jeff Layton <jlayton@kernel.org>,
ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 0/2] Fix two regressions from start_creating()/start_removing() conversion
Date: Wed, 24 Dec 2025 08:47:39 -0600 [thread overview]
Message-ID: <aUv9C5Z4Y996T8BT@yaupon> (raw)
In-Reply-To: <CAOQ4uxg5Qbkt2WzfXojzCNUYwj9BsW6vzKEL4265PQxBgNkdeA@mail.gmail.com>
On 2025-12-24 07:31:59, Amir Goldstein wrote:
> On Tue, Dec 23, 2025 at 9:42 PM Tyler Hicks <code@tyhicks.com> wrote:
> >
> > When running the eCryptfs test suite on v6.19-rc2, I noticed BUG splats
> > from every test and that the umount utility was segfaulting when tearing
> > down after a test. Bisection led me to commit f046fbb4d81d ("ecryptfs:
> > use new start_creating/start_removing APIs").
> >
> > This patch series addresses that regression and also a mknod problem
> > spotted during code review.
> >
>
> Ouch!
>
> Christian,
>
> In retrospect, it's a shame that patches get merged with zero test coverage
> and no ACK from the maintainer.
I wasn't able to be a very active maintainer over the last year. I think
Christian did the right thing here.
> OTOH, relying on ACKs from all fs maintainers will seriously impair
> the ability to make vfs wide changes like this one.
Exactly. The fringe filesystems shouldn't slow down the entire VFS.
> Feels like we need to find a better balance.
>
> At least for ecryptfs, if we know that Tyler is at least testing rc1
> regularly (?) that's a comfort.
I will be more active going forward and now have an easy setup for
testing rc1's regularly.
Tyler
>
> Thanks,
> Amir.
next prev parent reply other threads:[~2025-12-24 14:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-23 19:41 [PATCH 0/2] Fix two regressions from start_creating()/start_removing() conversion Tyler Hicks
2025-12-23 19:41 ` [PATCH 1/2] ecryptfs: Fix improper mknod pairing of start_creating()/end_removing() Tyler Hicks
2025-12-24 6:23 ` Amir Goldstein
2025-12-23 19:41 ` [PATCH 2/2] ecryptfs: Release lower parent dentry after creating dir Tyler Hicks
2025-12-24 6:37 ` Amir Goldstein
2025-12-24 6:31 ` [PATCH 0/2] Fix two regressions from start_creating()/start_removing() conversion Amir Goldstein
2025-12-24 14:47 ` Tyler Hicks [this message]
2025-12-24 12:58 ` Christian Brauner
2025-12-27 1:05 ` NeilBrown
2025-12-27 18:15 ` Amir Goldstein
2025-12-30 3:30 ` Tyler Hicks
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=aUv9C5Z4Y996T8BT@yaupon \
--to=code@tyhicks.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=ecryptfs@vger.kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neil@brown.name \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.