On Mon, Mar 6, 2023 at 5:39 PM Yury Norov <yury.no...@gmail.com> wrote: > > On Tue, Mar 07, 2023 at 12:06:51AM +0800, Vernon Yang wrote: > > After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask > > optimizations"), the cpumask size is divided into three different case, > > so fix comment of cpumask_xxx correctly. > > > > Signed-off-by: Vernon Yang <vernon...@gmail.com> > > --- > > include/linux/cpumask.h | 46 ++++++++++++++++++++--------------------- > > 1 file changed, 23 insertions(+), 23 deletions(-) > > > > diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h > > index 8fbe76607965..248bdb1c50dc 100644 > > --- a/include/linux/cpumask.h > > +++ b/include/linux/cpumask.h > > @@ -155,7 +155,7 @@ static __always_inline unsigned int > > cpumask_check(unsigned int cpu) > > * cpumask_first - get the first cpu in a cpumask > > * @srcp: the cpumask pointer > > * > > - * Returns >= nr_cpu_ids if no cpus set. > > + * Returns >= small_cpumask_bits if no cpus set. > > There's no such thing like small_cpumask_bits. Here and everywhere, > nr_cpu_ids must be used. > > Actually, before 596ff4a09b89 nr_cpumask_bits was deprecated, and it > must be like that for all users even now. > > nr_cpumask_bits must be considered as internal cpumask parameter and > never referenced outside of cpumask code.
What's the right thing I should do, then, for wireguard's usage and for random.c's usage? It sounds like you object to this patchset, but if the problem is real, it sounds like I should at least fix the two cases I maintain. What's the right check? Jason