From: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>,
Eric Biggers <ebiggers@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
David Sterba <dsterba@suse.com>, Theodore Ts'o <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>,
Andrey Albershteyn <aalbersh@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, fsverity@lists.linux.dev
Subject: Re: [PATCH 4/6] fsverity: use a hashtable to find the fsverity_info
Date: Mon, 19 Jan 2026 10:27:48 +0100 [thread overview]
Message-ID: <20260119092748.GA10125@lst.de> (raw)
In-Reply-To: <z4652hoxetll645hgpfuhy3pogm5y32ealgydlaz4kwve6qc2g@bl6ilzut2ybp>
On Mon, Jan 19, 2026 at 10:21:00AM +0100, Jan Kara wrote:
> OK, but since __fsverity_get_info() is just rhashtable_lookup_fast() what
> prevents the CPU from reordering the hash table reads before the S_VERITY
> check? I think you need a barrier in fsverity_get_info() to enforce the
> proper ordering. The matching ordering during setting of S_VERITY is
> implied by cmpxchg used to manipulate i_flags so that part should be fine.
Yes, probably.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: fsverity@lists.linux.dev, Christian Brauner <brauner@kernel.org>,
Theodore Ts'o <tytso@mit.edu>,
Andrey Albershteyn <aalbersh@redhat.com>,
linux-f2fs-devel@lists.sourceforge.net,
Eric Biggers <ebiggers@kernel.org>,
linux-fsdevel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
David Sterba <dsterba@suse.com>, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
linux-btrfs@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH 4/6] fsverity: use a hashtable to find the fsverity_info
Date: Mon, 19 Jan 2026 10:27:48 +0100 [thread overview]
Message-ID: <20260119092748.GA10125@lst.de> (raw)
In-Reply-To: <z4652hoxetll645hgpfuhy3pogm5y32ealgydlaz4kwve6qc2g@bl6ilzut2ybp>
On Mon, Jan 19, 2026 at 10:21:00AM +0100, Jan Kara wrote:
> OK, but since __fsverity_get_info() is just rhashtable_lookup_fast() what
> prevents the CPU from reordering the hash table reads before the S_VERITY
> check? I think you need a barrier in fsverity_get_info() to enforce the
> proper ordering. The matching ordering during setting of S_VERITY is
> implied by cmpxchg used to manipulate i_flags so that part should be fine.
Yes, probably.
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2026-01-19 9:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-19 6:22 fsverity optimzations and speedups Christoph Hellwig
2026-01-19 6:22 ` [f2fs-dev] " Christoph Hellwig
2026-01-19 6:22 ` [PATCH 1/6] fs,fsverity: reject size changes on fsverity files in setattr_prepare Christoph Hellwig
2026-01-19 6:22 ` [f2fs-dev] [PATCH 1/6] fs, fsverity: " Christoph Hellwig
2026-01-19 6:22 ` [PATCH 2/6] fs,fsverity: clear out fsverity_info from common code Christoph Hellwig
2026-01-19 6:22 ` [f2fs-dev] [PATCH 2/6] fs, fsverity: " Christoph Hellwig
2026-01-19 6:22 ` [PATCH 3/6] fs,fsverity: handle fsverity in generic_file_open Christoph Hellwig
2026-01-19 6:22 ` [f2fs-dev] [PATCH 3/6] fs, fsverity: " Christoph Hellwig
2026-01-19 9:05 ` [PATCH 3/6] fs,fsverity: " Jan Kara
2026-01-19 9:05 ` [f2fs-dev] [PATCH 3/6] fs, fsverity: " Jan Kara
2026-01-19 9:26 ` [PATCH 3/6] fs,fsverity: " Christoph Hellwig
2026-01-19 9:26 ` [f2fs-dev] [PATCH 3/6] fs, fsverity: " Christoph Hellwig
2026-01-19 10:02 ` [PATCH 3/6] fs,fsverity: " Christian Brauner
2026-01-19 10:02 ` [f2fs-dev] [PATCH 3/6] fs, fsverity: " Christian Brauner via Linux-f2fs-devel
2026-01-19 12:06 ` [PATCH 3/6] fs,fsverity: " Christoph Hellwig
2026-01-19 12:06 ` [f2fs-dev] [PATCH 3/6] fs, fsverity: " Christoph Hellwig
2026-01-19 6:22 ` [PATCH 4/6] fsverity: use a hashtable to find the fsverity_info Christoph Hellwig
2026-01-19 6:22 ` [f2fs-dev] " Christoph Hellwig
2026-01-19 9:21 ` Jan Kara
2026-01-19 9:21 ` [f2fs-dev] " Jan Kara
2026-01-19 9:27 ` Christoph Hellwig [this message]
2026-01-19 9:27 ` Christoph Hellwig
2026-01-19 19:05 ` Eric Biggers
2026-01-19 19:05 ` [f2fs-dev] " Eric Biggers via Linux-f2fs-devel
2026-01-20 7:35 ` Christoph Hellwig
2026-01-20 7:35 ` [f2fs-dev] " Christoph Hellwig
2026-01-19 6:22 ` [PATCH 5/6] fsverity: pass struct file to ->write_merkle_tree_block Christoph Hellwig
2026-01-19 6:22 ` [f2fs-dev] " Christoph Hellwig
2026-01-19 6:22 ` [PATCH 6/6] fsverity: kick off hash readahead at data I/O submission time Christoph Hellwig
2026-01-19 6:22 ` [f2fs-dev] " Christoph Hellwig
2026-01-19 9:37 ` fsverity optimzations and speedups Christian Brauner
2026-01-19 9:37 ` [f2fs-dev] " Christian Brauner via Linux-f2fs-devel
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=20260119092748.GA10125@lst.de \
--to=hch@lst.de \
--cc=aalbersh@redhat.com \
--cc=brauner@kernel.org \
--cc=chao@kernel.org \
--cc=dsterba@suse.com \
--cc=ebiggers@kernel.org \
--cc=fsverity@lists.linux.dev \
--cc=jack@suse.cz \
--cc=jaegeuk@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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.