On Thu, Mar 07, 2024 at 02:26:22PM -0800, Eric Biggers wrote: > On Thu, Mar 07, 2024 at 01:58:57PM -0800, Darrick J. Wong wrote: > > > 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? > > There's a global workqueue in fs/crypto/ too. IIRC, it has to be separate from > the fs/verity/ workqueue to avoid deadlocks when a file has both encryption and > verity enabled. This is because the verity step can involve reading and > decrypting Merkle tree blocks. > > The main thing I was wondering was whether there was some plan to use this new > per-sb workqueue as a generic post-read processing queue, as seemed to be > implied by the chosen naming. If there's no clear plan, it should instead just > be named after what it's actually used for, fsverity. My guess is that there's a lot less complexity if each subsystem (crypt, compression, verity, etc) gets its own workqueues instead of sharing so that there aren't starvation issues. It's too bad that's sort of wasteful, when what we really want is to submit a chain of dependent work_structs and have the workqueue(s) run that chain on the same cpu if possible. --D > - Eric >
