Re: overlayfs: verity validation broken since f77f281b6118
Eric Biggers <[email protected]> Tue, 5 May 2026 10:18:27 -0700
| Newsgroups | dev.linux.lists.fsverity,org.kernel.vger.linux-fsdevel |
|---|---|
| Message-ID | <20260505171827.GB2291@sol> |
[+Cc Miklos Szeredi <[email protected]>] On Tue, May 05, 2026 at 12:51:47PM -0400, Colin Walters wrote: > On Sat, May 2, 2026, at 5:23 AM, Amir Goldstein wrote: > > On Fri, May 01, 2026 at 01:14:54PM -0400, Colin Walters wrote: > >> Hi Christoph & Eric, > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f77f281b6118 broke composefs's usage of overlayfs verity=require, this was reported originally in https://github.com/bootc-dev/bootc/issues/2174 > >> > >> There's some output from an agent run I had in the <details> there, but here's an xfstests patch that passes on without that commit and fails with it. > >> > >> From 14231122bfd1e41337e4fb847acbbe038457c32a Mon Sep 17 00:00:00 2001 > >> From: Colin Walters <[email protected]> > >> Date: Fri, 1 May 2026 09:45:58 -0400 > >> Subject: [PATCH] overlay/118: test fsverity lazy load through metacopy overlay > >> > >> Reproduces the regression reported at: > >> https://github.com/bootc-dev/bootc/issues/2174 > >> > >> A recent change in how fsverity state was cached in memory > >> I think caused inodes not in cache to appear to have > >> missing verity=require for overlayfs. > >> > >> This test catches that. > >> > >> Generated-by: OpenCode (Claude Sonnet 4.5) > >> Signed-off-by: Colin Walters <[email protected]> > >> --- > >> tests/overlay/118 | 62 +++++++++++++++++++++++++++++++++++++++++++ > >> tests/overlay/118.out | 1 + > > > > > > Please use free test numbers below 100 > > OK, I can resend with that change if that's the only thing. > > > > > > Is there a kernel fix for this? please mention it. > > Not that I know of. I did have my agent framework (opencode + combo of Gemini+Claude models) generate one initially, but I intentionally didn't post it because the generating is ~easy, verifying it's "good" is another thing and my C has bitrotted a bit (in favor of Rust mostly but I have to deal with a lot of Go too). > > Anyways, this trivial change works: Please do a fix patch first, and then any cleanup second as separate patch(es). You'll also need to submit your patches correctly, otherwise they cannot be accepted into the kernel: https://docs.kernel.org/process/submitting-patches.html Thanks, - Eric