From Jason at zx2c4.com  Mon Mar  6 16:44:41 2023
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 6 Mar 2023 17:44:41 +0100
Subject: [PATCH 5/5] cpumask: fix comment of cpumask_xxx
In-Reply-To: <ZAYXJ2E+JHcp2kD/@yury-laptop>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-6-vernon2gm@gmail.com>
 <ZAYXJ2E+JHcp2kD/@yury-laptop>
Message-ID: <CAHmME9r_JXNCVVCNxZRQkafA=eOOu5k0+AweRDor3tNu283bdg@mail.gmail.com>

On Mon, Mar 6, 2023 at 5:39?PM Yury Norov <yury.norov at 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 <vernon2gm at 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

From Jason at zx2c4.com  Mon Mar  6 17:04:44 2023
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 6 Mar 2023 18:04:44 +0100
Subject: [PATCH 5/5] cpumask: fix comment of cpumask_xxx
In-Reply-To: <ZAYartD+NsF1JxlH@yury-laptop>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-6-vernon2gm@gmail.com>
 <ZAYXJ2E+JHcp2kD/@yury-laptop>
 <CAHmME9r_JXNCVVCNxZRQkafA=eOOu5k0+AweRDor3tNu283bdg@mail.gmail.com>
 <ZAYartD+NsF1JxlH@yury-laptop>
Message-ID: <CAHmME9qRicEe7zCFWSfV+aQ4j6sZ3FAJu3fgMUMJJkfBV4AMMw@mail.gmail.com>

On Mon, Mar 6, 2023 at 5:54?PM Yury Norov <yury.norov at gmail.com> wrote:
>
> On Mon, Mar 06, 2023 at 05:44:41PM +0100, Jason A. Donenfeld wrote:
> > On Mon, Mar 6, 2023 at 5:39?PM Yury Norov <yury.norov at 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 <vernon2gm at 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?
>
> Everywhere outside of cpumasks internals use (cpu < nr_cpu_ids) to
> check if the cpu is in a valid range, like:
>
> cpu = cpumask_first(cpus);
> if (cpu >= nr_cpu_ids)
>         pr_err("There's no cpus");

Oh, okay, so the ones for wireguard and random.c in this series are
correct then? If so, could you give a Reviewed-by:, and then I'll
queue those up in my respective trees.

Jason

From torvalds at linux-foundation.org  Mon Mar  6 17:29:10 2023
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Mon, 6 Mar 2023 09:29:10 -0800
Subject: [PATCH 5/5] cpumask: fix comment of cpumask_xxx
In-Reply-To: <20230306160651.2016767-6-vernon2gm@gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-6-vernon2gm@gmail.com>
Message-ID: <CAHk-=whVnaTBt2Xm-A+8SMc5-q5CuZBDU6rUZ8yC8GoAnbTBvw@mail.gmail.com>

On Mon, Mar 6, 2023 at 8:07?AM Vernon Yang <vernon2gm at gmail.com> 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.

No no.

Those three cases are meant to be entirely internal optimizations.
They are literally just "preferred sizes".

The correct thing to do is always that

   * Returns >= nr_cpu_ids if no cpus set.

because nr_cpu_ids is always the *smallest* of the access sizes.

That's exactly why it's a ">=". The CPU mask stuff has always
historically potentially used a different size than the actual
nr_cpu_ids, in that it could do word-sized scans even when the machine
might only have a smaller set of CPUs.

So the whole "small" vs "large" should be seen entirely internal to
cpumask.h. We should not expose it outside (sadly, that already
happened with "nr_cpumask_size", which also was that kind of thing.

So no, this patch is wrong. If anything, the comments should be strengthened.

Of course, right now Guenter seems to be reporting a problem with that
optimization, so unless I figure out what is going on I'll just need
to revert it anyway.

                Linus

                Linus

From torvalds at linux-foundation.org  Mon Mar  6 17:47:34 2023
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Mon, 6 Mar 2023 09:47:34 -0800
Subject: [PATCH 5/5] cpumask: fix comment of cpumask_xxx
In-Reply-To: <CAHk-=whVnaTBt2Xm-A+8SMc5-q5CuZBDU6rUZ8yC8GoAnbTBvw@mail.gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-6-vernon2gm@gmail.com>
 <CAHk-=whVnaTBt2Xm-A+8SMc5-q5CuZBDU6rUZ8yC8GoAnbTBvw@mail.gmail.com>
Message-ID: <CAHk-=witXXeQuP9fgs4dDL2Ex0meXQiHJs+3JEfNdaPwngMVEg@mail.gmail.com>

On Mon, Mar 6, 2023 at 9:29?AM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> The correct thing to do is always that
>
>    * Returns >= nr_cpu_ids if no cpus set.
>
> because nr_cpu_ids is always the *smallest* of the access sizes.
>
> Of course, right now Guenter seems to be reporting a problem with that
> optimization, so unless I figure out what is going on I'll just need
> to revert it anyway.

Ahh. And the reason is exactly that people do *not* follow that
"Returns >= nr_cpu_ids" rule.

The drivers/char/random.c code is very wrong, and does

             if (cpu == nr_cpumask_bits)
                             cpu = cpumask_first(&timer_cpus);

which fails miserably exactly because it doesn't use ">=".

Oh well.

I'll have to look for more of this pattern, but basically all those
"xyz_cpumask_bits" things were supposed to always be just internal to
that header file implementation, which is *exactly* why you have to
check the result for ">= nr_cpu_ids".

       Linus

From torvalds at linux-foundation.org  Mon Mar  6 18:02:27 2023
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Mon, 6 Mar 2023 10:02:27 -0800
Subject: [PATCH 5/5] cpumask: fix comment of cpumask_xxx
In-Reply-To: <CAHk-=witXXeQuP9fgs4dDL2Ex0meXQiHJs+3JEfNdaPwngMVEg@mail.gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-6-vernon2gm@gmail.com>
 <CAHk-=whVnaTBt2Xm-A+8SMc5-q5CuZBDU6rUZ8yC8GoAnbTBvw@mail.gmail.com>
 <CAHk-=witXXeQuP9fgs4dDL2Ex0meXQiHJs+3JEfNdaPwngMVEg@mail.gmail.com>
Message-ID: <CAHk-=wj5hFp39ZM7fEtmctwkWdHHnx0X7c2j5Z8L+b18jUgcMQ@mail.gmail.com>

On Mon, Mar 6, 2023 at 9:47?AM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> The drivers/char/random.c code is very wrong, and does
>
>              if (cpu == nr_cpumask_bits)
>                              cpu = cpumask_first(&timer_cpus);
>
> which fails miserably exactly because it doesn't use ">=".

Turns out this "cpu == nr_cpumask_bits" pattern exists in a couple of
other places too.

It was always wrong, but it always just happened to work. The lpfc
SCSI driver in particular seems to *love* this pattern:

        start_cpu = cpumask_next(new_cpu, cpu_present_mask);
        if (start_cpu == nr_cpumask_bits)
                start_cpu = first_cpu;

and has repeated it multiple times, all incorrect.

We do have "cpumask_next_wrap()", and that *seems* to be what the lpcf
driver actually wants to do.

.. and then we have kernel/sched/fair.c, which is actually not buggy,
just odd. It uses nr_cpumask_bits too, but it uses it purely for its
own internal nefarious reasons - it's not actually related to the
cpumask functions at all, its just used as a "not valid CPU number".

I think that scheduler use is still very *wrong*, but it doesn't look
actively buggy.

The other cases all look very buggy indeed, but yes, they happened to
work, and now they don't. So commit 596ff4a09b89 ("cpumask:
re-introduce constant-sized cpumask optimizations") did break them.

I'd rather fix these bad users than revert, but there does seem to be
an alarming number of these things, which worries me:

     git grep '== nr_cpumask_bits'

and that's just checking for this *exact* thing.

                Linus

From torvalds at linux-foundation.org  Mon Mar  6 18:34:02 2023
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Mon, 6 Mar 2023 10:34:02 -0800
Subject: [PATCH 5/5] cpumask: fix comment of cpumask_xxx
In-Reply-To: <ZAYtRcbMeRUQFUw/@vernon-pc>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-6-vernon2gm@gmail.com>
 <CAHk-=whVnaTBt2Xm-A+8SMc5-q5CuZBDU6rUZ8yC8GoAnbTBvw@mail.gmail.com>
 <ZAYtRcbMeRUQFUw/@vernon-pc>
Message-ID: <CAHk-=whA2kEBk3ibg3mrxpuXOAJKdM_MC4MQ8gLmxerZ5URfvg@mail.gmail.com>

On Mon, Mar 6, 2023 at 10:13?AM Vernon Yang <vernon2gm at gmail.com> wrote:
>
> I also just see nr_cpumask_size exposed to outside, so...

Yeah, it's not great.

nr_cpumask_bits came out of the exact same "this is an internal value
that we use for optimized cpumask accesses", and existed exactly
because it *might* be the same as 'nr_cpu_ids', but it might also be a
simpler "small constant that is big enough" case.

It just depended on the exact kernel config which one was used.

But clearly that internal value then spread outside, and that then
caused problems when the internal implementation changed.

            Linus

From torvalds at linux-foundation.org  Mon Mar  6 18:48:04 2023
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Mon, 6 Mar 2023 10:48:04 -0800
Subject: [PATCH 3/5] scsi: lpfc: fix lpfc_cpu_affinity_check() if no
 further cpus set
In-Reply-To: <20230306160651.2016767-4-vernon2gm@gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-4-vernon2gm@gmail.com>
Message-ID: <CAHk-=wj73=Os1p=W7D2va=Rd81ZKvjb35yWgXQNgn1hXNRpAbw@mail.gmail.com>

On Mon, Mar 6, 2023 at 8:07?AM Vernon Yang <vernon2gm at gmail.com> wrote:
>
> -                               if (new_cpu == nr_cpumask_bits)
> +                               if (new_cpu >= nr_cpumask_bits)

This all should use "nr_cpu_ids", not "nr_cpumask_bits".

But I really suspect that it should all be rewritten to not do that
thing over and over, but just use a helper function for it.

  int lpfc_next_present_cpu(int n, int alternate)
  {
        n = cpumask_next(n, cpu_present_mask);
        if (n >= nr_cpu_ids)
                n = alternate;
        return n;
  }

and then you could just use

        start_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);

or similar.

              Linus

PS. We "kind of" already have a helper function for this:
cpumask_next_wrap(). But it's really meant for a different pattern
entirely, so let's not confuse things.

From dnlcrwfrd at gmail.com  Mon Mar  6 09:51:54 2023
From: dnlcrwfrd at gmail.com (Dan Crawford)
Date: Mon, 06 Mar 2023 20:51:54 +1100
Subject: Possible regression between 5.18.2 and 6.2.1
Message-ID: <CQZ7HWJCK18F.1AUR9FMHKPOXB@crawfs>

I recently updated a server from kernel version 5.18.2 to 6.2.1 and
discovered that WG clients could no longer connect; there were no
changes to configs. Reverting to 5.18.2 resolves the issue.

My server config looks something like

[Interface]
Address = 192.168.1.0/24
ListenPort = 51820
PrivateKey = XXX
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = XXX
AllowedIPs = 192.168.1.3/32

and my client config looks something like


[Interface]
Address = 192.168.1.3/32
DNS = 1.1.1.1
PrivateKey = XXX

[Peer]
AllowedIPs = 0.0.0.0/0
Endpoint = example.com:51820
PublicKey = XXX

On the server I get mysterious "packet has unallowed src ip" errors.
Playing around with various combinations of subnets and iptables
invocations doesn't seem to help. Was there a change to the config spec
that I missed? Or otherwise any other ideas what might be going on?

Thanks.

From vernon2gm at gmail.com  Mon Mar  6 16:06:46 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 00:06:46 +0800
Subject: [PATCH 0/5] fix call cpumask_next() if no further cpus set
Message-ID: <20230306160651.2016767-1-vernon2gm@gmail.com>

Hello,

I updated the Linux kernel to commit fe15c26ee26e ("Linux 6.3-rc1")
and found that when the system boots to systemd ranom initialization,
panic, as follows:

[    3.607299] BUG: unable to handle page fault for address: 000000000001cc43
[    3.607558] #PF: supervisor read access in kernel mode
[    3.607704] #PF: error_code(0x0000) - not-present page
[    3.607704] PGD 0 P4D 0
[    3.607704] Oops: 0000 [#1] PREEMPT SMP NOPTI
[    3.607704] CPU: 1 PID: 1 Comm: systemd Not tainted 6.3.0-rc1 #50
[    3.607704] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[    3.607704] RIP: 0010:_raw_spin_lock+0x12/0x30
[    3.607704] Code: 84 00 00 00 00 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 ff 05 dd de 1e 7e 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 05 c3 cc cc cc cc 89 c6 e9 9c 00 00 00 6
[    3.607704] RSP: 0018:ffffc90000013d50 EFLAGS: 00000002
[    3.607704] RAX: 0000000000000000 RBX: 0000000000000040 RCX: 0000000000000002
[    3.607704] RDX: 0000000000000001 RSI: 0000000000000246 RDI: 000000000001cc43
[    3.607704] RBP: ffffc90000013dc8 R08: 00000000d6fbd601 R09: 0000000065abc912
[    3.607704] R10: 00000000ba93b167 R11: 000000007bb5d0bf R12: 000000000001cc43
[    3.607704] R13: 000000000001cc43 R14: 0000000000000003 R15: 0000000000000003
[    3.607704] FS:  00007fbd4911b400(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
[    3.607704] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.607704] CR2: 000000000001cc43 CR3: 0000000003b42000 CR4: 00000000000006e0
[    3.607704] Call Trace:
[    3.607704]  <TASK>
[    3.607704]  add_timer_on+0x80/0x130
[    3.607704]  try_to_generate_entropy+0x246/0x270
[    3.607704]  ? do_filp_open+0xb1/0x160
[    3.607704]  ? __pfx_entropy_timer+0x10/0x10
[    3.607704]  ? inode_security+0x1d/0x60
[    3.607704]  urandom_read_iter+0x23/0x90
[    3.607704]  vfs_read+0x203/0x2d0
[    3.607704]  ksys_read+0x5e/0xe0
[    3.607704]  do_syscall_64+0x3f/0x90
[    3.607704]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
[    3.607704] RIP: 0033:0x7fbd49a25992
[    3.607704] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 4
[    3.607704] RSP: 002b:00007ffea3fe8318 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[    3.607704] RAX: ffffffffffffffda RBX: 0000000000000010 RCX: 00007fbd49a25992
[    3.607704] RDX: 0000000000000010 RSI: 00007ffea3fe83a0 RDI: 000000000000000c
[    3.607704] RBP: 000000000000000c R08: 3983c6a57a866072 R09: c736ebfbeb917d7e
[    3.607704] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[    3.607704] R13: 0000000000000001 R14: 00007ffea3fe83a0 R15: 00005609e5454ea8
[    3.607704]  </TASK>
[    3.607704] Modules linked in:
[    3.607704] CR2: 000000000001cc43
[    3.607704] ---[ end trace 0000000000000000 ]---
[    3.607704] RIP: 0010:_raw_spin_lock+0x12/0x30
[    3.607704] Code: 84 00 00 00 00 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 ff 05 dd de 1e 7e 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 05 c3 cc cc cc cc 89 c6 e9 9c 00 00 00 6
[    3.607704] RSP: 0018:ffffc90000013d50 EFLAGS: 00000002
[    3.607704] RAX: 0000000000000000 RBX: 0000000000000040 RCX: 0000000000000002
[    3.607704] RDX: 0000000000000001 RSI: 0000000000000246 RDI: 000000000001cc43
[    3.607704] RBP: ffffc90000013dc8 R08: 00000000d6fbd601 R09: 0000000065abc912
[    3.607704] R10: 00000000ba93b167 R11: 000000007bb5d0bf R12: 000000000001cc43
[    3.607704] R13: 000000000001cc43 R14: 0000000000000003 R15: 0000000000000003
[    3.607704] FS:  00007fbd4911b400(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
[    3.607704] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.607704] CR2: 000000000001cc43 CR3: 0000000003b42000 CR4: 00000000000006e0
[    3.607704] note: systemd[1] exited with irqs disabled
[    3.618556] note: systemd[1] exited with preempt_count 2
[    3.618991] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    3.619797] Kernel Offset: disabled
[    3.619798] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]---


Analysis add_timer_on() found that the parameter cpu is equal to 64, which
feels strange, because qemu only specifies two CPUs, continues to look up,
and finds that the parameter cpu is obtained by
try_to_generate_entropy() -> cpumask_next().

Then use git bisect to find the bug, and find that it was introduced by
commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask optimizations"),
carefully analyzing the cpumask_next() modification record, I found that
nr_cpumask_bits modified to small_cpumask_bits, and when NR_CPUS <= BITS_PER_LONG,
small_cpumask_bits is a macro and before nr_cpumask_bits is a variable-sized.

