On Thu, Mar 07, 2024 at 01:58:57PM -0800, Darrick J. Wong wrote:
> On Mon, Mar 04, 2024 at 05:08:05PM -0800, Eric Biggers wrote:
> > On Mon, Mar 04, 2024 at 08:10:31PM +0100, Andrey Albershteyn wrote:
> > > For XFS, fsverity's global workqueue is not really suitable due to:
> > >
> > > 1. High priority workqueues are used within XFS to ensure that data
> > > IO completion cannot stall processing of journal IO completions.
> > > Hence using a WQ_HIGHPRI workqueue directly in the user data IO
> > > path is a potential filesystem livelock/deadlock vector.
> > >
> > > 2. The fsverity workqueue is global - it creates a cross-filesystem
> > > contention point.
> > >
> > > This patch adds per-filesystem, per-cpu workqueue for fsverity
> > > work. This allows iomap to add verification work in the read path on
> > > BIO completion.
> > >
> > > Signed-off-by: Andrey Albershteyn <aalbersh@xxxxxxxxxx>
> >
> > Should ext4 and f2fs switch over to this by converting
> > fsverity_enqueue_verify_work() to use it? I'd prefer not to have to maintain
> > two separate workqueue strategies as part of the fs/verity/ infrastructure.
>
> (Agreed.)
>
> > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > index 1fbc72c5f112..5863519ffd51 100644
> > > --- a/include/linux/fs.h
> > > +++ b/include/linux/fs.h
> > > @@ -1223,6 +1223,8 @@ struct super_block {
> > > #endif
> > > #ifdef CONFIG_FS_VERITY
> > > const struct fsverity_operations *s_vop;
> > > + /* Completion queue for post read verification */
> > > + struct workqueue_struct *s_read_done_wq;
> > > #endif
> >
> > Maybe s_verity_wq? Or do you anticipate this being used for other purposes too,
> > such as fscrypt? Note that it's behind CONFIG_FS_VERITY and is allocated by an
> > fsverity_* function, so at least at the moment it doesn't feel very generic.
>
> Doesn't fscrypt already create its own workqueues?
Yes, but iomap really needs it to be a generic sb workqueue like the
sb->s_dio_done_wq.
i.e. the completion processing in task context is not isolated to
fsverity - it will likely also be needed for fscrypt completion and
decompression on read completion, when they get supported by the
generic iomap IO infrastruture. i.e. Any read IO that needs a task
context for completion side data processing will need this.
The reality is that the major filesytsems are already using either
generic or internal per-fs workqueues for DIO completion and
buffered write completions. Some already use buried workqueues on
read IO completion, too, so moving this to being supported by the
generic IO infrastructure rather than reimplmenting it just a little
bit differently in every filesystem makes a lot of sense.
-Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
