linux-kernel - Re: [PATCH 01/53] workqueue: Introduce the create*

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: <ZoXRrD48cLEGmUT2@slm.duckdns.org>
Date: Wed, 3 Jul 2024 12:33:16 -1000
From: Tejun Heo <tj@...nel.org>
To: Kees Cook <kees@...nel.org>
Cc: Bart Van Assche <bvanassche@....org>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	"Martin K . Petersen" <martin.petersen@...cle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/53] workqueue: Introduce the create*_workqueue2()
 macros

Hello,

On Wed, Jul 03, 2024 at 03:20:17PM -0700, Kees Cook wrote:
> > Hence a different approach for the SCSI create*_workqueue() macros:
> > https://lore.kernel.org/linux-scsi/20240702215228.2743420-1-bvanassche@acm.org/
> 
> Gotcha. Okay, well, that's a lot of flags to open-code, but I guess
> that's fine? :P

The flag in question is WQ_MEM_RECLAIM and that flag has a direct cost of
creating a dedicated kthread which mostly sits idle, so we want it to be
explicit. In SCSI, the naive expansion is likely to be correct for most
cases.

It's a bit tricky in that the failure mode of incorrectly missing the flag
is critical (system deadlock under memory pressure) but can be difficult to
trigger and the depencency chain may not be immediately evident when looking
at the code. The upsides are that when it happens, it's usually not too
difficult to tell from the backtraces and lockdep annotation sometimes helps
with finding missing cases (which is suppressed when using the old interface
because it's unclear whether MEM_RECLAIM is there intentionally or not).

Anyways, yeah, we want it to be explicit.

Thanks.

-- 
tejun