look for find_next_bit() If no bits are set, returns @size, I seem to
understand the cause of the problem.

I fixed this bug by make `if (cpu == nr_cpumask_bits)` to `if (cpu >= nr_cpumask_bits)`

At the same time I think about this situation, maybe there are the same errors
elsewhere, check it, sure enough, there are, quite a few.

The patch "random:xxx" has been verified, it is valid, the other three fixes
have not been verified, because I do not have an environment, but they
principle are same, so also submitted at the same time, if someone helps to
verify, thanks you very much.

If there is anything error, please tell me, thanks.

Vernon Yang (5):
  random: fix try_to_generate_entropy() if no further cpus set
  wireguard: fix wg_cpumask_choose_online() if no further cpus set
  scsi: lpfc: fix lpfc_cpu_affinity_check() if no further cpus set
  scsi: lpfc: fix lpfc_nvmet_setup_io_context() if no further cpus set
  cpumask: fix comment of cpumask_xxx

 drivers/char/random.c            |  2 +-
 drivers/net/wireguard/queueing.h |  2 +-
 drivers/scsi/lpfc/lpfc_init.c    | 14 +++++-----
 drivers/scsi/lpfc/lpfc_nvmet.c   |  2 +-
 include/linux/cpumask.h          | 46 ++++++++++++++++----------------
 5 files changed, 33 insertions(+), 33 deletions(-)

--
2.34.1


From vernon2gm at gmail.com  Mon Mar  6 16:06:47 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 00:06:47 +0800
Subject: [PATCH 1/5] random: fix try_to_generate_entropy() if no further cpus
 set
In-Reply-To: <20230306160651.2016767-1-vernon2gm@gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
Message-ID: <20230306160651.2016767-2-vernon2gm@gmail.com>

After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), when NR_CPUS <= BITS_PER_LONG, small_cpumask_bits used
a macro instead of variable-sized for efficient.

If no further cpus set, the cpumask_next() returns small_cpumask_bits,
it must greater than or equal to nr_cpumask_bits, so fix it to correctly.

Signed-off-by: Vernon Yang <vernon2gm at gmail.com>
---
 drivers/char/random.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index ce3ccd172cc8..d76f12a5f74f 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1311,7 +1311,7 @@ static void __cold try_to_generate_entropy(void)
 			/* Basic CPU round-robin, which avoids the current CPU. */
 			do {
 				cpu = cpumask_next(cpu, &timer_cpus);
-				if (cpu == nr_cpumask_bits)
+				if (cpu >= nr_cpumask_bits)
 					cpu = cpumask_first(&timer_cpus);
 			} while (cpu == smp_processor_id() && num_cpus > 1);
 
-- 
2.34.1


From vernon2gm at gmail.com  Mon Mar  6 16:06:48 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 00:06:48 +0800
Subject: [PATCH 2/5] wireguard: fix wg_cpumask_choose_online() if no further
 cpus set
In-Reply-To: <20230306160651.2016767-1-vernon2gm@gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
Message-ID: <20230306160651.2016767-3-vernon2gm@gmail.com>

After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), when NR_CPUS <= BITS_PER_LONG, small_cpumask_bits used
a macro instead of variable-sized for efficient.

If no further cpus set, the cpumask_next() returns small_cpumask_bits,
it must greater than or equal to nr_cpumask_bits, so fix it to correctly.

Signed-off-by: Vernon Yang <vernon2gm at gmail.com>
---
 drivers/net/wireguard/queueing.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h
index 583adb37ee1e..41adeac3ee0b 100644
--- a/drivers/net/wireguard/queueing.h
+++ b/drivers/net/wireguard/queueing.h
@@ -106,7 +106,7 @@ static inline int wg_cpumask_choose_online(int *stored_cpu, unsigned int id)
 {
 	unsigned int cpu = *stored_cpu, cpu_index, i;
 
-	if (unlikely(cpu == nr_cpumask_bits ||
+	if (unlikely(cpu >= nr_cpumask_bits ||
 		     !cpumask_test_cpu(cpu, cpu_online_mask))) {
 		cpu_index = id % cpumask_weight(cpu_online_mask);
 		cpu = cpumask_first(cpu_online_mask);
-- 
2.34.1


From vernon2gm at gmail.com  Mon Mar  6 16:06:49 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 00:06:49 +0800
Subject: [PATCH 3/5] scsi: lpfc: fix lpfc_cpu_affinity_check() if no further
 cpus set
In-Reply-To: <20230306160651.2016767-1-vernon2gm@gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
Message-ID: <20230306160651.2016767-4-vernon2gm@gmail.com>

After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), when NR_CPUS <= BITS_PER_LONG, small_cpumask_bits used
a macro instead of variable-sized for efficient.

If no further cpus set, the cpumask_next() returns small_cpumask_bits,
it must greater than or equal to nr_cpumask_bits, so fix it to correctly.

Signed-off-by: Vernon Yang <vernon2gm at gmail.com>
---
 drivers/scsi/lpfc/lpfc_init.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 61958a24a43d..01c0e2f47cf7 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -12563,7 +12563,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 					goto found_same;
 				new_cpu = cpumask_next(
 					new_cpu, cpu_present_mask);
-				if (new_cpu == nr_cpumask_bits)
+				if (new_cpu >= nr_cpumask_bits)
 					new_cpu = first_cpu;
 			}
 			/* At this point, we leave the CPU as unassigned */
@@ -12577,7 +12577,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 			 * selecting the same IRQ.
 			 */
 			start_cpu = cpumask_next(new_cpu, cpu_present_mask);
-			if (start_cpu == nr_cpumask_bits)
+			if (start_cpu >= nr_cpumask_bits)
 				start_cpu = first_cpu;
 
 			lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
@@ -12613,7 +12613,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 					goto found_any;
 				new_cpu = cpumask_next(
 					new_cpu, cpu_present_mask);
-				if (new_cpu == nr_cpumask_bits)
+				if (new_cpu >= nr_cpumask_bits)
 					new_cpu = first_cpu;
 			}
 			/* We should never leave an entry unassigned */
@@ -12631,7 +12631,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 			 * selecting the same IRQ.
 			 */
 			start_cpu = cpumask_next(new_cpu, cpu_present_mask);
-			if (start_cpu == nr_cpumask_bits)
+			if (start_cpu >= nr_cpumask_bits)
 				start_cpu = first_cpu;
 
 			lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
@@ -12704,7 +12704,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 				goto found_hdwq;
 			}
 			new_cpu = cpumask_next(new_cpu, cpu_present_mask);
-			if (new_cpu == nr_cpumask_bits)
+			if (new_cpu >= nr_cpumask_bits)
 				new_cpu = first_cpu;
 		}
 
@@ -12719,7 +12719,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 				goto found_hdwq;
 
 			new_cpu = cpumask_next(new_cpu, cpu_present_mask);
-			if (new_cpu == nr_cpumask_bits)
+			if (new_cpu >= nr_cpumask_bits)
 				new_cpu = first_cpu;
 		}
 
@@ -12730,7 +12730,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
  found_hdwq:
 		/* We found an available entry, copy the IRQ info */
 		start_cpu = cpumask_next(new_cpu, cpu_present_mask);
-		if (start_cpu == nr_cpumask_bits)
+		if (start_cpu >= nr_cpumask_bits)
 			start_cpu = first_cpu;
 		cpup->hdwq = new_cpup->hdwq;
  logit:
-- 
2.34.1


From vernon2gm at gmail.com  Mon Mar  6 16:06:50 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 00:06:50 +0800
Subject: [PATCH 4/5] scsi: lpfc: fix lpfc_nvmet_setup_io_context() if no
 further cpus set
In-Reply-To: <20230306160651.2016767-1-vernon2gm@gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
Message-ID: <20230306160651.2016767-5-vernon2gm@gmail.com>

After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), when NR_CPUS <= BITS_PER_LONG, small_cpumask_bits used
a macro instead of variable-sized for efficient.

If no further cpus set, the cpumask_next() returns small_cpumask_bits,
it must greater than or equal to nr_cpumask_bits, so fix it to correctly.

Signed-off-by: Vernon Yang <vernon2gm at gmail.com>
---
 drivers/scsi/lpfc/lpfc_nvmet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_nvmet.c b/drivers/scsi/lpfc/lpfc_nvmet.c
index 7517dd55fe91..3ae7f330f827 100644
--- a/drivers/scsi/lpfc/lpfc_nvmet.c
+++ b/drivers/scsi/lpfc/lpfc_nvmet.c
@@ -1621,7 +1621,7 @@ lpfc_nvmet_setup_io_context(struct lpfc_hba *phba)
 			continue;
 		}
 		cpu = cpumask_next(cpu, cpu_present_mask);
-		if (cpu == nr_cpu_ids)
+		if (cpu >= nr_cpu_ids)
 			cpu = cpumask_first(cpu_present_mask);
 
 	}
-- 
2.34.1


