Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed()

[Thomas Gleixner <tglx@linutronix.de>]

On Mon, 6 Feb 2017, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > cpumasks are a pain, the above avoids allocating more of them.

Indeed.

> Yeah, so this could then be done by pointerifying ->cpus_allowed - more robust 
> than the wrappery,

You mean:

struct task_struct {
       cpumask_t	cpus_allowed;
       cpumask_t	*effective_cpus_allowed;
};

and make the scheduler use effective_cpus_allowed instead of cpus_allowed?
Or what do you have in mind?

> because as I've noted in the changelog there's a large body of 
> upstream code that does not use the wrappers but uses ->cpus_allowed directly:

Right and we really should audit those places. I bet that half of them are
just broken and evil hacks.

The wrapper we added is just covering the core scheduler code where the
information really matters for decision, but leaves the other oddball cases
alone.

The extra pointer might be a nicer concept, but it still has the same issue
as the wrapper. How do we enforce that random code accesses the right
thing?

Thanks,

	tglx