linux-kernel - Re: [PATCH 1/1] io_uring/sqpoll: inherit cpumask of creating process

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: <236f0c6d019e8c25301f3db0a5c9d4971a094eb9.camel@siemens.com>
Date: Fri, 6 Sep 2024 13:52:32 +0000
From: "MOESSBAUER, Felix" <felix.moessbauer@...mens.com>
To: "axboe@...nel.dk" <axboe@...nel.dk>, "asml.silence@...il.com"
	<asml.silence@...il.com>
CC: "io-uring@...r.kernel.org" <io-uring@...r.kernel.org>,
	"cgroups@...r.kernel.org" <cgroups@...r.kernel.org>, "Bezdeka, Florian"
	<florian.bezdeka@...mens.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "longman@...hat.com" <longman@...hat.com>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>, "Schmidt, Adriaan"
	<adriaan.schmidt@...mens.com>, "dqminh@...udflare.com"
	<dqminh@...udflare.com>
Subject: Re: [PATCH 1/1] io_uring/sqpoll: inherit cpumask of creating process

On Fri, 2024-09-06 at 07:47 -0600, Jens Axboe wrote:
> On 9/6/24 7:44 AM, Felix Moessbauer wrote:
> > The submit queue polling threads are "kernel" threads that are
> > started
> 
> It's not a kernel thread, it's a normal userland thread that just
> never
> exits to userspace.

One more reason to behave like a userland thread. I used the term
"kernel" thread as it was used in commit a5fc1441af as well, referring
to the same thing.

Shall I update the commit message?

Best regards,
Felix

> 
> > from the userland. In case the userland task is part of a cgroup
> > with
> > the cpuset controller enabled, the poller should also stay within
> > that
> > cpuset. This also holds, as the poller belongs to the same cgroup
> > as
> > the task that started it.
> > 
> > With the current implementation, a process can "break out" of the
> > defined cpuset by creating sq pollers consuming CPU time on other
> > CPUs,
> > which is especially problematic for realtime applications.
> > 
> > Part of this problem was fixed in a5fc1441 by dropping the
> > PF_NO_SETAFFINITY flag, but this only becomes effective after the
> > first
> > modification of the cpuset (i.e. the pollers cpuset is correct
> > after the
> > first update of the enclosing cgroups cpuset).
> > 
> > By inheriting the cpuset of the creating tasks, we ensure that the
> > poller is created with a cpumask that is a subset of the cgroups
> > mask.
> > Inheriting the creators cpumask is reasonable, as other userland
> > tasks
> > also inherit the mask.
> 
> Looks fine to me.
> 

-- 
Siemens AG, Technology
Linux Expert Center