From vernon2gm at gmail.com  Mon Mar  6 16:06:51 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 00:06:51 +0800
Subject: [PATCH 5/5] cpumask: fix comment of cpumask_xxx
In-Reply-To: <20230306160651.2016767-1-vernon2gm@gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
Message-ID: <20230306160651.2016767-6-vernon2gm@gmail.com>

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 <vernon2gm at 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.
  */
 static inline unsigned int cpumask_first(const struct cpumask *srcp)
 {
@@ -166,7 +166,7 @@ static inline unsigned int cpumask_first(const struct cpumask *srcp)
  * cpumask_first_zero - get the first unset cpu in a cpumask
  * @srcp: the cpumask pointer
  *
- * Returns >= nr_cpu_ids if all cpus are set.
+ * Returns >= small_cpumask_bits if all cpus are set.
  */
 static inline unsigned int cpumask_first_zero(const struct cpumask *srcp)
 {
@@ -178,7 +178,7 @@ static inline unsigned int cpumask_first_zero(const struct cpumask *srcp)
  * @src1p: the first input
  * @src2p: the second input
  *
- * Returns >= nr_cpu_ids if no cpus set in both.  See also cpumask_next_and().
+ * Returns >= small_cpumask_bits if no cpus set in both.  See also cpumask_next_and().
  */
 static inline
 unsigned int cpumask_first_and(const struct cpumask *srcp1, const struct cpumask *srcp2)
@@ -190,7 +190,7 @@ unsigned int cpumask_first_and(const struct cpumask *srcp1, const struct cpumask
  * cpumask_last - get the last CPU in a cpumask
  * @srcp:	- the cpumask pointer
  *
- * Returns	>= nr_cpumask_bits if no CPUs set.
+ * Returns	>= small_cpumask_bits if no CPUs set.
  */
 static inline unsigned int cpumask_last(const struct cpumask *srcp)
 {
@@ -202,7 +202,7 @@ static inline unsigned int cpumask_last(const struct cpumask *srcp)
  * @n: the cpu prior to the place to search (ie. return will be > @n)
  * @srcp: the cpumask pointer
  *
- * Returns >= nr_cpu_ids if no further cpus set.
+ * Returns >= small_cpumask_bits if no further cpus set.
  */
 static inline
 unsigned int cpumask_next(int n, const struct cpumask *srcp)
@@ -218,7 +218,7 @@ unsigned int cpumask_next(int n, const struct cpumask *srcp)
  * @n: the cpu prior to the place to search (ie. return will be > @n)
  * @srcp: the cpumask pointer
  *
- * Returns >= nr_cpu_ids if no further cpus unset.
+ * Returns >= small_cpumask_bits if no further cpus unset.
  */
 static inline unsigned int cpumask_next_zero(int n, const struct cpumask *srcp)
 {
@@ -258,7 +258,7 @@ unsigned int cpumask_any_distribute(const struct cpumask *srcp);
  * @src1p: the first cpumask pointer
  * @src2p: the second cpumask pointer
  *
- * Returns >= nr_cpu_ids if no further cpus set in both.
+ * Returns >= small_cpumask_bits if no further cpus set in both.
  */
 static inline
 unsigned int cpumask_next_and(int n, const struct cpumask *src1p,
@@ -276,7 +276,7 @@ unsigned int cpumask_next_and(int n, const struct cpumask *src1p,
  * @cpu: the (optionally unsigned) integer iterator
  * @mask: the cpumask pointer
  *
- * After the loop, cpu is >= nr_cpu_ids.
+ * After the loop, cpu is >= small_cpumask_bits.
  */
 #define for_each_cpu(cpu, mask)				\
 	for_each_set_bit(cpu, cpumask_bits(mask), small_cpumask_bits)
@@ -310,7 +310,7 @@ unsigned int __pure cpumask_next_wrap(int n, const struct cpumask *mask, int sta
  *
  * The implementation does not assume any bit in @mask is set (including @start).
  *
- * After the loop, cpu is >= nr_cpu_ids.
+ * After the loop, cpu is >= small_cpumask_bits.
  */
 #define for_each_cpu_wrap(cpu, mask, start)				\
 	for_each_set_bit_wrap(cpu, cpumask_bits(mask), small_cpumask_bits, start)
@@ -327,7 +327,7 @@ unsigned int __pure cpumask_next_wrap(int n, const struct cpumask *mask, int sta
  *	for_each_cpu(cpu, &tmp)
  *		...
  *
- * After the loop, cpu is >= nr_cpu_ids.
+ * After the loop, cpu is >= small_cpumask_bits.
  */
 #define for_each_cpu_and(cpu, mask1, mask2)				\
 	for_each_and_bit(cpu, cpumask_bits(mask1), cpumask_bits(mask2), small_cpumask_bits)
@@ -345,7 +345,7 @@ unsigned int __pure cpumask_next_wrap(int n, const struct cpumask *mask, int sta
  *	for_each_cpu(cpu, &tmp)
  *		...
  *
- * After the loop, cpu is >= nr_cpu_ids.
+ * After the loop, cpu is >= small_cpumask_bits.
  */
 #define for_each_cpu_andnot(cpu, mask1, mask2)				\
 	for_each_andnot_bit(cpu, cpumask_bits(mask1), cpumask_bits(mask2), small_cpumask_bits)
@@ -375,7 +375,7 @@ unsigned int cpumask_any_but(const struct cpumask *mask, unsigned int cpu)
  * @srcp: the cpumask pointer
  * @cpu: the N'th cpu to find, starting from 0
  *
- * Returns >= nr_cpu_ids if such cpu doesn't exist.
+ * Returns >= small_cpumask_bits if such cpu doesn't exist.
  */
 static inline unsigned int cpumask_nth(unsigned int cpu, const struct cpumask *srcp)
 {
@@ -388,7 +388,7 @@ static inline unsigned int cpumask_nth(unsigned int cpu, const struct cpumask *s
  * @srcp2: the cpumask pointer
  * @cpu: the N'th cpu to find, starting from 0
  *
- * Returns >= nr_cpu_ids if such cpu doesn't exist.
+ * Returns >= small_cpumask_bits if such cpu doesn't exist.
  */
 static inline
 unsigned int cpumask_nth_and(unsigned int cpu, const struct cpumask *srcp1,
@@ -404,7 +404,7 @@ unsigned int cpumask_nth_and(unsigned int cpu, const struct cpumask *srcp1,
  * @srcp2: the cpumask pointer
  * @cpu: the N'th cpu to find, starting from 0
  *
- * Returns >= nr_cpu_ids if such cpu doesn't exist.
+ * Returns >= small_cpumask_bits if such cpu doesn't exist.
  */
 static inline
 unsigned int cpumask_nth_andnot(unsigned int cpu, const struct cpumask *srcp1,
@@ -421,7 +421,7 @@ unsigned int cpumask_nth_andnot(unsigned int cpu, const struct cpumask *srcp1,
  * @srcp3: the cpumask pointer
  * @cpu: the N'th cpu to find, starting from 0
  *
- * Returns >= nr_cpu_ids if such cpu doesn't exist.
+ * Returns >= small_cpumask_bits if such cpu doesn't exist.
  */
 static __always_inline
 unsigned int cpumask_nth_and_andnot(unsigned int cpu, const struct cpumask *srcp1,
@@ -529,7 +529,7 @@ static inline void cpumask_setall(struct cpumask *dstp)
 }
 
 /**
- * cpumask_clear - clear all cpus (< nr_cpu_ids) in a cpumask
+ * cpumask_clear - clear all cpus (< large_cpumask_bits) in a cpumask
  * @dstp: the cpumask pointer
  */
 static inline void cpumask_clear(struct cpumask *dstp)
@@ -650,7 +650,7 @@ static inline bool cpumask_subset(const struct cpumask *src1p,
 
 /**
  * cpumask_empty - *srcp == 0
- * @srcp: the cpumask to that all cpus < nr_cpu_ids are clear.
+ * @srcp: the cpumask to that all cpus < small_cpumask_bits are clear.
  */
 static inline bool cpumask_empty(const struct cpumask *srcp)
 {
@@ -659,7 +659,7 @@ static inline bool cpumask_empty(const struct cpumask *srcp)
 
 /**
  * cpumask_full - *srcp == 0xFFFFFFFF...
- * @srcp: the cpumask to that all cpus < nr_cpu_ids are set.
+ * @srcp: the cpumask to that all cpus < nr_cpumask_bits are set.
  */
 static inline bool cpumask_full(const struct cpumask *srcp)
 {
@@ -668,7 +668,7 @@ static inline bool cpumask_full(const struct cpumask *srcp)
 
 /**
  * cpumask_weight - Count of bits in *srcp
- * @srcp: the cpumask to count bits (< nr_cpu_ids) in.
+ * @srcp: the cpumask to count bits (< small_cpumask_bits) in.
  */
 static inline unsigned int cpumask_weight(const struct cpumask *srcp)
 {
@@ -677,8 +677,8 @@ static inline unsigned int cpumask_weight(const struct cpumask *srcp)
 
 /**
  * cpumask_weight_and - Count of bits in (*srcp1 & *srcp2)
- * @srcp1: the cpumask to count bits (< nr_cpu_ids) in.
- * @srcp2: the cpumask to count bits (< nr_cpu_ids) in.
+ * @srcp1: the cpumask to count bits (< small_cpumask_bits) in.
+ * @srcp2: the cpumask to count bits (< small_cpumask_bits) in.
  */
 static inline unsigned int cpumask_weight_and(const struct cpumask *srcp1,
 						const struct cpumask *srcp2)
@@ -727,7 +727,7 @@ static inline void cpumask_copy(struct cpumask *dstp,
  * cpumask_any - pick a "random" cpu from *srcp
  * @srcp: the input cpumask
  *
- * Returns >= nr_cpu_ids if no cpus set.
+ * Returns >= small_cpumask_bits if no cpus set.
  */
 #define cpumask_any(srcp) cpumask_first(srcp)
 
@@ -736,7 +736,7 @@ static inline void cpumask_copy(struct cpumask *dstp,
  * @mask1: the first input cpumask
  * @mask2: the second input cpumask
  *
- * Returns >= nr_cpu_ids if no cpus set.
+ * Returns >= small_cpumask_bits if no cpus set.
  */
 #define cpumask_any_and(mask1, mask2) cpumask_first_and((mask1), (mask2))
 
-- 
2.34.1


From yury.norov at gmail.com  Mon Mar  6 16:26:32 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Mon, 6 Mar 2023 08:26:32 -0800
Subject: [PATCH 1/5] random: fix try_to_generate_entropy() if no further
 cpus set
In-Reply-To: <20230306160651.2016767-2-vernon2gm@gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-2-vernon2gm@gmail.com>
Message-ID: <ZAYUODI1yaH5PqHk@yury-laptop>

On Tue, Mar 07, 2023 at 12:06:47AM +0800, Vernon Yang wrote:
> After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
> optimizations"), when NR_CPUS <= BITS_PER_LONG, small_cpumask_bits used
> a macro instead of variable-sized for efficient.
> 
> If no further cpus set, the cpumask_next() returns small_cpumask_bits,
> it must greater than or equal to nr_cpumask_bits, so fix it to correctly.
> 
> Signed-off-by: Vernon Yang <vernon2gm at gmail.com>

Hi Vernon,

In all that cases, nr_cpu_ids must be used. The difference is that
nr_cpumask_bits is an upper limit for possible CPUs, and it's derived
from compile-time NR_CPUS, unless CPUMASK_OFFSTACK is enabled.

nr_cpu_ids is an actual number of CPUS as counted on boot.

So, nr_cpu_ids is always equal or less than nr_cpumask_bits, and we'd
compare with the smaller number.

Nor sure, but maybe it's worth to introduce a macro like:
 #define valid_cpuid(cpu) (cpu) < nr_cpu_ids

Thanks,
Yury
> ---
>  drivers/char/random.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index ce3ccd172cc8..d76f12a5f74f 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1311,7 +1311,7 @@ static void __cold try_to_generate_entropy(void)
>  			/* Basic CPU round-robin, which avoids the current CPU. */
>  			do {
>  				cpu = cpumask_next(cpu, &timer_cpus);
> -				if (cpu == nr_cpumask_bits)
> +				if (cpu >= nr_cpumask_bits)
>  					cpu = cpumask_first(&timer_cpus);
>  			} while (cpu == smp_processor_id() && num_cpus > 1);
>  
> -- 
> 2.34.1

From yury.norov at gmail.com  Mon Mar  6 16:39:03 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Mon, 6 Mar 2023 08:39:03 -0800
Subject: [PATCH 5/5] cpumask: fix comment of cpumask_xxx
In-Reply-To: <20230306160651.2016767-6-vernon2gm@gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-6-vernon2gm@gmail.com>
Message-ID: <ZAYXJ2E+JHcp2kD/@yury-laptop>

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 <vernon2gm at 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.

Thansk,
Yury

From yury.norov at gmail.com  Mon Mar  6 16:54:06 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Mon, 6 Mar 2023 08:54:06 -0800
Subject: [PATCH 5/5] cpumask: fix comment of cpumask_xxx
In-Reply-To: <CAHmME9r_JXNCVVCNxZRQkafA=eOOu5k0+AweRDor3tNu283bdg@mail.gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-6-vernon2gm@gmail.com>
 <ZAYXJ2E+JHcp2kD/@yury-laptop>
 <CAHmME9r_JXNCVVCNxZRQkafA=eOOu5k0+AweRDor3tNu283bdg@mail.gmail.com>
Message-ID: <ZAYartD+NsF1JxlH@yury-laptop>

On Mon, Mar 06, 2023 at 05:44:41PM +0100, Jason A. Donenfeld wrote:
> On Mon, Mar 6, 2023 at 5:39?PM Yury Norov <yury.norov at 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 <vernon2gm at 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?

Everywhere outside of cpumasks internals use (cpu < nr_cpu_ids) to
check if the cpu is in a valid range, like:

cpu = cpumask_first(cpus);
if (cpu >= nr_cpu_ids)
        pr_err("There's no cpus");
 


From vernon2gm at gmail.com  Mon Mar  6 17:45:13 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue, 7 Mar 2023 01:45:13 +0800
Subject: [PATCH 5/5] cpumask: fix comment of cpumask_xxx
In-Reply-To: <ZAYXJ2E+JHcp2kD/@yury-laptop>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-6-vernon2gm@gmail.com>
 <ZAYXJ2E+JHcp2kD/@yury-laptop>
Message-ID: <ZAYmqVmeYdDPVpLZ@vernon-pc>

On Mon, Mar 06, 2023 at 08:39:03AM -0800, Yury Norov 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 <vernon2gm at 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.

OK, I remove this path for next version.

>
> Thansk,
> Yury

From vernon2gm at gmail.com  Mon Mar  6 18:13:25 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue, 7 Mar 2023 02:13:25 +0800
Subject: [PATCH 5/5] cpumask: fix comment of cpumask_xxx
In-Reply-To: <CAHk-=whVnaTBt2Xm-A+8SMc5-q5CuZBDU6rUZ8yC8GoAnbTBvw@mail.gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-6-vernon2gm@gmail.com>
 <CAHk-=whVnaTBt2Xm-A+8SMc5-q5CuZBDU6rUZ8yC8GoAnbTBvw@mail.gmail.com>
Message-ID: <ZAYtRcbMeRUQFUw/@vernon-pc>

On Mon, Mar 06, 2023 at 09:29:10AM -0800, Linus Torvalds wrote:
> On Mon, Mar 6, 2023 at 8:07?AM Vernon Yang <vernon2gm at gmail.com> 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.
>
> No no.
>
> Those three cases are meant to be entirely internal optimizations.
> They are literally just "preferred sizes".
>
> The correct thing to do is always that
>
>    * Returns >= nr_cpu_ids if no cpus set.
>
> because nr_cpu_ids is always the *smallest* of the access sizes.
>
> That's exactly why it's a ">=". The CPU mask stuff has always
> historically potentially used a different size than the actual
> nr_cpu_ids, in that it could do word-sized scans even when the machine
> might only have a smaller set of CPUs.
>
> So the whole "small" vs "large" should be seen entirely internal to
> cpumask.h. We should not expose it outside (sadly, that already
> happened with "nr_cpumask_size", which also was that kind of thing.

I also just see nr_cpumask_size exposed to outside, so... Sorry.

>
> So no, this patch is wrong. If anything, the comments should be strengthened.
>
> Of course, right now Guenter seems to be reporting a problem with that
> optimization, so unless I figure out what is going on I'll just need
> to revert it anyway.

Yes, cause is the cpumask_next() calls find_next_bit(..., size, ...), and
find_next_bit(..., size, ...) if no bits are set, returns @size.

@size was a nr_cpumask_bits variable before, now it is small_cpumask_bits, and
when NR_CPUS < = BITS_PER_LONG, small_cpumask_bits is a macro, which is
replaced with NR_CPUS at compile, so only the NR_CPUS is returned when it no
further cpus set.

But before nr_cpumask_bits variable, it was read while running, and it was
mutable.

The random.c try_to_generate_entropy() to get first cpu by
`if (cpu == nr_cpumask_bits)`, but cpumask_next() alway return NR_CPUS,
nr_cpumask_bits is nr_cpu_ids, so pass NR_CPUS to add_timer_on(),

>
>                 Linus
>
>                 Linus

From vernon2gm at gmail.com  Mon Mar  6 20:09:37 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue, 7 Mar 2023 04:09:37 +0800
Subject: [PATCH 3/5] scsi: lpfc: fix lpfc_cpu_affinity_check() if no
 further cpus set
In-Reply-To: <CAHk-=wj73=Os1p=W7D2va=Rd81ZKvjb35yWgXQNgn1hXNRpAbw@mail.gmail.com>
References: <20230306160651.2016767-1-vernon2gm@gmail.com>
 <20230306160651.2016767-4-vernon2gm@gmail.com>
 <CAHk-=wj73=Os1p=W7D2va=Rd81ZKvjb35yWgXQNgn1hXNRpAbw@mail.gmail.com>
Message-ID: <ZAZIgcpEBE7HXBuy@vernon-pc>

On Mon, Mar 06, 2023 at 10:48:04AM -0800, Linus Torvalds wrote:
> On Mon, Mar 6, 2023 at 8:07?AM Vernon Yang <vernon2gm at gmail.com> wrote:
> >
> > -                               if (new_cpu == nr_cpumask_bits)
> > +                               if (new_cpu >= nr_cpumask_bits)
>
> This all should use "nr_cpu_ids", not "nr_cpumask_bits".
>
> But I really suspect that it should all be rewritten to not do that
> thing over and over, but just use a helper function for it.
>
>   int lpfc_next_present_cpu(int n, int alternate)
>   {
>         n = cpumask_next(n, cpu_present_mask);
>         if (n >= nr_cpu_ids)
>                 n = alternate;
>         return n;
>   }
>
> and then you could just use
>
>         start_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);

OK, thanks you very much.

I'll send a second version shortly

>
> or similar.
>
>               Linus
>
> PS. We "kind of" already have a helper function for this:
> cpumask_next_wrap(). But it's really meant for a different pattern
> entirely, so let's not confuse things.

From vernon2gm at gmail.com  Mon Mar  6 20:47:19 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 04:47:19 +0800
Subject: [PATCH v2 0/4] fix call cpumask_next() if no further cpus set
Message-ID: <20230306204723.2584724-1-vernon2gm@gmail.com>

Hello,

I updated the Linux kernel to commit fe15c26ee26e ("Linux 6.3-rc1")
and found that when the system boots to systemd ranom initialization,
panic, as follows:

[    3.607299] BUG: unable to handle page fault for address: 000000000001cc43
[    3.607558] #PF: supervisor read access in kernel mode
[    3.607704] #PF: error_code(0x0000) - not-present page
[    3.607704] PGD 0 P4D 0
[    3.607704] Oops: 0000 [#1] PREEMPT SMP NOPTI
[    3.607704] CPU: 1 PID: 1 Comm: systemd Not tainted 6.3.0-rc1 #50
[    3.607704] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[    3.607704] RIP: 0010:_raw_spin_lock+0x12/0x30
[    3.607704] Code: 84 00 00 00 00 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 ff 05 dd de 1e 7e 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 05 c3 cc cc cc cc 89 c6 e9 9c 00 00 00 6
[    3.607704] RSP: 0018:ffffc90000013d50 EFLAGS: 00000002
[    3.607704] RAX: 0000000000000000 RBX: 0000000000000040 RCX: 0000000000000002
[    3.607704] RDX: 0000000000000001 RSI: 0000000000000246 RDI: 000000000001cc43
[    3.607704] RBP: ffffc90000013dc8 R08: 00000000d6fbd601 R09: 0000000065abc912
[    3.607704] R10: 00000000ba93b167 R11: 000000007bb5d0bf R12: 000000000001cc43
[    3.607704] R13: 000000000001cc43 R14: 0000000000000003 R15: 0000000000000003
[    3.607704] FS:  00007fbd4911b400(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
[    3.607704] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.607704] CR2: 000000000001cc43 CR3: 0000000003b42000 CR4: 00000000000006e0
[    3.607704] Call Trace:
[    3.607704]  <TASK>
[    3.607704]  add_timer_on+0x80/0x130
[    3.607704]  try_to_generate_entropy+0x246/0x270
[    3.607704]  ? do_filp_open+0xb1/0x160
[    3.607704]  ? __pfx_entropy_timer+0x10/0x10
[    3.607704]  ? inode_security+0x1d/0x60
[    3.607704]  urandom_read_iter+0x23/0x90
[    3.607704]  vfs_read+0x203/0x2d0
[    3.607704]  ksys_read+0x5e/0xe0
[    3.607704]  do_syscall_64+0x3f/0x90
[    3.607704]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
[    3.607704] RIP: 0033:0x7fbd49a25992
[    3.607704] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 4
[    3.607704] RSP: 002b:00007ffea3fe8318 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[    3.607704] RAX: ffffffffffffffda RBX: 0000000000000010 RCX: 00007fbd49a25992
[    3.607704] RDX: 0000000000000010 RSI: 00007ffea3fe83a0 RDI: 000000000000000c
[    3.607704] RBP: 000000000000000c R08: 3983c6a57a866072 R09: c736ebfbeb917d7e
[    3.607704] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[    3.607704] R13: 0000000000000001 R14: 00007ffea3fe83a0 R15: 00005609e5454ea8
[    3.607704]  </TASK>
[    3.607704] Modules linked in:
[    3.607704] CR2: 000000000001cc43
[    3.607704] ---[ end trace 0000000000000000 ]---
[    3.607704] RIP: 0010:_raw_spin_lock+0x12/0x30
[    3.607704] Code: 84 00 00 00 00 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 ff 05 dd de 1e 7e 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 05 c3 cc cc cc cc 89 c6 e9 9c 00 00 00 6
[    3.607704] RSP: 0018:ffffc90000013d50 EFLAGS: 00000002
[    3.607704] RAX: 0000000000000000 RBX: 0000000000000040 RCX: 0000000000000002
[    3.607704] RDX: 0000000000000001 RSI: 0000000000000246 RDI: 000000000001cc43
[    3.607704] RBP: ffffc90000013dc8 R08: 00000000d6fbd601 R09: 0000000065abc912
[    3.607704] R10: 00000000ba93b167 R11: 000000007bb5d0bf R12: 000000000001cc43
[    3.607704] R13: 000000000001cc43 R14: 0000000000000003 R15: 0000000000000003
[    3.607704] FS:  00007fbd4911b400(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
[    3.607704] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.607704] CR2: 000000000001cc43 CR3: 0000000003b42000 CR4: 00000000000006e0
[    3.607704] note: systemd[1] exited with irqs disabled
[    3.618556] note: systemd[1] exited with preempt_count 2
[    3.618991] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    3.619797] Kernel Offset: disabled
[    3.619798] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]---


Analysis add_timer_on() found that the parameter cpu is equal to 64, which
feels strange, because qemu only specifies two CPUs, continues to look up,
and finds that the parameter cpu is obtained by
try_to_generate_entropy() -> cpumask_next().

Then use git bisect to find the bug, and find that it was introduced by
commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask optimizations"),
carefully analyzing the cpumask_next() modification record, I found that
nr_cpumask_bits modified to small_cpumask_bits, and when NR_CPUS <= BITS_PER_LONG,
small_cpumask_bits is a macro and before nr_cpumask_bits is a variable-sized.

look for find_next_bit() If no bits are set, returns @size, I seem to
understand the cause of the problem.

I fixed this bug by make `if (cpu == nr_cpumask_bits)` to `if (cpu >= nr_cpu_ids)`

At the same time I think about this situation, maybe there are the same errors
elsewhere, check it, sure enough, there are, quite a few.

The patch "random:xxx" has been verified, it is valid, the other three fixes
have not been verified, because I do not have an environment, but they
principle are same, so also submitted at the same time, if someone helps to
verify, thanks you very much.

If there is anything error, please tell me, thanks.


v2 changes:
 - remove patch 5
 - make nr_cpumask_bits to nr_cpu_ids
 - add helper function to get next present cpu for lpfc_cpu_affinity_check
 - update commit comment

v1: https://lore.kernel.org/all/20230306160651.2016767-1-vernon2gm at gmail.com/

Vernon Yang (4):
  random: fix try_to_generate_entropy() if no further cpus set
  wireguard: fix wg_cpumask_choose_online() if no further cpus set
  scsi: lpfc: fix lpfc_cpu_affinity_check() if no further cpus set
  scsi: lpfc: fix lpfc_nvmet_setup_io_context() if no further cpus set

 drivers/char/random.c            |  2 +-
 drivers/net/wireguard/queueing.h |  2 +-
 drivers/scsi/lpfc/lpfc_init.c    | 43 +++++++++++++++-----------------
 drivers/scsi/lpfc/lpfc_nvmet.c   |  2 +-
 4 files changed, 23 insertions(+), 26 deletions(-)

--
2.34.1


From vernon2gm at gmail.com  Mon Mar  6 20:47:20 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 04:47:20 +0800
Subject: [PATCH v2 1/4] random: fix try_to_generate_entropy() if no further
 cpus set
In-Reply-To: <20230306204723.2584724-1-vernon2gm@gmail.com>
References: <20230306204723.2584724-1-vernon2gm@gmail.com>
Message-ID: <20230306204723.2584724-2-vernon2gm@gmail.com>

When cpumask_next() the return value is greater than or equal to
nr_cpu_ids, it indicates invalid.

Before commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), when cpumask_next() returned an invalid cpu, the driver
used the judgment equal to nr_cpu_ids to indicate the invalid cpu, so it
happened to work normally, but this is the wrong approach.

After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), these incorrect practices actively buggy, so fix it to
correctly.

Signed-off-by: Vernon Yang <vernon2gm at gmail.com>
---
 drivers/char/random.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index ce3ccd172cc8..253f2ddb8913 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1311,7 +1311,7 @@ static void __cold try_to_generate_entropy(void)
 			/* Basic CPU round-robin, which avoids the current CPU. */
 			do {
 				cpu = cpumask_next(cpu, &timer_cpus);
-				if (cpu == nr_cpumask_bits)
+				if (cpu >= nr_cpu_ids)
 					cpu = cpumask_first(&timer_cpus);
 			} while (cpu == smp_processor_id() && num_cpus > 1);
 
-- 
2.34.1


From vernon2gm at gmail.com  Mon Mar  6 20:47:21 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 04:47:21 +0800
Subject: [PATCH v2 2/4] wireguard: fix wg_cpumask_choose_online() if no
 further cpus set
In-Reply-To: <20230306204723.2584724-1-vernon2gm@gmail.com>
References: <20230306204723.2584724-1-vernon2gm@gmail.com>
Message-ID: <20230306204723.2584724-3-vernon2gm@gmail.com>

When cpumask_next() the return value is greater than or equal to
nr_cpu_ids, it indicates invalid.

Before commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), when cpumask_next() returned an invalid cpu, the driver
used the judgment equal to nr_cpu_ids to indicate the invalid cpu, so it
happened to work normally, but this is the wrong approach.

After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), these incorrect practices actively buggy, so fix it to
correctly.

Signed-off-by: Vernon Yang <vernon2gm at gmail.com>
---
 drivers/net/wireguard/queueing.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h
index 583adb37ee1e..125284b346a7 100644
--- a/drivers/net/wireguard/queueing.h
+++ b/drivers/net/wireguard/queueing.h
@@ -106,7 +106,7 @@ static inline int wg_cpumask_choose_online(int *stored_cpu, unsigned int id)
 {
 	unsigned int cpu = *stored_cpu, cpu_index, i;
 
-	if (unlikely(cpu == nr_cpumask_bits ||
+	if (unlikely(cpu >= nr_cpu_ids ||
 		     !cpumask_test_cpu(cpu, cpu_online_mask))) {
 		cpu_index = id % cpumask_weight(cpu_online_mask);
 		cpu = cpumask_first(cpu_online_mask);
-- 
2.34.1


From vernon2gm at gmail.com  Mon Mar  6 21:03:08 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 05:03:08 +0800
Subject: [PATCH v2 0/4] fix call cpumask_next() if no further cpus set
Message-ID: <20230306210312.2614988-1-vernon2gm@gmail.com>

Hello,

I updated the Linux kernel to commit fe15c26ee26e ("Linux 6.3-rc1")
and found that when the system boots to systemd ranom initialization,
panic, as follows:

[    3.607299] BUG: unable to handle page fault for address: 000000000001cc43
[    3.607558] #PF: supervisor read access in kernel mode
[    3.607704] #PF: error_code(0x0000) - not-present page
[    3.607704] PGD 0 P4D 0
[    3.607704] Oops: 0000 [#1] PREEMPT SMP NOPTI
[    3.607704] CPU: 1 PID: 1 Comm: systemd Not tainted 6.3.0-rc1 #50
[    3.607704] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[    3.607704] RIP: 0010:_raw_spin_lock+0x12/0x30
[    3.607704] Code: 84 00 00 00 00 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 ff 05 dd de 1e 7e 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 05 c3 cc cc cc cc 89 c6 e9 9c 00 00 00 6
[    3.607704] RSP: 0018:ffffc90000013d50 EFLAGS: 00000002
[    3.607704] RAX: 0000000000000000 RBX: 0000000000000040 RCX: 0000000000000002
[    3.607704] RDX: 0000000000000001 RSI: 0000000000000246 RDI: 000000000001cc43
[    3.607704] RBP: ffffc90000013dc8 R08: 00000000d6fbd601 R09: 0000000065abc912
[    3.607704] R10: 00000000ba93b167 R11: 000000007bb5d0bf R12: 000000000001cc43
[    3.607704] R13: 000000000001cc43 R14: 0000000000000003 R15: 0000000000000003
[    3.607704] FS:  00007fbd4911b400(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
[    3.607704] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.607704] CR2: 000000000001cc43 CR3: 0000000003b42000 CR4: 00000000000006e0
[    3.607704] Call Trace:
[    3.607704]  <TASK>
[    3.607704]  add_timer_on+0x80/0x130
[    3.607704]  try_to_generate_entropy+0x246/0x270
[    3.607704]  ? do_filp_open+0xb1/0x160
[    3.607704]  ? __pfx_entropy_timer+0x10/0x10
[    3.607704]  ? inode_security+0x1d/0x60
[    3.607704]  urandom_read_iter+0x23/0x90
[    3.607704]  vfs_read+0x203/0x2d0
[    3.607704]  ksys_read+0x5e/0xe0
[    3.607704]  do_syscall_64+0x3f/0x90
[    3.607704]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
[    3.607704] RIP: 0033:0x7fbd49a25992
[    3.607704] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 4
[    3.607704] RSP: 002b:00007ffea3fe8318 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[    3.607704] RAX: ffffffffffffffda RBX: 0000000000000010 RCX: 00007fbd49a25992
[    3.607704] RDX: 0000000000000010 RSI: 00007ffea3fe83a0 RDI: 000000000000000c
[    3.607704] RBP: 000000000000000c R08: 3983c6a57a866072 R09: c736ebfbeb917d7e
[    3.607704] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[    3.607704] R13: 0000000000000001 R14: 00007ffea3fe83a0 R15: 00005609e5454ea8
[    3.607704]  </TASK>
[    3.607704] Modules linked in:
[    3.607704] CR2: 000000000001cc43
[    3.607704] ---[ end trace 0000000000000000 ]---
[    3.607704] RIP: 0010:_raw_spin_lock+0x12/0x30
[    3.607704] Code: 84 00 00 00 00 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 ff 05 dd de 1e 7e 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 05 c3 cc cc cc cc 89 c6 e9 9c 00 00 00 6
[    3.607704] RSP: 0018:ffffc90000013d50 EFLAGS: 00000002
[    3.607704] RAX: 0000000000000000 RBX: 0000000000000040 RCX: 0000000000000002
[    3.607704] RDX: 0000000000000001 RSI: 0000000000000246 RDI: 000000000001cc43
[    3.607704] RBP: ffffc90000013dc8 R08: 00000000d6fbd601 R09: 0000000065abc912
[    3.607704] R10: 00000000ba93b167 R11: 000000007bb5d0bf R12: 000000000001cc43
[    3.607704] R13: 000000000001cc43 R14: 0000000000000003 R15: 0000000000000003
[    3.607704] FS:  00007fbd4911b400(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
[    3.607704] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.607704] CR2: 000000000001cc43 CR3: 0000000003b42000 CR4: 00000000000006e0
[    3.607704] note: systemd[1] exited with irqs disabled
[    3.618556] note: systemd[1] exited with preempt_count 2
[    3.618991] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    3.619797] Kernel Offset: disabled
[    3.619798] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]---


Analysis add_timer_on() found that the parameter cpu is equal to 64, which
feels strange, because qemu only specifies two CPUs, continues to look up,
and finds that the parameter cpu is obtained by
try_to_generate_entropy() -> cpumask_next().

Then use git bisect to find the bug, and find that it was introduced by
commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask optimizations"),
carefully analyzing the cpumask_next() modification record, I found that
nr_cpumask_bits modified to small_cpumask_bits, and when NR_CPUS <= BITS_PER_LONG,
small_cpumask_bits is a macro and before nr_cpumask_bits is a variable-sized.

look for find_next_bit() If no bits are set, returns @size, I seem to
understand the cause of the problem.

I fixed this bug by make `if (cpu == nr_cpumask_bits)` to `if (cpu >= nr_cpu_ids)`

At the same time I think about this situation, maybe there are the same errors
elsewhere, check it, sure enough, there are, quite a few.

The patch "random:xxx" has been verified, it is valid, the other three fixes
have not been verified, because I do not have an environment, but they
principle are same, so also submitted at the same time, if someone helps to
verify, thanks you very much.

If there is anything error, please tell me, thanks.


v2 changes:
 - remove patch 5
 - make nr_cpumask_bits to nr_cpu_ids
 - add helper function to get next present cpu for lpfc_cpu_affinity_check
 - update commit comment

v1: https://lore.kernel.org/all/20230306160651.2016767-1-vernon2gm at gmail.com/

Vernon Yang (4):
  random: fix try_to_generate_entropy() if no further cpus set
  wireguard: fix wg_cpumask_choose_online() if no further cpus set
  scsi: lpfc: fix lpfc_cpu_affinity_check() if no further cpus set
  scsi: lpfc: fix lpfc_nvmet_setup_io_context() if no further cpus set

 drivers/char/random.c            |  2 +-
 drivers/net/wireguard/queueing.h |  2 +-
 drivers/scsi/lpfc/lpfc_init.c    | 43 +++++++++++++++-----------------
 drivers/scsi/lpfc/lpfc_nvmet.c   |  2 +-
 4 files changed, 23 insertions(+), 26 deletions(-)

--
2.34.1


From vernon2gm at gmail.com  Mon Mar  6 21:03:09 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 05:03:09 +0800
Subject: [PATCH v2 1/4] random: fix try_to_generate_entropy() if no further
 cpus set
In-Reply-To: <20230306210312.2614988-1-vernon2gm@gmail.com>
References: <20230306210312.2614988-1-vernon2gm@gmail.com>
Message-ID: <20230306210312.2614988-2-vernon2gm@gmail.com>

When cpumask_next() the return value is greater than or equal to
nr_cpu_ids, it indicates invalid.

Before commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), when cpumask_next() returned an invalid cpu, the driver
used the judgment equal to nr_cpu_ids to indicate the invalid cpu, so it
happened to work normally, but this is the wrong approach.

After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), these incorrect practices actively buggy, so fix it to
correctly.

Signed-off-by: Vernon Yang <vernon2gm at gmail.com>
---
 drivers/char/random.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index ce3ccd172cc8..253f2ddb8913 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1311,7 +1311,7 @@ static void __cold try_to_generate_entropy(void)
 			/* Basic CPU round-robin, which avoids the current CPU. */
 			do {
 				cpu = cpumask_next(cpu, &timer_cpus);
-				if (cpu == nr_cpumask_bits)
+				if (cpu >= nr_cpu_ids)
 					cpu = cpumask_first(&timer_cpus);
 			} while (cpu == smp_processor_id() && num_cpus > 1);
 
-- 
2.34.1


From vernon2gm at gmail.com  Mon Mar  6 21:03:10 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 05:03:10 +0800
Subject: [PATCH v2 2/4] wireguard: fix wg_cpumask_choose_online() if no
 further cpus set
In-Reply-To: <20230306210312.2614988-1-vernon2gm@gmail.com>
References: <20230306210312.2614988-1-vernon2gm@gmail.com>
Message-ID: <20230306210312.2614988-3-vernon2gm@gmail.com>

When cpumask_next() the return value is greater than or equal to
nr_cpu_ids, it indicates invalid.

Before commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), when cpumask_next() returned an invalid cpu, the driver
used the judgment equal to nr_cpu_ids to indicate the invalid cpu, so it
happened to work normally, but this is the wrong approach.

After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), these incorrect practices actively buggy, so fix it to
correctly.

Signed-off-by: Vernon Yang <vernon2gm at gmail.com>
---
 drivers/net/wireguard/queueing.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h
index 583adb37ee1e..125284b346a7 100644
--- a/drivers/net/wireguard/queueing.h
+++ b/drivers/net/wireguard/queueing.h
@@ -106,7 +106,7 @@ static inline int wg_cpumask_choose_online(int *stored_cpu, unsigned int id)
 {
 	unsigned int cpu = *stored_cpu, cpu_index, i;
 
-	if (unlikely(cpu == nr_cpumask_bits ||
+	if (unlikely(cpu >= nr_cpu_ids ||
 		     !cpumask_test_cpu(cpu, cpu_online_mask))) {
 		cpu_index = id % cpumask_weight(cpu_online_mask);
 		cpu = cpumask_first(cpu_online_mask);
-- 
2.34.1


From vernon2gm at gmail.com  Mon Mar  6 21:03:11 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 05:03:11 +0800
Subject: [PATCH v2 3/4] scsi: lpfc: fix lpfc_cpu_affinity_check() if no
 further cpus set
In-Reply-To: <20230306210312.2614988-1-vernon2gm@gmail.com>
References: <20230306210312.2614988-1-vernon2gm@gmail.com>
Message-ID: <20230306210312.2614988-4-vernon2gm@gmail.com>

When cpumask_next() the return value is greater than or equal to
nr_cpu_ids, it indicates invalid.

Before commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), when cpumask_next() returned an invalid cpu, the driver
used the judgment equal to nr_cpu_ids to indicate the invalid cpu, so it
happened to work normally, but this is the wrong approach.

After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), these incorrect practices actively buggy, so fix it to
correctly.

Signed-off-by: Vernon Yang <vernon2gm at gmail.com>
---
 drivers/scsi/lpfc/lpfc_init.c | 43 ++++++++++++++++-------------------
 1 file changed, 20 insertions(+), 23 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 61958a24a43d..acfffdbe9ba1 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -12473,6 +12473,16 @@ lpfc_hba_eq_hdl_array_init(struct lpfc_hba *phba)
 	}
 }
 
+static inline int lpfc_next_present_cpu(int n, int first_cpu)
+{
+	n = cpumask_next(n, cpu_present_mask);
+
+	if (n >= nr_cpu_ids)
+		n = first_cpu;
+
+	return n;
+}
+
 /**
  * lpfc_cpu_affinity_check - Check vector CPU affinity mappings
  * @phba: pointer to lpfc hba data structure.
@@ -12561,10 +12571,8 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 				    (new_cpup->eq != LPFC_VECTOR_MAP_EMPTY) &&
 				    (new_cpup->phys_id == cpup->phys_id))
 					goto found_same;
-				new_cpu = cpumask_next(
-					new_cpu, cpu_present_mask);
-				if (new_cpu == nr_cpumask_bits)
-					new_cpu = first_cpu;
+
+				new_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
 			}
 			/* At this point, we leave the CPU as unassigned */
 			continue;
@@ -12576,9 +12584,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 			 * chance of having multiple unassigned CPU entries
 			 * selecting the same IRQ.
 			 */
-			start_cpu = cpumask_next(new_cpu, cpu_present_mask);
-			if (start_cpu == nr_cpumask_bits)
-				start_cpu = first_cpu;
+			start_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
 
 			lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
 					"3337 Set Affinity: CPU %d "
@@ -12611,10 +12617,8 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 				if (!(new_cpup->flag & LPFC_CPU_MAP_UNASSIGN) &&
 				    (new_cpup->eq != LPFC_VECTOR_MAP_EMPTY))
 					goto found_any;
-				new_cpu = cpumask_next(
-					new_cpu, cpu_present_mask);
-				if (new_cpu == nr_cpumask_bits)
-					new_cpu = first_cpu;
+
+				new_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
 			}
 			/* We should never leave an entry unassigned */
 			lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
@@ -12630,9 +12634,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 			 * chance of having multiple unassigned CPU entries
 			 * selecting the same IRQ.
 			 */
-			start_cpu = cpumask_next(new_cpu, cpu_present_mask);
-			if (start_cpu == nr_cpumask_bits)
-				start_cpu = first_cpu;
+			start_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
 
 			lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
 					"3338 Set Affinity: CPU %d "
@@ -12703,9 +12705,8 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 			    new_cpup->core_id == cpup->core_id) {
 				goto found_hdwq;
 			}
-			new_cpu = cpumask_next(new_cpu, cpu_present_mask);
-			if (new_cpu == nr_cpumask_bits)
-				new_cpu = first_cpu;
+
+			new_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
 		}
 
 		/* If we can't match both phys_id and core_id,
@@ -12718,9 +12719,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 			    new_cpup->phys_id == cpup->phys_id)
 				goto found_hdwq;
 
-			new_cpu = cpumask_next(new_cpu, cpu_present_mask);
-			if (new_cpu == nr_cpumask_bits)
-				new_cpu = first_cpu;
+			new_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
 		}
 
 		/* Otherwise just round robin on cfg_hdw_queue */
@@ -12729,9 +12728,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 		goto logit;
  found_hdwq:
 		/* We found an available entry, copy the IRQ info */
-		start_cpu = cpumask_next(new_cpu, cpu_present_mask);
-		if (start_cpu == nr_cpumask_bits)
-			start_cpu = first_cpu;
+		start_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
 		cpup->hdwq = new_cpup->hdwq;
  logit:
 		lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
-- 
2.34.1


From vernon2gm at gmail.com  Mon Mar  6 21:03:12 2023
From: vernon2gm at gmail.com (Vernon Yang)
Date: Tue,  7 Mar 2023 05:03:12 +0800
Subject: [PATCH v2 4/4] scsi: lpfc: fix lpfc_nvmet_setup_io_context() if no
 further cpus set
In-Reply-To: <20230306210312.2614988-1-vernon2gm@gmail.com>
References: <20230306210312.2614988-1-vernon2gm@gmail.com>
Message-ID: <20230306210312.2614988-5-vernon2gm@gmail.com>

When cpumask_next() the return value is greater than or equal to
nr_cpu_ids, it indicates invalid.

Before commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), when cpumask_next() returned an invalid cpu, the driver
used the judgment equal to nr_cpu_ids to indicate the invalid cpu, so it
happened to work normally, but this is the wrong approach.

After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), these incorrect practices actively buggy, so fix it to
correctly.

Signed-off-by: Vernon Yang <vernon2gm at gmail.com>
---
 drivers/scsi/lpfc/lpfc_nvmet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_nvmet.c b/drivers/scsi/lpfc/lpfc_nvmet.c
index 7517dd55fe91..3ae7f330f827 100644
--- a/drivers/scsi/lpfc/lpfc_nvmet.c
+++ b/drivers/scsi/lpfc/lpfc_nvmet.c
@@ -1621,7 +1621,7 @@ lpfc_nvmet_setup_io_context(struct lpfc_hba *phba)
 			continue;
 		}
 		cpu = cpumask_next(cpu, cpu_present_mask);
-		if (cpu == nr_cpu_ids)
+		if (cpu >= nr_cpu_ids)
 			cpu = cpumask_first(cpu_present_mask);
 
 	}
-- 
2.34.1


From justintee8345 at gmail.com  Wed Mar  8 00:40:28 2023
From: justintee8345 at gmail.com (Justin Tee)
Date: Tue, 7 Mar 2023 16:40:28 -0800
Subject: [PATCH v2 3/4] scsi: lpfc: fix lpfc_cpu_affinity_check() if no
 further cpus set
In-Reply-To: <20230306210312.2614988-4-vernon2gm@gmail.com>
References: <20230306210312.2614988-1-vernon2gm@gmail.com>
 <20230306210312.2614988-4-vernon2gm@gmail.com>
Message-ID: <CABPRKS-DRvmZpoXBTogjEf5Q+oL5GR71nSVRgmVo5vWx-9OQow@mail.gmail.com>

Hi Vernon,

Is it possible to move the new helper routine lpfc_next_present_cpu
into the lpfc.h header file around where lpfc_next_online_cpu is
defined?

Also, with slight modifications we could use the new
lpfc_next_present_cpu helper routine for the
lpfc_nvmet_setup_io_context() patch as well so that we can contain all
lpfc changes within one patch.

---
 drivers/scsi/lpfc/lpfc.h       | 20 ++++++++++++++++++++
 drivers/scsi/lpfc/lpfc_init.c  | 31 +++++++------------------------
 drivers/scsi/lpfc/lpfc_nvmet.c |  5 +----
 3 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index cf55f8e3bd9f..f342d6bc5726 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -1737,6 +1737,26 @@ lpfc_next_online_cpu(const struct cpumask
*mask, unsigned int start)

     return cpu_it;
 }
+
+/**
+ * lpfc_next_present_cpu - Finds next present CPU after n
+ * @n: the cpu prior to search
+ *
+ * Note: If no next present cpu, then fallback to first present cpu.
+ *
+ **/
+static inline unsigned int lpfc_next_present_cpu(int n)
+{
+    unsigned int cpu;
+
+    cpu = cpumask_next(n, cpu_present_mask);
+
+    if (cpu >= nr_cpu_ids)
+        cpu = cpumask_first(cpu_present_mask);
+
+    return cpu;
+}
+
 /**
  * lpfc_sli4_mod_hba_eq_delay - update EQ delay
  * @phba: Pointer to HBA context object.
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 3e1e1d17b2b4..f28af338341f 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -12560,10 +12560,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba
*phba, int vectors)
                     (new_cpup->eq != LPFC_VECTOR_MAP_EMPTY) &&
                     (new_cpup->phys_id == cpup->phys_id))
                     goto found_same;
-                new_cpu = cpumask_next(
-                    new_cpu, cpu_present_mask);
-                if (new_cpu == nr_cpumask_bits)
-                    new_cpu = first_cpu;
+                new_cpu = lpfc_next_present_cpu(new_cpu);
             }
             /* At this point, we leave the CPU as unassigned */
             continue;
@@ -12575,9 +12572,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba,
int vectors)
              * chance of having multiple unassigned CPU entries
              * selecting the same IRQ.
              */
-            start_cpu = cpumask_next(new_cpu, cpu_present_mask);
-            if (start_cpu == nr_cpumask_bits)
-                start_cpu = first_cpu;
+            start_cpu = lpfc_next_present_cpu(new_cpu);

             lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
                     "3337 Set Affinity: CPU %d "
@@ -12610,10 +12605,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba
*phba, int vectors)
                 if (!(new_cpup->flag & LPFC_CPU_MAP_UNASSIGN) &&
                     (new_cpup->eq != LPFC_VECTOR_MAP_EMPTY))
                     goto found_any;
-                new_cpu = cpumask_next(
-                    new_cpu, cpu_present_mask);
-                if (new_cpu == nr_cpumask_bits)
-                    new_cpu = first_cpu;
+                new_cpu = lpfc_next_present_cpu(new_cpu);
             }
             /* We should never leave an entry unassigned */
             lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
@@ -12629,9 +12621,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba,
int vectors)
              * chance of having multiple unassigned CPU entries
              * selecting the same IRQ.
              */
-            start_cpu = cpumask_next(new_cpu, cpu_present_mask);
-            if (start_cpu == nr_cpumask_bits)
-                start_cpu = first_cpu;
+            start_cpu = lpfc_next_present_cpu(new_cpu);

             lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
                     "3338 Set Affinity: CPU %d "
@@ -12702,9 +12692,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba,
int vectors)
                 new_cpup->core_id == cpup->core_id) {
                 goto found_hdwq;
             }
-            new_cpu = cpumask_next(new_cpu, cpu_present_mask);
-            if (new_cpu == nr_cpumask_bits)
-                new_cpu = first_cpu;
+            new_cpu = lpfc_next_present_cpu(new_cpu);
         }

         /* If we can't match both phys_id and core_id,
@@ -12716,10 +12704,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba
*phba, int vectors)
             if (new_cpup->hdwq != LPFC_VECTOR_MAP_EMPTY &&
                 new_cpup->phys_id == cpup->phys_id)
                 goto found_hdwq;
-
-            new_cpu = cpumask_next(new_cpu, cpu_present_mask);
-            if (new_cpu == nr_cpumask_bits)
-                new_cpu = first_cpu;
+            new_cpu = lpfc_next_present_cpu(new_cpu);
         }

         /* Otherwise just round robin on cfg_hdw_queue */
@@ -12728,9 +12713,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba,
int vectors)
         goto logit;
  found_hdwq:
         /* We found an available entry, copy the IRQ info */
