On Wed, Oct 19, 2022 at 01:19:53PM +0206, John Ogness wrote:
> On 2022-10-18, "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
> > And the v6.1-rc1 stack is now at srcunmisafe.2022.10.18b.
>
> Thanks!
>
> I guess the kernel test robot will catch this, but if you checkout
> commit 79c95dc428ad ("arch/x86: Add ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
> Kconfig option") and build for x86_64, you will get:
>
> x86_64-linux-gnu-ld: kernel/rcu/srcutree.o: in function `srcu_gp_start_if_needed':
> srcutree.c:(.text+0x133a): undefined reference to `__srcu_read_lock_nmisafe'
> x86_64-linux-gnu-ld: srcutree.c:(.text+0x1490): undefined reference to `__srcu_read_unlock_nmisafe'
> x86_64-linux-gnu-ld: kernel/rcu/srcutree.o: in function `srcu_barrier':
> srcutree.c:(.text+0x1b03): undefined reference to `__srcu_read_lock_nmisafe'
> x86_64-linux-gnu-ld: srcutree.c:(.text+0x1b38): undefined reference to `__srcu_read_unlock_nmisafe'
>
> Note that this error is fixed with a later commit:
>
> commit c2d158a284ab ("srcu: Debug NMI safety even on archs that don't
> require it").
>
> This does not affect what I am working on, so feel free to take care of
> it whenever it fits your schedule.
Good catch, thank you!
It looks like the first two hunks in include/linux/srcu.h from that
later commit need to be in that earlier commit.
Frederic, does this make sense, or am I off in the weeds?
If so, my thought is to make this change in the name of bisectability,
then produce a new srcunmisafe branch. The printk() series would
then need to rebase or remerge this new series.
John, would that work for you?
Thanx, Paul
