Re: [PATCH v4] sched/core: Use zero length to reset cpumasks in sched_setaffinity()

[Waiman Long]

On 10/4/23 08:55, Florian Weimer wrote:
> * Waiman Long:
>
> > On 10/4/23 08:34, Florian Weimer wrote:
> > > * Peter Zijlstra:
> > >
> > > > Subject: sched: Add CPU_FILL()
> > > >
> > > > Add the CPU_FILL() macros to easily create an all-set cpumask.
> > > >
> > > > FreeBSD also provides this macro with this semantic.
> > > >
> > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> > > My main concer is that obtaining the size of the mask, or at least an
> > > approximiation is not exactly easy.  If there's an expectation that
> > > applications reset the mask more often than they do today (I don't have
> > > the full context here), then we'd some decent interface to get the
> > > approriate size.
> > I believe the macro just use sizeof(cpu_set_t) as the size of the
> > bitmask. It is the same case as in CPU_ZERO().
> I mean the CPU_FILL_S macro also defined in the patch.  Correctly
> written applications should not use CPU_FILL and statically sized CPU
> sets.

Right, that can be a problem. If the input bitmask size is less than 
cpumask_size(), CPU_FILL_S() won't work to reset the cpumask. In fact, 
it will treat that bitmask just like a regular sched_setaffinity() call 
and set it accordingly.

With that caveat, I would prefer to keep using a length of 0 for the 
reset then.

Cheers,
Longman