-        start_cpu = cpumask_next(new_cpu, cpu_present_mask);
-        if (start_cpu == nr_cpumask_bits)
-            start_cpu = first_cpu;
+        start_cpu = lpfc_next_present_cpu(new_cpu);
         cpup->hdwq = new_cpup->hdwq;
  logit:
         lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
diff --git a/drivers/scsi/lpfc/lpfc_nvmet.c b/drivers/scsi/lpfc/lpfc_nvmet.c
index 7517dd55fe91..2d8ac2ceb6f3 100644
--- a/drivers/scsi/lpfc/lpfc_nvmet.c
+++ b/drivers/scsi/lpfc/lpfc_nvmet.c
@@ -1620,10 +1620,7 @@ lpfc_nvmet_setup_io_context(struct lpfc_hba *phba)
             cpu = cpumask_first(cpu_present_mask);
             continue;
         }
-        cpu = cpumask_next(cpu, cpu_present_mask);
-        if (cpu == nr_cpu_ids)
-            cpu = cpumask_first(cpu_present_mask);
-
+        cpu = lpfc_next_present_cpu(cpu);
     }

     for_each_present_cpu(i) {
-- 
2.38.0

Thanks,
Justin

On Mon, Mar 6, 2023 at 1:10?PM Vernon Yang <vernon2gm at gmail.com> wrote:
>
> When cpumask_next() the return value is greater than or equal to
> nr_cpu_ids, it indicates invalid.
>
> Before commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
> optimizations"), when cpumask_next() returned an invalid cpu, the driver
> used the judgment equal to nr_cpu_ids to indicate the invalid cpu, so it
> happened to work normally, but this is the wrong approach.
>
> After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
> optimizations"), these incorrect practices actively buggy, so fix it to
> correctly.
>
> Signed-off-by: Vernon Yang <vernon2gm at gmail.com>
> ---
>  drivers/scsi/lpfc/lpfc_init.c | 43 ++++++++++++++++-------------------
>  1 file changed, 20 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
> index 61958a24a43d..acfffdbe9ba1 100644
> --- a/drivers/scsi/lpfc/lpfc_init.c
> +++ b/drivers/scsi/lpfc/lpfc_init.c
> @@ -12473,6 +12473,16 @@ lpfc_hba_eq_hdl_array_init(struct lpfc_hba *phba)
>         }
>  }
>
> +static inline int lpfc_next_present_cpu(int n, int first_cpu)
> +{
> +       n = cpumask_next(n, cpu_present_mask);
> +
> +       if (n >= nr_cpu_ids)
> +               n = first_cpu;
> +
> +       return n;
> +}
> +
>  /**
>   * lpfc_cpu_affinity_check - Check vector CPU affinity mappings
>   * @phba: pointer to lpfc hba data structure.
> @@ -12561,10 +12571,8 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
>                                     (new_cpup->eq != LPFC_VECTOR_MAP_EMPTY) &&
>                                     (new_cpup->phys_id == cpup->phys_id))
>                                         goto found_same;
> -                               new_cpu = cpumask_next(
> -                                       new_cpu, cpu_present_mask);
> -                               if (new_cpu == nr_cpumask_bits)
> -                                       new_cpu = first_cpu;
> +
> +                               new_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
>                         }
>                         /* At this point, we leave the CPU as unassigned */
>                         continue;
> @@ -12576,9 +12584,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
>                          * chance of having multiple unassigned CPU entries
>                          * selecting the same IRQ.
>                          */
> -                       start_cpu = cpumask_next(new_cpu, cpu_present_mask);
> -                       if (start_cpu == nr_cpumask_bits)
> -                               start_cpu = first_cpu;
> +                       start_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
>
>                         lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
>                                         "3337 Set Affinity: CPU %d "
> @@ -12611,10 +12617,8 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
>                                 if (!(new_cpup->flag & LPFC_CPU_MAP_UNASSIGN) &&
>                                     (new_cpup->eq != LPFC_VECTOR_MAP_EMPTY))
>                                         goto found_any;
> -                               new_cpu = cpumask_next(
> -                                       new_cpu, cpu_present_mask);
> -                               if (new_cpu == nr_cpumask_bits)
> -                                       new_cpu = first_cpu;
> +
> +                               new_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
>                         }
>                         /* We should never leave an entry unassigned */
>                         lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
> @@ -12630,9 +12634,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
>                          * chance of having multiple unassigned CPU entries
>                          * selecting the same IRQ.
>                          */
> -                       start_cpu = cpumask_next(new_cpu, cpu_present_mask);
> -                       if (start_cpu == nr_cpumask_bits)
> -                               start_cpu = first_cpu;
> +                       start_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
>
>                         lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
>                                         "3338 Set Affinity: CPU %d "
> @@ -12703,9 +12705,8 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
>                             new_cpup->core_id == cpup->core_id) {
>                                 goto found_hdwq;
>                         }
> -                       new_cpu = cpumask_next(new_cpu, cpu_present_mask);
> -                       if (new_cpu == nr_cpumask_bits)
> -                               new_cpu = first_cpu;
> +
> +                       new_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
>                 }
>
>                 /* If we can't match both phys_id and core_id,
> @@ -12718,9 +12719,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
>                             new_cpup->phys_id == cpup->phys_id)
>                                 goto found_hdwq;
>
> -                       new_cpu = cpumask_next(new_cpu, cpu_present_mask);
> -                       if (new_cpu == nr_cpumask_bits)
> -                               new_cpu = first_cpu;
> +                       new_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
>                 }
>
>                 /* Otherwise just round robin on cfg_hdw_queue */
> @@ -12729,9 +12728,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
>                 goto logit;
>   found_hdwq:
>                 /* We found an available entry, copy the IRQ info */
> -               start_cpu = cpumask_next(new_cpu, cpu_present_mask);
> -               if (start_cpu == nr_cpumask_bits)
> -                       start_cpu = first_cpu;
> +               start_cpu = lpfc_next_present_cpu(new_cpu, first_cpu);
>                 cpup->hdwq = new_cpup->hdwq;
>   logit:
>                 lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
> --
> 2.34.1
>

