Re: [f2fs-dev] [PATCH v10 03/22] ovl: use core fsverity ensure info interface

Andrey Albershteyn via Linux-f2fs-devel <[email protected]>
Newsgroups net.sourceforge.lists.linux-f2fs-devel,dev.linux.lists.fsverity,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-unionfs,org.kernel.vger.linux-xfs
Message-ID <[email protected]>
On 2026-06-19 09:54:48, Eric Biggers wrote:
> On Fri, Jun 19, 2026 at 09:28:31AM +0200, Amir Goldstein wrote:
> > On Wed, May 20, 2026 at 9:07 PM Eric Biggers <[email protected]> wrote:
> > >
> > > On Wed, May 20, 2026 at 02:37:01PM +0200, Andrey Albershteyn wrote:
> > > > fsverity now exposes fsverity_ensure_verity_info() which could be used
> > > > instead of opening file to ensure that fsverity info is loaded and
> > > > attached to inode.
> > > >
> > > > Signed-off-by: Andrey Albershteyn <[email protected]>
> > > > Acked-by: Amir Goldstein <[email protected]>
> > > > ---
> > > >  fs/overlayfs/util.c | 14 +++-----------
> > > >  1 file changed, 3 insertions(+), 11 deletions(-)
> > >
> > > Reviewed-by: Eric Biggers <[email protected]>
> > >
> > > I'm still confused by the new implementation of fsverity_active() that
> > > got introduced by "fsverity: use a hashtable to find the fsverity_info",
> > > though.  I should have caught this during review of that commit.  For
> > > one its comment is outdated, but also the memory barrier seems to be
> > > specific to the fsverity_get_info() caller and probably should be moved
> > > to there.  Anyway, that's not directly related to this patch.
> > 
> > Eric, Andrey,
> > 
> > Did you see the Sashiko review for this patch and others in this series?
> > 
> > https://sashiko.dev/#/patchset/20260520123722.405752-1-aalbersh%40kernel.org
> > 
> > It annotated some review comments as high and critical.
> > For this patch it is about interaction with fscrypt.
> > 
> > Please take a look and say if this is concerning or false positive.
> 
> Yes, this patch is broken and should be dropped.  I need to remember to
> look at the Sashiko reviews for other people's patches and not just
> trust that the submitter will.  Fortunately this one wasn't applied yet.
> 
> I pointed out the HIGHMEM performance bug in
> "fsverity: generate and store zero-block hash" earlier
> (https://lore.kernel.org/linux-fsdevel/20260401222717.GH2466@quark/).  I
> assume it was decided that no one will care about the combination of XFS
> && fsverity && HIGHMEM.  But the XFS folks should double-check that.
> 
> Andrey, could you check the Sashiko reviews for the other patches too?

Sure, I will go through them

-- 
- Andrey


_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.