linux-kernel - Re: [GIT PULL] fsverity fixes for v6.3-rc4

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]

Date:   Mon, 20 Mar 2023 15:31:13 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Eric Biggers <ebiggers@...nel.org>, Tejun Heo <tj@...nel.org>
Cc:     fsverity@...ts.linux.dev, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, "Theodore Ts'o" <tytso@....edu>,
        Nathan Huckleberry <nhuck@...gle.com>,
        Victor Hsieh <victorhsieh@...gle.com>
Subject: Re: [GIT PULL] fsverity fixes for v6.3-rc4

On Mon, Mar 20, 2023 at 2:07 PM Eric Biggers <ebiggers@...nel.org> wrote:
>
> Nathan Huckleberry (1):
>       fsverity: Remove WQ_UNBOUND from fsverity read workqueue

There's a *lot* of other WQ_UNBOUND users. If it performs that badly,
maybe there is something wrong with the workqueue code.

Should people be warned to not use WQ_UNBOUND - or is there something
very special about fsverity?

Added Tejun to the cc. With one of the main documented reasons for
WQ_UNBOUND being performance (both implicit "try to start execution of
work items as soon as possible") and explicit ("CPU intensive
workloads which can be better managed by the system scheduler"), maybe
it's time to reconsider?

WQ_UNBOUND adds a fair amount of complexity and special cases to the
workqueues, and this is now the second "let's remove it because it's
hurting things in a big way".

              Linus