From regressions at leemhuis.info  Fri Mar 10 10:21:45 2023
From: regressions at leemhuis.info (Linux regression tracking (Thorsten Leemhuis))
Date: Fri, 10 Mar 2023 11:21:45 +0100
Subject: Possible regression between 5.18.2 and 6.2.1
In-Reply-To: <CQZ7HWJCK18F.1AUR9FMHKPOXB@crawfs>
References: <CQZ7HWJCK18F.1AUR9FMHKPOXB@crawfs>
Message-ID: <4d4f0a83-180b-ffbe-72bf-718c4db62b39@leemhuis.info>

[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]

[Also adding Jason to the list of recipients, as I'm not sure how
closely he follows the lists]

[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]

On 06.03.23 10:51, Dan Crawford wrote:
> I recently updated a server from kernel version 5.18.2 to 6.2.1 and
> discovered that WG clients could no longer connect; there were no
> changes to configs. Reverting to 5.18.2 resolves the issue.
> 
> My server config looks something like
> 
> [Interface]
> Address = 192.168.1.0/24
> ListenPort = 51820
> PrivateKey = XXX
> PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
> 
> [Peer]
> PublicKey = XXX
> AllowedIPs = 192.168.1.3/32
> 
> and my client config looks something like
> 
> 
> [Interface]
> Address = 192.168.1.3/32
> DNS = 1.1.1.1
> PrivateKey = XXX
> 
> [Peer]
> AllowedIPs = 0.0.0.0/0
> Endpoint = example.com:51820
> PublicKey = XXX
> 
> On the server I get mysterious "packet has unallowed src ip" errors.
> Playing around with various combinations of subnets and iptables
> invocations doesn't seem to help. Was there a change to the config spec
> that I missed? Or otherwise any other ideas what might be going on?

Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:

