linux-kernel - Re: [PATCH RFC 04/29] fsverity: add per-sb workqueue for post read processing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250812074350.GC18413@lst.de>
Date: Tue, 12 Aug 2025 09:43:50 +0200
From: Christoph Hellwig <hch@....de>
To: Tejun Heo <tj@...nel.org>
Cc: Christoph Hellwig <hch@....de>,
	Andrey Albershteyn <aalbersh@...hat.com>, fsverity@...ts.linux.dev,
	linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org,
	david@...morbit.com, djwong@...nel.org, ebiggers@...nel.org,
	Lai Jiangshan <jiangshanlai@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 04/29] fsverity: add per-sb workqueue for post read
 processing

> On Mon, Aug 11, 2025 at 01:45:19PM +0200, Christoph Hellwig wrote:
> > On Mon, Jul 28, 2025 at 10:30:08PM +0200, Andrey Albershteyn wrote:
> > > From: Andrey Albershteyn <aalbersh@...hat.com>
> > > 
> > > 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.
> > 
> > Do they?  I though the whole point of WQ_HIGHPRI was that they'd
> > have separate rescue workers to avoid any global pool effects.
> 
> HIGHPRI and MEM_RECLAIM are orthogonal. HIGHPRI makes the workqueue use
> worker pools with high priority, so all work items would execute at MIN_NICE
> (-20). Hmm... actually, rescuer doesn't set priority according to the
> workqueue's, which seems buggy.

Andrey (or others involved with previous versions):  is interference
with the log completion workqueue what you ran into?

Tejun, are you going to prepare a patch to fix the rescuer priority?