linux-kernel - Re: cpusets and kthreads, inconsistent behaviour

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: <484EEF05.3060807@qualcomm.com>
Date:	Tue, 10 Jun 2008 14:15:49 -0700
From:	Max Krasnyansky <maxk@...lcomm.com>
To:	David Rientjes <rientjes@...gle.com>
CC:	Paul Jackson <pj@....com>, mingo@...e.hu,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, menage@...gle.com,
	linux-kernel@...r.kernel.org
Subject: Re: cpusets and kthreads, inconsistent behaviour

David Rientjes wrote:
> On Tue, 10 Jun 2008, Max Krasnyansky wrote:
> 
>> Hmm, technically you are correct of course. But we do not have any other
>> kernel tasks besides kthreads. All the kernel tasks I have on my machines have
>> kthreadd as their parent.
>> And I'm not aware of any kernel code that changes affinity mask of a
>> user-space task without paying attention to the cpuset the task belongs to. If
>> you know of any we should fix it because it'd clearly be a bug.
>>
> 
> This is why it shouldn't belong in the sched or kthread code; the 
> discrepency that you point out between p->cpus_allowed and 
> task_cs(p)->cpus_allowed is a cpuset created one.
I guess I do not see how the kernel task case is different from the
sched_setaffinity(). ie sched_setaffinity() is in the scheduler but it deals
with cpusets.

Also in this case the discrepancy is created _not_ by the cpuset, it's created
due to the lack of the appropriate API. In other words if we had something
kthread_setaffinty() from day one this would have been a non-issue :).

> So to avoid having tasks with a cpus_allowed mask that is not a subset of 
> its cpuset's set of allowable cpus, the solution would probably be to add 
> a flavor of cpuset_update_task_memory_state() for a cpus generation value.
Post policing would not work well in some scenarios due to lag time. ie By the
time cpusets realized that some kthread is running on the wrong cpus it maybe
too late.
We should just enforce cpuset constraint when kthreads change their affinity
mask, just like sched_setaffinity() already does.

Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/