#regzbot ^introduced v5.18..v6.2
#regzbot title net: wireguard: clients can no longer connect
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.

Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.

From ashish.is at lostca.se  Fri Mar 17 19:43:53 2023
From: ashish.is at lostca.se (Ashish SHUKLA)
Date: Sat, 18 Mar 2023 01:13:53 +0530
Subject: Force a specific IP for outgoing WG traffic with SNAT?
In-Reply-To: <20230217000747.0825b2e9@nvm>
References: <20230217000747.0825b2e9@nvm>
Message-ID: <e4f7dc477cd14e14a75e304878e6cb05@lostca.se>

On 2023-02-17 00:37, Roman Mamedov wrote:
> Hello,
> 
> I'm trying to move all my WG communication with peers to a non-primary
> IP of my server.
> 
> It has IPs added like this:
> 
>     inet6 2001:db8::ca6c/128 scope global deprecated
>        valid_lft forever preferred_lft 0sec
>     inet6 2001:db8::1/128 scope global nodad
>        valid_lft forever preferred_lft forever
> 
> What I tried:
> 
>   ip6tables -t nat -I POSTROUTING -d 2000::/3 -p udp --dport 51820 -j
> SNAT --to-source 2001:db8::ca6c
> 
> Also tried to filter by --sport, and also briefly without a port filter 
> at all.
> 
> This has zero effect, as shown by tcpdump all the WG traffic still
> originates from 2001:db8::1
> 
> Does anyone have an idea why is that? Thanks

Did you try filtering based on fwmark ?

     CONFIGURATION FILE FORMAT
            The configuration file format is based on INI. There are two 
top level sections -- Interface and Peer. Multiple Peer sections may be 
specified, but only one Interface section may be specified.

            The Interface section may contain the following fields:

            ?      PrivateKey ? a base64 private key generated by wg 
genkey. Required.

            ?      ListenPort ? a 16-bit port for listening. Optional; if 
not specified, chosen randomly.

            ?      FwMark ? a 32-bit fwmark for outgoing packets. If set 
to 0 or "off", this option is disabled. May be specified in hexadecimal 
by prepending "0x". Optional.

HTH
-- 
Ashish

"It could be that the purpose of your life is only to serve as a warning 
to others." (Ashleigh Brilliant)

From rm at romanrm.net  Fri Mar 17 19:54:51 2023
From: rm at romanrm.net (Roman Mamedov)
Date: Sat, 18 Mar 2023 00:54:51 +0500
Subject: Force a specific IP for outgoing WG traffic with SNAT?
In-Reply-To: <e4f7dc477cd14e14a75e304878e6cb05@lostca.se>
References: <20230217000747.0825b2e9@nvm>
 <e4f7dc477cd14e14a75e304878e6cb05@lostca.se>
Message-ID: <20230318005451.7212e6c9@nvm>

On Sat, 18 Mar 2023 01:13:53 +0530
Ashish SHUKLA <ashish.is at lostca.se> wrote:

> Did you try filtering based on fwmark ?
> 
>      CONFIGURATION FILE FORMAT
>             The configuration file format is based on INI. There are two 
> top level sections -- Interface and Peer. Multiple Peer sections may be 
> specified, but only one Interface section may be specified.
> 
>             The Interface section may contain the following fields:
> 
>             ?      PrivateKey ? a base64 private key generated by wg 
> genkey. Required.
> 
>             ?      ListenPort ? a 16-bit port for listening. Optional; if 
> not specified, chosen randomly.
> 
>             ?      FwMark ? a 32-bit fwmark for outgoing packets. If set 
> to 0 or "off", this option is disabled. May be specified in hexadecimal 
> by prepending "0x". Optional.

I was not aware there was such an option. For now the task described in the
original message is no longer required, I will try fwmark next time when it
might be. Thanks!

-- 
With respect,
Roman

From dseliv at gmail.com  Sun Mar 19 16:43:57 2023
From: dseliv at gmail.com (Dmitry Selivanov)
Date: Sun, 19 Mar 2023 19:43:57 +0300
Subject: [PATCH] wg-quick: add possibility to force use userspace
 implementation
Message-ID: <316d48cc-6abc-ede1-5344-26fb81d19439@gmail.com>

This patch allows to use userspace implementation with 
"WG_QUICK_USERSPACE_IMPLEMENTATION" env variable even if kernel
driver is installed. Quotes around program name are removed 
to run like this:
WG_QUICK_USERSPACE_IMPLEMENTATION="setfib 1 wireguard-go" wg-quick up wg0
on FreeBSD or with "ip netns exec" on Linux. This can move
wireguard traffic to non-default routing table or namespace.

Signed-off-by: Dmitry Selivanov <dseliv at gmail.com>
---
 src/wg-quick/freebsd.bash | 6 +++++-
 src/wg-quick/linux.bash   | 8 ++++++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/src/wg-quick/freebsd.bash b/src/wg-quick/freebsd.bash
