linux-kernel - Re: [PATCH 05/10] sched/core: Remove the tsk_cpus

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: <20170209090808.GA6893@gmail.com>
Date:   Thu, 9 Feb 2017 10:08:08 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mike Galbraith <efault@....de>,
        Oleg Nesterov <oleg@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 05/10] sched/core: Remove the tsk_cpus_allowed() wrapper


* Peter Zijlstra <peterz@...radead.org> wrote:

> On Wed, Feb 08, 2017 at 07:34:18PM +0100, Ingo Molnar wrote:
>
> > So the original intention of tsk_cpus_allowed() was to 'future-proof' the 
> > field - but it's pretty ineffectual at that, because half of the code uses 
> > ->cpus_allowed directly ...
> > 
> > Also, the wrapper makes the code longer than the original expression!
> 
> I still object to taking this out without replacement.

Yeah, that would have been my next suggestion.

> This leaves RT stranded.

Well, no, it leaves -rt with slightly more patching work than it already has...

Because note how the wrappery is _already_ incomplete to a significant degree:

  triton:~/tip> git grep -Ee '->cpus_allowed' | grep -vE 'tsk_|cpuset|core.c' | wc -l
  27
  triton:~/tip> git grep tsk_cpus_allowed | wc -l
  43

I.e. around 40% of the places that use ->cpus_allowed in the upstream kernel are 
not properly wrapped. That fact already 'wrecks' -rt.

Thanks,

	Ingo