index b529ab2..663af48 100755
--- a/src/wg-quick/freebsd.bash
+++ b/src/wg-quick/freebsd.bash
@@ -116,6 +116,10 @@ auto_su() {
 
 add_if() {
 	local ret rc
+	if [[ -n $WG_QUICK_USERSPACE_IMPLEMENTATION ]]; then
+		cmd $WG_QUICK_USERSPACE_IMPLEMENTATION "$INTERFACE"
+		return
+	fi
 	if ret="$(cmd ifconfig wg create name "$INTERFACE" 2>&1 >/dev/null)"; then
 		return 0
 	fi
@@ -125,7 +129,7 @@ add_if() {
 		return $rc
 	fi
 	echo "[!] Missing WireGuard kernel support ($ret). Falling back to slow userspace implementation." >&3
-	cmd "${WG_QUICK_USERSPACE_IMPLEMENTATION:-wireguard-go}" "$INTERFACE"
+	cmd wireguard-go "$INTERFACE"
 }
 
 del_routes() {
diff --git a/src/wg-quick/linux.bash b/src/wg-quick/linux.bash
index 69e5bef..a883df9 100755
--- a/src/wg-quick/linux.bash
+++ b/src/wg-quick/linux.bash
@@ -87,11 +87,15 @@ auto_su() {
 
 add_if() {
 	local ret
+	if [[ -n $WG_QUICK_USERSPACE_IMPLEMENTATION ]]; then
+		cmd $WG_QUICK_USERSPACE_IMPLEMENTATION "$INTERFACE"
+		return
+	fi
 	if ! cmd ip link add "$INTERFACE" type wireguard; then
 		ret=$?
-		[[ -e /sys/module/wireguard ]] || ! command -v "${WG_QUICK_USERSPACE_IMPLEMENTATION:-wireguard-go}" >/dev/null && exit $ret
+		[[ -e /sys/module/wireguard ]] || ! command -v "wireguard-go" >/dev/null && exit $ret
 		echo "[!] Missing WireGuard kernel module. Falling back to slow userspace implementation." >&2
-		cmd "${WG_QUICK_USERSPACE_IMPLEMENTATION:-wireguard-go}" "$INTERFACE"
+		cmd wireguard-go "$INTERFACE"
 	fi
 }
 
-- 
2.30.2


From sashal at kernel.org  Mon Mar 20 00:52:34 2023
From: sashal at kernel.org (Sasha Levin)
Date: Sun, 19 Mar 2023 20:52:34 -0400
Subject: [PATCH AUTOSEL 6.2 09/30] cpumask: fix incorrect cpumask scanning
 result checks
In-Reply-To: <20230320005258.1428043-1-sashal@kernel.org>
References: <20230320005258.1428043-1-sashal@kernel.org>
Message-ID: <20230320005258.1428043-9-sashal@kernel.org>

From: Linus Torvalds <torvalds at linux-foundation.org>

[ Upstream commit 8ca09d5fa3549d142c2080a72a4c70ce389163cd ]

It turns out that commit 596ff4a09b89 ("cpumask: re-introduce
constant-sized cpumask optimizations") exposed a number of cases of
drivers not checking the result of "cpumask_next()" and friends
correctly.

The documented correct check for "no more cpus in the cpumask" is to
check for the result being equal or larger than the number of possible
CPU ids, exactly _because_ we've always done those constant-sized
cpumask scans using a widened type before.  So the return value of a
cpumask scan should be checked with

	if (cpu >= nr_cpu_ids)
		...

because the cpumask scan did not necessarily stop exactly *at* that
maximum CPU id.

But a few cases ended up instead using checks like

	if (cpu == nr_cpumask_bits)
		...

which used that internal "widened" number of bits.  And that used to
work pretty much by accident (ok, in this case "by accident" is simply
because it matched the historical internal implementation of the cpumask
scanning, so it was more of a "intentionally using implementation
details rather than an accident").

But the extended constant-sized optimizations then did that internal
implementation differently, and now that code that did things wrong but
matched the old implementation no longer worked at all.

Which then causes subsequent odd problems due to using what ends up
being an invalid CPU ID.

Most of these cases require either unusual hardware or special uses to
hit, but the random.c one triggers quite easily.

All you really need is to have a sufficiently small CONFIG_NR_CPUS value
for the bit scanning optimization to be triggered, but not enough CPUs
to then actually fill that widened cpumask.  At that point, the cpumask
scanning will return the NR_CPUS constant, which is _not_ the same as
nr_cpumask_bits.

This just does the mindless fix with

   sed -i 's/== nr_cpumask_bits/>= nr_cpu_ids/'

to fix the incorrect uses.

The ones in the SCSI lpfc driver in particular could probably be fixed
more cleanly by just removing that repeated pattern entirely, but I am
not emptionally invested enough in that driver to care.

Reported-and-tested-by: Guenter Roeck <linux at roeck-us.net>
Link: https://lore.kernel.org/lkml/481b19b5-83a0-4793-b4fd-194ad7b978c3 at roeck-us.net/
Reported-and-tested-by: Geert Uytterhoeven <geert+renesas at glider.be>
Link: https://lore.kernel.org/lkml/CAMuHMdUKo_Sf7TjKzcNDa8Ve+6QrK+P8nSQrSQ=6LTRmcBKNww at mail.gmail.com/
Reported-by: Vernon Yang <vernon2gm at gmail.com>
Link: https://lore.kernel.org/lkml/20230306160651.2016767-1-vernon2gm at gmail.com/
Cc: Yury Norov <yury.norov at gmail.com>
Cc: Jason A. Donenfeld <Jason at zx2c4.com>
Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/powerpc/xmon/xmon.c         |  2 +-
 drivers/char/random.c            |  2 +-
 drivers/net/wireguard/queueing.h |  2 +-
 drivers/scsi/lpfc/lpfc_init.c    | 14 +++++++-------
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 0da66bc4823d4..3b4e2475fc4ef 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1277,7 +1277,7 @@ static int xmon_batch_next_cpu(void)
 	while (!cpumask_empty(&xmon_batch_cpus)) {
 		cpu = cpumask_next_wrap(smp_processor_id(), &xmon_batch_cpus,
 					xmon_batch_start_cpu, true);
-		if (cpu == nr_cpumask_bits)
+		if (cpu >= nr_cpu_ids)
 			break;
 		if (xmon_batch_start_cpu == -1)
 			xmon_batch_start_cpu = cpu;
diff --git a/drivers/char/random.c b/drivers/char/random.c
index ce3ccd172cc86..253f2ddb89130 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1311,7 +1311,7 @@ static void __cold try_to_generate_entropy(void)
 			/* Basic CPU round-robin, which avoids the current CPU. */
 			do {
 				cpu = cpumask_next(cpu, &timer_cpus);
-				if (cpu == nr_cpumask_bits)
+				if (cpu >= nr_cpu_ids)
 					cpu = cpumask_first(&timer_cpus);
 			} while (cpu == smp_processor_id() && num_cpus > 1);
 
diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h
index 583adb37ee1e3..125284b346a77 100644
--- a/drivers/net/wireguard/queueing.h
+++ b/drivers/net/wireguard/queueing.h
@@ -106,7 +106,7 @@ static inline int wg_cpumask_choose_online(int *stored_cpu, unsigned int id)
 {
 	unsigned int cpu = *stored_cpu, cpu_index, i;
 
-	if (unlikely(cpu == nr_cpumask_bits ||
+	if (unlikely(cpu >= nr_cpu_ids ||
 		     !cpumask_test_cpu(cpu, cpu_online_mask))) {
 		cpu_index = id % cpumask_weight(cpu_online_mask);
 		cpu = cpumask_first(cpu_online_mask);
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 25ba20e428255..3fbd3bec26fc1 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -12507,7 +12507,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 					goto found_same;
 				new_cpu = cpumask_next(
 					new_cpu, cpu_present_mask);
-				if (new_cpu == nr_cpumask_bits)
+				if (new_cpu >= nr_cpu_ids)
 					new_cpu = first_cpu;
 			}
 			/* At this point, we leave the CPU as unassigned */
@@ -12521,7 +12521,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 			 * selecting the same IRQ.
 			 */
 			start_cpu = cpumask_next(new_cpu, cpu_present_mask);
-			if (start_cpu == nr_cpumask_bits)
+			if (start_cpu >= nr_cpu_ids)
 				start_cpu = first_cpu;
 
 			lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
@@ -12557,7 +12557,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 					goto found_any;
 				new_cpu = cpumask_next(
 					new_cpu, cpu_present_mask);
-				if (new_cpu == nr_cpumask_bits)
+				if (new_cpu >= nr_cpu_ids)
 					new_cpu = first_cpu;
 			}
 			/* We should never leave an entry unassigned */
@@ -12575,7 +12575,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 			 * selecting the same IRQ.
 			 */
 			start_cpu = cpumask_next(new_cpu, cpu_present_mask);
-			if (start_cpu == nr_cpumask_bits)
+			if (start_cpu >= nr_cpu_ids)
 				start_cpu = first_cpu;
 
 			lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
@@ -12648,7 +12648,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 				goto found_hdwq;
 			}
 			new_cpu = cpumask_next(new_cpu, cpu_present_mask);
-			if (new_cpu == nr_cpumask_bits)
+			if (new_cpu >= nr_cpu_ids)
 				new_cpu = first_cpu;
 		}
 
@@ -12663,7 +12663,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
 				goto found_hdwq;
 
 			new_cpu = cpumask_next(new_cpu, cpu_present_mask);
-			if (new_cpu == nr_cpumask_bits)
+			if (new_cpu >= nr_cpu_ids)
 				new_cpu = first_cpu;
 		}
 
@@ -12674,7 +12674,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba *phba, int vectors)
  found_hdwq:
 		/* We found an available entry, copy the IRQ info */
 		start_cpu = cpumask_next(new_cpu, cpu_present_mask);
-		if (start_cpu == nr_cpumask_bits)
+		if (start_cpu >= nr_cpu_ids)
 			start_cpu = first_cpu;
 		cpup->hdwq = new_cpup->hdwq;
  logit:
-- 
2.39.2


From torvalds at linux-foundation.org  Mon Mar 20 01:59:07 2023
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Sun, 19 Mar 2023 18:59:07 -0700
Subject: [PATCH AUTOSEL 6.2 09/30] cpumask: fix incorrect cpumask scanning
 result checks
In-Reply-To: <20230320005258.1428043-9-sashal@kernel.org>
References: <20230320005258.1428043-1-sashal@kernel.org>
 <20230320005258.1428043-9-sashal@kernel.org>
Message-ID: <CAHk-=wgpK-Gm-nOybRKs1LTD5yb7rPHQ4+=PCDvq61mUpBskYw@mail.gmail.com>

On Sun, Mar 19, 2023 at 5:53?PM Sasha Levin <sashal at kernel.org> wrote:
>
> [ Upstream commit 8ca09d5fa3549d142c2080a72a4c70ce389163cd ]

These are technically real fixes, but they are really just "documented
behavior" fixes, and don't actually matter unless you also have
596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask
optimizations"), which doesn't look like stable material.

And if somebody *does* decide to backport commit 596ff4a09b89, you
should then backport all of

  6015b1aca1a2 sched_getaffinity: don't assume 'cpumask_size()' is
fully initialized
  e7304080e0e5 cpumask: relax sanity checking constraints
  63355b9884b3 cpumask: be more careful with 'cpumask_setall()'
  8ca09d5fa354 cpumask: fix incorrect cpumask scanning result checks

but again, none of these matter as long as the constant-sized cpumask
optimized case doesn't exist.

(Technically, FORCE_NR_CPUS also does the constant-size optimizations
even before, but that will complain loudly if that constant size then
doesn't match nr_cpu_ids, so ..).

                   Linus

From lsc at lv6.tw  Thu Mar 23 09:01:42 2023
From: lsc at lv6.tw (lsc)
Date: Thu, 23 Mar 2023 17:01:42 +0800
Subject: wireguard-go: data race introduced in recent commit 9e2f386
Message-ID: <ac87f86f-6837-4e0e-ec34-1df35f52540e@lv6.tw>

Hi,

Not sure if this is the correct place for bug reports, hope it's okay :)

I found my wireguard-go server (built from current ToT 1417a47) always 
panicking when I ran speedtest on a client via the server. I rebuilt the 
server with data race detector (`go build -race`) and got the following 
trace:

==================
WARNING: DATA RACE
Read at 0x00c00043b2f8 by goroutine 49:
   golang.zx2c4.com/wireguard/conn.setSrcControl()
       /home/lsc36/wireguard-go/conn/sticky_linux.go:76 +0x8c
   golang.zx2c4.com/wireguard/conn.(*StdNetBind).send4()
       /home/lsc36/wireguard-go/conn/bind_std.go:346 +0x174
   golang.zx2c4.com/wireguard/conn.(*StdNetBind).Send()
       /home/lsc36/wireguard-go/conn/bind_std.go:332 +0x1d4
   golang.zx2c4.com/wireguard/device.(*Peer).SendBuffers()
       /home/lsc36/wireguard-go/device/peer.go:126 +0x18c
   golang.zx2c4.com/wireguard/device.(*Peer).RoutineSequentialSender()
       /home/lsc36/wireguard-go/device/send.go:519 +0x458
   golang.zx2c4.com/wireguard/device.(*Peer).Start.func2()
       /home/lsc36/wireguard-go/device/peer.go:198 +0x40

Previous write at 0x00c00043b2f8 by goroutine 47:
   golang.zx2c4.com/wireguard/conn.(*StdNetEndpoint).ClearSrc()
       /home/lsc36/wireguard-go/conn/bind_std.go:100 +0x48
   golang.zx2c4.com/wireguard/conn.getSrcFromControl()
       /home/lsc36/wireguard-go/conn/sticky_linux.go:18 +0x3c
   golang.zx2c4.com/wireguard/conn.(*StdNetBind).makeReceiveIPv4.func1()
       /home/lsc36/wireguard-go/conn/bind_std.go:232 +0x350
   golang.zx2c4.com/wireguard/device.(*Device).RoutineReceiveIncoming()
       /home/lsc36/wireguard-go/device/receive.go:107 +0x3ac
   golang.zx2c4.com/wireguard/device.(*Device).BindUpdate.func3()
       /home/lsc36/wireguard-go/device/device.go:530 +0x4c

Goroutine 49 (running) created at:
   golang.zx2c4.com/wireguard/device.(*Peer).Start()
       /home/lsc36/wireguard-go/device/peer.go:198 +0x300
   golang.zx2c4.com/wireguard/device.(*ipcSetPeer).handlePostConfig()
       /home/lsc36/wireguard-go/device/uapi.go:268 +0x164
   golang.zx2c4.com/wireguard/device.(*Device).IpcSetOperation()
       /home/lsc36/wireguard-go/device/uapi.go:160 +0x35c
   golang.zx2c4.com/wireguard/device.(*Device).IpcHandle()
       /home/lsc36/wireguard-go/device/uapi.go:428 +0x248
   main.main.func4.1()
       /home/lsc36/wireguard-go/main.go:245 +0x4c

Goroutine 47 (running) created at:
   golang.zx2c4.com/wireguard/device.(*Device).BindUpdate()
       /home/lsc36/wireguard-go/device/device.go:530 +0x4b8
   golang.zx2c4.com/wireguard/device.(*Device).handleDeviceLine()
       /home/lsc36/wireguard-go/device/uapi.go:223 +0x45c
   golang.zx2c4.com/wireguard/device.(*Device).IpcSetOperation()
       /home/lsc36/wireguard-go/device/uapi.go:183 +0x210
   golang.zx2c4.com/wireguard/device.(*Device).IpcHandle()
       /home/lsc36/wireguard-go/device/uapi.go:428 +0x248
   main.main.func4.1()
       /home/lsc36/wireguard-go/main.go:245 +0x4c
==================

The bug looks introduced by a recent commit 9e2f386 "conn, device, tun: 
implement vectorized I/O on Linux". Without much knowledge to the 
codebase, it seems to me that Endpoint is supposed to be guarded by the 
RWMutex embedded in Peer, yet the change introduced a write without 
locking the mutex (`ep.ClearSrc()` called from sticky_linux.go:18).

In addition, I found it weird that Endpoint objects are reused via 
`endpointPool`. The docstring suggests "Endpoints are immutable, so we 
can re-use them" but that doesn't seem true.

Added authors/reviewers of 9e2f386 to cc. Would you take a look?

Regards,
SC


From Jason at zx2c4.com  Thu Mar 23 14:19:57 2023
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 23 Mar 2023 15:19:57 +0100
Subject: [PATCH android] ui: set selected tunnel after creating fragments
Message-ID: <20230323141957.3200896-1-Jason@zx2c4.com>

I'm not sure why that comment (Samuel's) was there saying it was
necessary. Given it's been async for a long while, this wasn't
guaranteed anyway. So let's get rid of it and see what happens. Screen
rotation seems fine thus far.

Cc: Samuel Holland <samuel at sholland.org>
Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
---
Samuel -- CC'ing this to you in case you remember anything.

 .../com/wireguard/android/activity/BaseActivity.kt    | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/ui/src/main/java/com/wireguard/android/activity/BaseActivity.kt b/ui/src/main/java/com/wireguard/android/activity/BaseActivity.kt
index 204a5a80..8f0855ea 100644
--- a/ui/src/main/java/com/wireguard/android/activity/BaseActivity.kt
+++ b/ui/src/main/java/com/wireguard/android/activity/BaseActivity.kt
@@ -7,9 +7,7 @@ package com.wireguard.android.activity
 import android.os.Bundle
 import androidx.databinding.CallbackRegistry
 import androidx.databinding.CallbackRegistry.NotifierCallback
-import androidx.lifecycle.Lifecycle
 import androidx.lifecycle.lifecycleScope
-import androidx.lifecycle.repeatOnLifecycle
 import com.wireguard.android.Application
 import com.wireguard.android.model.ObservableTunnel
 import kotlinx.coroutines.launch
@@ -33,6 +31,8 @@ abstract class BaseActivity : ThemeChangeAwareActivity() {
     }
 
     override fun onCreate(savedInstanceState: Bundle?) {
+        super.onCreate(savedInstanceState)
+
         // Restore the saved tunnel if there is one; otherwise grab it from the arguments.
         val savedTunnelName = when {
             savedInstanceState != null -> savedInstanceState.getString(KEY_SELECTED_TUNNEL)
@@ -41,13 +41,8 @@ abstract class BaseActivity : ThemeChangeAwareActivity() {
         }
         if (savedTunnelName != null)
             lifecycleScope.launch {
-                repeatOnLifecycle(Lifecycle.State.CREATED) {
-                    selectedTunnel = Application.getTunnelManager().getTunnels()[savedTunnelName]
-                }
+                selectedTunnel = Application.getTunnelManager().getTunnels()[savedTunnelName]
             }
-
-        // The selected tunnel must be set before the superclass method recreates fragments.
-        super.onCreate(savedInstanceState)
     }
 
     override fun onSaveInstanceState(outState: Bundle) {
-- 
2.40.0


From gabriel at augendre.info  Thu Mar 16 16:58:45 2023
From: gabriel at augendre.info (Gabriel Augendre)
Date: Thu, 16 Mar 2023 17:58:45 +0100
Subject: macOS on-demand Wi-Fi space at the beginning of SSID doesn't work as
 expected
Message-ID: <8DFC7AF6-8476-421B-93BC-766C6714E178@augendre.info>

Hello,

I hope this is the right place to submit what, in my opinion, is a bug.

I'm using Wireguard on macOS, installed from the App Store[1].
App version: 1.0.16 (27)
Go backend version: 1e2c3e5a

[1]: https://apps.apple.com/fr/app/wireguard/id1451685025?mt=12

I'm unable to add an SSID starting with a space in the on-demand except/only configuration. The app strips the whitespace at the beginning of the SSID.

Steps to reproduce:
1. Install WireGuard
2. Setup a tunnel
3. Enable On-Demand Wi-Fi
4. Select "Only these SSIDs" or "Except these SSIDs"
5. Type an SSID name starting with a space
6. Type Enter or Tab to validate the selection

Notice how the space at the beginning of the SSID has disappeared in the text box. Also, the configuration treats the SSID with no space at the beginning. If you opted for "only" this SSID and you're connected to it, then WireGuard won't connect. If you selected "except", then WireGuard will connect anyway.

The iOS app doesn't seem affected by this bug. Selecting a known SSID starting with a space works as expected.

I'd be glad to contribute a patch but I have no experience in Swift programming.
I'm guessing the issue lies somewhere in Sources/WireGuardApp/UI/ActivateOnDemandViewModel.swift though.

Regards,

-- 
Gabriel Augendre


From gabriel at augendre.info  Thu Mar 16 17:08:11 2023
From: gabriel at augendre.info (Gabriel Augendre)
Date: Thu, 16 Mar 2023 18:08:11 +0100
Subject: String tunnelListCaptionOnDemand missing translation in iOS
Message-ID: <CB3C1986-2AA8-4B72-9E18-FBF586C9A651@augendre.info>

Hello,

When trying to enable On-Demand in iOS, I found a string missing translations.
A screenshot is available here: https://cloud.augendre.info/s/pCFWiLDZBf8w6Fo
It only appears like this on non-English languages. Switching the OS or the app to English displays "On-Demand".

The string label is "tunnelListCaptionOnDemand".

Regards,

-- 
Gabriel Augendre


From jordan at tailscale.com  Thu Mar 23 17:00:19 2023
From: jordan at tailscale.com (Jordan Whited)
Date: Thu, 23 Mar 2023 10:00:19 -0700
Subject: wireguard-go: data race introduced in recent commit 9e2f386
In-Reply-To: <ac87f86f-6837-4e0e-ec34-1df35f52540e@lv6.tw>
References: <ac87f86f-6837-4e0e-ec34-1df35f52540e@lv6.tw>
Message-ID: <CABprzAaZC86FosOK7A__LB7LzULLYv=-y539y5VHacttYJwSmg@mail.gmail.com>

SC, thank you for reporting. Do you happen to have a stack trace from
one of the panics?

On Thu, Mar 23, 2023 at 2:01?AM lsc <lsc at lv6.tw> wrote:
>
> Hi,
>
> Not sure if this is the correct place for bug reports, hope it's okay :)
>
> I found my wireguard-go server (built from current ToT 1417a47) always
> panicking when I ran speedtest on a client via the server. I rebuilt the
> server with data race detector (`go build -race`) and got the following
> trace:
>
> ==================
> WARNING: DATA RACE
> Read at 0x00c00043b2f8 by goroutine 49:
>    golang.zx2c4.com/wireguard/conn.setSrcControl()
>        /home/lsc36/wireguard-go/conn/sticky_linux.go:76 +0x8c
>    golang.zx2c4.com/wireguard/conn.(*StdNetBind).send4()
>        /home/lsc36/wireguard-go/conn/bind_std.go:346 +0x174
>    golang.zx2c4.com/wireguard/conn.(*StdNetBind).Send()
>        /home/lsc36/wireguard-go/conn/bind_std.go:332 +0x1d4
>    golang.zx2c4.com/wireguard/device.(*Peer).SendBuffers()
>        /home/lsc36/wireguard-go/device/peer.go:126 +0x18c
>    golang.zx2c4.com/wireguard/device.(*Peer).RoutineSequentialSender()
>        /home/lsc36/wireguard-go/device/send.go:519 +0x458
>    golang.zx2c4.com/wireguard/device.(*Peer).Start.func2()
>        /home/lsc36/wireguard-go/device/peer.go:198 +0x40
>
> Previous write at 0x00c00043b2f8 by goroutine 47:
>    golang.zx2c4.com/wireguard/conn.(*StdNetEndpoint).ClearSrc()
>        /home/lsc36/wireguard-go/conn/bind_std.go:100 +0x48
>    golang.zx2c4.com/wireguard/conn.getSrcFromControl()
>        /home/lsc36/wireguard-go/conn/sticky_linux.go:18 +0x3c
>    golang.zx2c4.com/wireguard/conn.(*StdNetBind).makeReceiveIPv4.func1()
>        /home/lsc36/wireguard-go/conn/bind_std.go:232 +0x350
>    golang.zx2c4.com/wireguard/device.(*Device).RoutineReceiveIncoming()
>        /home/lsc36/wireguard-go/device/receive.go:107 +0x3ac
>    golang.zx2c4.com/wireguard/device.(*Device).BindUpdate.func3()
>        /home/lsc36/wireguard-go/device/device.go:530 +0x4c
>
> Goroutine 49 (running) created at:
>    golang.zx2c4.com/wireguard/device.(*Peer).Start()
>        /home/lsc36/wireguard-go/device/peer.go:198 +0x300
>    golang.zx2c4.com/wireguard/device.(*ipcSetPeer).handlePostConfig()
>        /home/lsc36/wireguard-go/device/uapi.go:268 +0x164
>    golang.zx2c4.com/wireguard/device.(*Device).IpcSetOperation()
>        /home/lsc36/wireguard-go/device/uapi.go:160 +0x35c
>    golang.zx2c4.com/wireguard/device.(*Device).IpcHandle()
>        /home/lsc36/wireguard-go/device/uapi.go:428 +0x248
>    main.main.func4.1()
>        /home/lsc36/wireguard-go/main.go:245 +0x4c
>
> Goroutine 47 (running) created at:
>    golang.zx2c4.com/wireguard/device.(*Device).BindUpdate()
>        /home/lsc36/wireguard-go/device/device.go:530 +0x4b8
>    golang.zx2c4.com/wireguard/device.(*Device).handleDeviceLine()
>        /home/lsc36/wireguard-go/device/uapi.go:223 +0x45c
>    golang.zx2c4.com/wireguard/device.(*Device).IpcSetOperation()
>        /home/lsc36/wireguard-go/device/uapi.go:183 +0x210
>    golang.zx2c4.com/wireguard/device.(*Device).IpcHandle()
>        /home/lsc36/wireguard-go/device/uapi.go:428 +0x248
>    main.main.func4.1()
>        /home/lsc36/wireguard-go/main.go:245 +0x4c
> ==================
>
> The bug looks introduced by a recent commit 9e2f386 "conn, device, tun:
> implement vectorized I/O on Linux". Without much knowledge to the
> codebase, it seems to me that Endpoint is supposed to be guarded by the
> RWMutex embedded in Peer, yet the change introduced a write without
> locking the mutex (`ep.ClearSrc()` called from sticky_linux.go:18).
>
> In addition, I found it weird that Endpoint objects are reused via
> `endpointPool`. The docstring suggests "Endpoints are immutable, so we
> can re-use them" but that doesn't seem true.
>
> Added authors/reviewers of 9e2f386 to cc. Would you take a look?
>
> Regards,
> SC
>

From lsc at lv6.tw  Fri Mar 24 03:21:52 2023
From: lsc at lv6.tw (lsc)
Date: Fri, 24 Mar 2023 11:21:52 +0800
Subject: wireguard-go: data race introduced in recent commit 9e2f386
In-Reply-To: <CABprzAaZC86FosOK7A__LB7LzULLYv=-y539y5VHacttYJwSmg@mail.gmail.com>
References: <ac87f86f-6837-4e0e-ec34-1df35f52540e@lv6.tw>
 <CABprzAaZC86FosOK7A__LB7LzULLYv=-y539y5VHacttYJwSmg@mail.gmail.com>
Message-ID: <18b4903b-0835-ac5e-49ca-ae6bea08a268@lv6.tw>

Sure, here's the trace:

--
DEBUG: (wg1) 2023/03/22 23:46:39 peer(Suxf?6dEI) - Routine: sequential sender - stopped
panic: As4 called on IP zero value

goroutine 70 [running]:
net/netip.Addr.As4({{0xc0048b1200?, 0xc00058bb28?}, 0x0?})
        /opt/go1.20.2.linux-arm64/src/net/netip/netip.go:690 +0x174
golang.zx2c4.com/wireguard/conn.setSrcControl(0xc00931b018, 0xc006301640)
        /home/lsc36/wireguard-go/conn/sticky_linux.go:95 +0x280
golang.zx2c4.com/wireguard/conn.(*StdNetBind).send4(0xc0003b6000, 0xffffa9d04200?, 0xc0000b8230, {0x24e6e8?, 0xc006301640?}, {0xc000533800, 0x1, 0xba250?})
        /home/lsc36/wireguard-go/conn/bind_std.go:346 +0x178
golang.zx2c4.com/wireguard/conn.(*StdNetBind).Send(0xc0003b6000, {0xc000533800, 0x1, 0x80}, {0x24e6e8, 0xc006301640})
        /home/lsc36/wireguard-go/conn/bind_std.go:332 +0x1d8
golang.zx2c4.com/wireguard/device.(*Peer).SendBuffers(0xc0000be380, {0xc000533800?, 0x1, 0x80})
        /home/lsc36/wireguard-go/device/peer.go:126 +0x190
golang.zx2c4.com/wireguard/device.(*Peer).RoutineSequentialSender(0xc0000be380, 0x80)
        /home/lsc36/wireguard-go/device/send.go:519 +0x45c
created by golang.zx2c4.com/wireguard/device.(*Peer).Start
        /home/lsc36/wireguard-go/device/peer.go:198 +0x304
--

The offending call `ep.SrcIP().As4()` (sticky_linux.go:95) is only
reached when `ep.SrcIP().Is4() && ep.SrcIP().IsValid()` is true, yet it
panicked saying it was being called against a zero value. That's why I
suspected it's a data race in the first place.

On 3/24/23 01:00, Jordan Whited wrote:
> SC, thank you for reporting. Do you happen to have a stack trace from
> one of the panics?
> 
> On Thu, Mar 23, 2023 at 2:01?AM lsc <lsc at lv6.tw> wrote:
>>
>> Hi,
>>
>> Not sure if this is the correct place for bug reports, hope it's okay :)
>>
>> I found my wireguard-go server (built from current ToT 1417a47) always
>> panicking when I ran speedtest on a client via the server. I rebuilt the
>> server with data race detector (`go build -race`) and got the following
>> trace:
>>
>> ==================
>> WARNING: DATA RACE
>> Read at 0x00c00043b2f8 by goroutine 49:
>>    golang.zx2c4.com/wireguard/conn.setSrcControl()
>>        /home/lsc36/wireguard-go/conn/sticky_linux.go:76 +0x8c
>>    golang.zx2c4.com/wireguard/conn.(*StdNetBind).send4()
>>        /home/lsc36/wireguard-go/conn/bind_std.go:346 +0x174
>>    golang.zx2c4.com/wireguard/conn.(*StdNetBind).Send()
>>        /home/lsc36/wireguard-go/conn/bind_std.go:332 +0x1d4
>>    golang.zx2c4.com/wireguard/device.(*Peer).SendBuffers()
>>        /home/lsc36/wireguard-go/device/peer.go:126 +0x18c
>>    golang.zx2c4.com/wireguard/device.(*Peer).RoutineSequentialSender()
>>        /home/lsc36/wireguard-go/device/send.go:519 +0x458
>>    golang.zx2c4.com/wireguard/device.(*Peer).Start.func2()
>>        /home/lsc36/wireguard-go/device/peer.go:198 +0x40
>>
>> Previous write at 0x00c00043b2f8 by goroutine 47:
>>    golang.zx2c4.com/wireguard/conn.(*StdNetEndpoint).ClearSrc()
>>        /home/lsc36/wireguard-go/conn/bind_std.go:100 +0x48
>>    golang.zx2c4.com/wireguard/conn.getSrcFromControl()
>>        /home/lsc36/wireguard-go/conn/sticky_linux.go:18 +0x3c
>>    golang.zx2c4.com/wireguard/conn.(*StdNetBind).makeReceiveIPv4.func1()
>>        /home/lsc36/wireguard-go/conn/bind_std.go:232 +0x350
>>    golang.zx2c4.com/wireguard/device.(*Device).RoutineReceiveIncoming()
>>        /home/lsc36/wireguard-go/device/receive.go:107 +0x3ac
>>    golang.zx2c4.com/wireguard/device.(*Device).BindUpdate.func3()
>>        /home/lsc36/wireguard-go/device/device.go:530 +0x4c
>>
>> Goroutine 49 (running) created at:
>>    golang.zx2c4.com/wireguard/device.(*Peer).Start()
>>        /home/lsc36/wireguard-go/device/peer.go:198 +0x300
>>    golang.zx2c4.com/wireguard/device.(*ipcSetPeer).handlePostConfig()
>>        /home/lsc36/wireguard-go/device/uapi.go:268 +0x164
>>    golang.zx2c4.com/wireguard/device.(*Device).IpcSetOperation()
>>        /home/lsc36/wireguard-go/device/uapi.go:160 +0x35c
>>    golang.zx2c4.com/wireguard/device.(*Device).IpcHandle()
>>        /home/lsc36/wireguard-go/device/uapi.go:428 +0x248
>>    main.main.func4.1()
>>        /home/lsc36/wireguard-go/main.go:245 +0x4c
>>
>> Goroutine 47 (running) created at:
>>    golang.zx2c4.com/wireguard/device.(*Device).BindUpdate()
>>        /home/lsc36/wireguard-go/device/device.go:530 +0x4b8
>>    golang.zx2c4.com/wireguard/device.(*Device).handleDeviceLine()
>>        /home/lsc36/wireguard-go/device/uapi.go:223 +0x45c
>>    golang.zx2c4.com/wireguard/device.(*Device).IpcSetOperation()
>>        /home/lsc36/wireguard-go/device/uapi.go:183 +0x210
>>    golang.zx2c4.com/wireguard/device.(*Device).IpcHandle()
>>        /home/lsc36/wireguard-go/device/uapi.go:428 +0x248
>>    main.main.func4.1()
>>        /home/lsc36/wireguard-go/main.go:245 +0x4c
>> ==================
>>
>> The bug looks introduced by a recent commit 9e2f386 "conn, device, tun:
>> implement vectorized I/O on Linux". Without much knowledge to the
>> codebase, it seems to me that Endpoint is supposed to be guarded by the
>> RWMutex embedded in Peer, yet the change introduced a write without
>> locking the mutex (`ep.ClearSrc()` called from sticky_linux.go:18).
>>
>> In addition, I found it weird that Endpoint objects are reused via
>> `endpointPool`. The docstring suggests "Endpoints are immutable, so we
>> can re-use them" but that doesn't seem true.
>>
>> Added authors/reviewers of 9e2f386 to cc. Would you take a look?
>>
>> Regards,
>> SC
>>


From Jason at zx2c4.com  Fri Mar 24 13:44:16 2023
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 24 Mar 2023 14:44:16 +0100
Subject: wireguard-go: data race introduced in recent commit 9e2f386
In-Reply-To: <18b4903b-0835-ac5e-49ca-ae6bea08a268@lv6.tw>
References: <ac87f86f-6837-4e0e-ec34-1df35f52540e@lv6.tw>
 <CABprzAaZC86FosOK7A__LB7LzULLYv=-y539y5VHacttYJwSmg@mail.gmail.com>
 <18b4903b-0835-ac5e-49ca-ae6bea08a268@lv6.tw>
Message-ID: <CAHmME9pbN4b115-dnqsMaqGMYq+xzLxDYyAv7xFTPZT6AU_39Q@mail.gmail.com>

Thanks for the panic trace. That indeed looks like the same issue as
the race. Jordan has a stop-gap patch prepared, which I'll send to the
list.

Jason

From Jason at zx2c4.com  Fri Mar 24 13:45:05 2023
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 24 Mar 2023 14:45:05 +0100
Subject: [PATCH wireguard-go] conn: fix StdNetEndpoint data race by
 dynamically allocating endpoints
In-Reply-To: <CAHmME9pbN4b115-dnqsMaqGMYq+xzLxDYyAv7xFTPZT6AU_39Q@mail.gmail.com>
References: <CAHmME9pbN4b115-dnqsMaqGMYq+xzLxDYyAv7xFTPZT6AU_39Q@mail.gmail.com>
Message-ID: <20230324134505.3597572-1-Jason@zx2c4.com>

From: Jordan Whited <jordan at tailscale.com>

In 9e2f386 ("conn, device, tun: implement vectorized I/O on Linux"), the
Linux-specific Bind implementation was collapsed into StdNetBind. This
introduced a race on StdNetEndpoint from getSrcFromControl() and
setSrcControl().

Remove the sync.Pool involved in the race, and simplify StdNetBind's
receive path to allocate StdNetEndpoint on the heap instead, with the
intent for it to be cleaned up by the GC, later. This essentially
reverts ef5c587 ("conn: remove the final alloc per packet receive"),
adding back that allocation, unfortunately.

This does slightly increase resident memory usage in higher throughput
scenarios. StdNetBind is the only Bind implementation that was using
this Endpoint recycling technique prior to this commit.

This is considered a stop-gap solution, and there are plans to replace
the allocation with a better mechanism.

Reported-by: lsc <lsc at lv6.tw>
Link: https://lore.kernel.org/wireguard/ac87f86f-6837-4e0e-ec34-1df35f52540e at lv6.tw/
Fixes: 9e2f386 ("conn, device, tun: implement vectorized I/O on Linux")
Cc: Josh Bleecher Snyder <josharian at gmail.com>
Reviewed-by: James Tucker <james at tailscale.com>
Signed-off-by: Jordan Whited <jordan at tailscale.com>
Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
---
 conn/bind_std.go | 32 ++++++++------------------------
 1 file changed, 8 insertions(+), 24 deletions(-)

diff --git a/conn/bind_std.go b/conn/bind_std.go
index e8cf7b8..491e571 100644
--- a/conn/bind_std.go
+++ b/conn/bind_std.go
@@ -93,7 +93,12 @@ var (
 
 func (*StdNetBind) ParseEndpoint(s string) (Endpoint, error) {
 	e, err := netip.ParseAddrPort(s)
-	return asEndpoint(e), err
+	if err != nil {
+		return nil, err
+	}
+	return &StdNetEndpoint{
+		AddrPort: e,
+	}, nil
 }
 
 func (e *StdNetEndpoint) ClearSrc() {
@@ -228,7 +233,7 @@ func (s *StdNetBind) makeReceiveIPv4(pc *ipv4.PacketConn, conn *net.UDPConn) Rec
 			msg := &(*msgs)[i]
 			sizes[i] = msg.N
 			addrPort := msg.Addr.(*net.UDPAddr).AddrPort()
-			ep := asEndpoint(addrPort)
+			ep := &StdNetEndpoint{AddrPort: addrPort} // TODO: remove allocation
 			getSrcFromControl(msg.OOB[:msg.NN], ep)
 			eps[i] = ep
 		}
@@ -261,7 +266,7 @@ func (s *StdNetBind) makeReceiveIPv6(pc *ipv6.PacketConn, conn *net.UDPConn) Rec
 			msg := &(*msgs)[i]
 			sizes[i] = msg.N
 			addrPort := msg.Addr.(*net.UDPAddr).AddrPort()
-			ep := asEndpoint(addrPort)
+			ep := &StdNetEndpoint{AddrPort: addrPort} // TODO: remove allocation
 			getSrcFromControl(msg.OOB[:msg.NN], ep)
 			eps[i] = ep
 		}
@@ -408,24 +413,3 @@ func (s *StdNetBind) send6(conn *net.UDPConn, pc *ipv6.PacketConn, ep Endpoint,
 	s.ipv6MsgsPool.Put(msgs)
 	return err
 }
-
-// endpointPool contains a re-usable set of mapping from netip.AddrPort to Endpoint.
-// This exists to reduce allocations: Putting a netip.AddrPort in an Endpoint allocates,
-// but Endpoints are immutable, so we can re-use them.
-var endpointPool = sync.Pool{
-	New: func() any {
-		return make(map[netip.AddrPort]*StdNetEndpoint)
-	},
-}
-
-// asEndpoint returns an Endpoint containing ap.
-func asEndpoint(ap netip.AddrPort) *StdNetEndpoint {
-	m := endpointPool.Get().(map[netip.AddrPort]*StdNetEndpoint)
-	defer endpointPool.Put(m)
-	e, ok := m[ap]
-	if !ok {
-		e = &StdNetEndpoint{AddrPort: ap}
-		m[ap] = e
-	}
-	return e
-}
-- 
2.40.0


From khaberz at gmail.com  Thu Mar 30 13:24:59 2023
From: khaberz at gmail.com (Kai Haberzettl)
Date: Thu, 30 Mar 2023 15:24:59 +0200
Subject: Nw Android version crashes on Android TV / Google TV
Message-ID: <CA+CGqoKvx-Yeh6zP1_9goVFaPMKaVPQUij2UrO9B9Ea8cRd7iQ@mail.gmail.com>

The new Android version Version 1.0.20230328 crashes upon startup on
Android TV - in my case on a Google Chromecast with Google TV (others
appear to see the same per reports on reddit).  If I can provide
additional debug Information, please let me know how and I?ll be happy
to.

From Jason at zx2c4.com  Thu Mar 30 14:16:06 2023
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Mar 2023 16:16:06 +0200
Subject: Nw Android version crashes on Android TV / Google TV
In-Reply-To: <CA+CGqoKvx-Yeh6zP1_9goVFaPMKaVPQUij2UrO9B9Ea8cRd7iQ@mail.gmail.com>
References: <CA+CGqoKvx-Yeh6zP1_9goVFaPMKaVPQUij2UrO9B9Ea8cRd7iQ@mail.gmail.com>
Message-ID: <CAHmME9pXvghVW7RUD3gMRR4R9bAfS9YZ7kbt+27m2tnbGtjXFQ@mail.gmail.com>

Already fixed and just waiting on Google to approve the app:
https://git.zx2c4.com/wireguard-android/commit/?id=b734f44200c40fb630fbc566dd245693145f93ec

From Jason at zx2c4.com  Thu Mar 30 14:23:46 2023
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Mar 2023 16:23:46 +0200
Subject: Nw Android version crashes on Android TV / Google TV
In-Reply-To: <CAHmME9pXvghVW7RUD3gMRR4R9bAfS9YZ7kbt+27m2tnbGtjXFQ@mail.gmail.com>
References: <CA+CGqoKvx-Yeh6zP1_9goVFaPMKaVPQUij2UrO9B9Ea8cRd7iQ@mail.gmail.com>
 <CAHmME9pXvghVW7RUD3gMRR4R9bAfS9YZ7kbt+27m2tnbGtjXFQ@mail.gmail.com>
Message-ID: <CAHmME9rTgQKn54SDO+JDNYVYiSFuaV+wjN2yNNNOSw43P6KiKQ@mail.gmail.com>

Or if you can't wait for the update approval, here's the Play Store-signed APK:
https://data.zx2c4.com/wireguard-496-81ed97b6-5d27-466d-a966-f3c7b498ffdb-delete-me-in-two-weeks.apk

From Jason at zx2c4.com  Thu Mar 30 14:39:06 2023
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Mar 2023 16:39:06 +0200
Subject: Possible regression between 5.18.2 and 6.2.1
In-Reply-To: <CQZ7HWJCK18F.1AUR9FMHKPOXB@crawfs>
References: <CQZ7HWJCK18F.1AUR9FMHKPOXB@crawfs>
Message-ID: <CAHmME9qi=26zP-A14pLVxtL86Zj1P-+i93t=_BnSd0t1Dj_U8A@mail.gmail.com>

Hi Dan,

Hard to imagine that this is a WireGuard bug, but more likely
something having to do with SNAT or something.

What is the unallowed src IP when you get that error? Can you debug
further? Maybe bisect a bit? Otherwise, not much I can do.

The diff between those versions you listed is pretty minimal, so I
suspect your bug is elsewhere.

Jason

From Jason at zx2c4.com  Fri Mar 31 16:06:04 2023
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 31 Mar 2023 18:06:04 +0200
Subject: Nw Android version crashes on Android TV / Google TV
In-Reply-To: <CAHmME9rTgQKn54SDO+JDNYVYiSFuaV+wjN2yNNNOSw43P6KiKQ@mail.gmail.com>
References: <CA+CGqoKvx-Yeh6zP1_9goVFaPMKaVPQUij2UrO9B9Ea8cRd7iQ@mail.gmail.com>
 <CAHmME9pXvghVW7RUD3gMRR4R9bAfS9YZ7kbt+27m2tnbGtjXFQ@mail.gmail.com>
 <CAHmME9rTgQKn54SDO+JDNYVYiSFuaV+wjN2yNNNOSw43P6KiKQ@mail.gmail.com>
Message-ID: <CAHmME9ryKHp-YsWHF=v=CieavufWAQKuNNxgGmiP=Kiz2uTWXQ@mail.gmail.com>

The fix has now been released by Google, so just update and the crash
will go away.

From caskd at redxen.eu  Thu Mar 30 07:16:42 2023
From: caskd at redxen.eu (caskd)
Date: Thu, 30 Mar 2023 07:16:42 +0000
Subject: wg config and interface address
Message-ID: <21QN43YXI27DJ.3G5P6T4FS5WOA@unix.is.love.unix.is.life>

Hello,

i've run into a interesting edgecase where if the wireguard config is loaded with `wg setconf` at the same time as a address is added via iproute2's `ip` tool, the address simply disappears without any notice or error. The address addition "succeeds" but is not persisted. I've been able to semi-persistently replicate it but the scheduler gets in the way. Is this a known issue?

-- 
Alex D.
RedXen System & Infrastructure Administration
https://redxen.eu/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 858 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20230330/4ca5b3d6/attachment.sig>