~ubuntu-mainline/ubuntu-mainline/+git/linux-upstream:linux-5.16.y

Last commit made on 2022-04-13
Get this branch:
git clone -b linux-5.16.y https://git.launchpad.net/~ubuntu-mainline/ubuntu-mainline/+git/linux-upstream
Members of Ubuntu Mainline can upload to this branch. Log in for directions.

Branch merges

Branch information

Recent commits

c19a885... by Greg Kroah-Hartman <email address hidden>

Linux 5.16.20

Link: https://<email address hidden>
Tested-by: Shuah Khan <email address hidden>
Tested-by: Ron Economos <email address hidden>
Tested-by: Guenter Roeck <email address hidden>
Tested-by: Linux Kernel Functional Testing <email address hidden>
Tested-by: Justin M. Forbes <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

bff5ed3... by Christophe Leroy <email address hidden>

static_call: Don't make __static_call_return0 static

commit 8fd4ddda2f49a66bf5dd3d0c01966c4b1971308b upstream.

System.map shows that vmlinux contains several instances of
__static_call_return0():

 c0004fc0 t __static_call_return0
 c0011518 t __static_call_return0
 c00d8160 t __static_call_return0

arch_static_call_transform() uses the middle one to check whether we are
setting a call to __static_call_return0 or not:

 c0011520 <arch_static_call_transform>:
 c0011520: 3d 20 c0 01 lis r9,-16383 <== r9 = 0xc001 << 16
 c0011524: 39 29 15 18 addi r9,r9,5400 <== r9 += 0x1518
 c0011528: 7c 05 48 00 cmpw r5,r9 <== r9 has value 0xc0011518 here

So if static_call_update() is called with one of the other instances of
__static_call_return0(), arch_static_call_transform() won't recognise it.

In order to work properly, global single instance of __static_call_return0() is required.

Fixes: 3f2a8fc4b15d ("static_call/x86: Add __static_call_return0()")
Signed-off-by: Christophe Leroy <email address hidden>
Signed-off-by: Peter Zijlstra (Intel) <email address hidden>
Acked-by: Josh Poimboeuf <email address hidden>
Link: https://lkml.kernel.org/r/30821468a0e7d28251954b578e5051dc09300d04<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

3d0089f... by Waiman Long <email address hidden>

mm/sparsemem: fix 'mem_section' will never be NULL gcc 12 warning

commit a431dbbc540532b7465eae4fc8b56a85a9fc7d17 upstream.

The gcc 12 compiler reports a "'mem_section' will never be NULL" warning
on the following code:

    static inline struct mem_section *__nr_to_section(unsigned long nr)
    {
    #ifdef CONFIG_SPARSEMEM_EXTREME
        if (!mem_section)
                return NULL;
    #endif
        if (!mem_section[SECTION_NR_TO_ROOT(nr)])
                return NULL;
       :

It happens with CONFIG_SPARSEMEM_EXTREME off. The mem_section definition
is

    #ifdef CONFIG_SPARSEMEM_EXTREME
    extern struct mem_section **mem_section;
    #else
    extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT];
    #endif

In the !CONFIG_SPARSEMEM_EXTREME case, mem_section is a static
2-dimensional array and so the check "!mem_section[SECTION_NR_TO_ROOT(nr)]"
doesn't make sense.

Fix this warning by moving the "!mem_section[SECTION_NR_TO_ROOT(nr)]"
check up inside the CONFIG_SPARSEMEM_EXTREME block and adding an
explicit NR_SECTION_ROOTS check to make sure that there is no
out-of-bound array access.

Link: https://<email address hidden>
Fixes: 3e347261a80b ("sparsemem extreme implementation")
Signed-off-by: Waiman Long <email address hidden>
Reported-by: Justin Forbes <email address hidden>
Cc: "Kirill A . Shutemov" <email address hidden>
Cc: Ingo Molnar <email address hidden>
Cc: Rafael Aquini <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

2560d9a... by Andre Przywara <email address hidden>

irqchip/gic, gic-v3: Prevent GSI to SGI translations

commit 544808f7e21cb9ccdb8f3aa7de594c05b1419061 upstream.

At the moment the GIC IRQ domain translation routine happily converts
ACPI table GSI numbers below 16 to GIC SGIs (Software Generated
Interrupts aka IPIs). On the Devicetree side we explicitly forbid this
translation, actually the function will never return HWIRQs below 16 when
using a DT based domain translation.

We expect SGIs to be handled in the first part of the function, and any
further occurrence should be treated as a firmware bug, so add a check
and print to report this explicitly and avoid lengthy debug sessions.

Fixes: 64b499d8df40 ("irqchip/gic-v3: Configure SGIs as standard interrupts")
Signed-off-by: Andre Przywara <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

0a8cd9a... by Christophe Leroy <email address hidden>

powerpc/64: Fix build failure with allyesconfig in book3s_64_entry.S

commit af41d2866f7d75bbb38d487f6ec7770425d70e45 upstream.

Using conditional branches between two files is hasardous,
they may get linked too far from each other.

  arch/powerpc/kvm/book3s_64_entry.o:(.text+0x3ec): relocation truncated
  to fit: R_PPC64_REL14 (stub) against symbol `system_reset_common'
  defined in .text section in arch/powerpc/kernel/head_64.o

Reorganise the code to use non conditional branches.

Fixes: 89d35b239101 ("KVM: PPC: Book3S HV P9: Implement the rest of the P9 path in C")
Signed-off-by: Christophe Leroy <email address hidden>
[mpe: Avoid odd-looking bne ., use named local labels]
Signed-off-by: Michael Ellerman <email address hidden>
Link: https://lore.kernel.org/r/89cf27bf43ee07a0b2879b9e8e2f5cd6386a3645<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

1b95786... by Marc Zyngier <email address hidden>

irqchip/gic-v4: Wait for GICR_VPENDBASER.Dirty to clear before descheduling

commit af27e41612ec7e5b4783f589b753a7c31a37aac8 upstream.

The way KVM drives GICv4.{0,1} is as follows:
- vcpu_load() makes the VPE resident, instructing the RD to start
  scanning for interrupts
- just before entering the guest, we check that the RD has finished
  scanning and that we can start running the vcpu
- on preemption, we deschedule the VPE by making it invalid on
  the RD

However, we are preemptible between the first two steps. If it so
happens *and* that the RD was still scanning, we nonetheless write
to the GICR_VPENDBASER register while Dirty is set, and bad things
happen (we're in UNPRED land).

This affects both the 4.0 and 4.1 implementations.

Make sure Dirty is cleared before performing the deschedule,
meaning that its_clear_vpend_valid() becomes a sort of full VPE
residency barrier.

Reported-by: Jingyi Wang <email address hidden>
Tested-by: Nianyao Tang <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
Fixes: 57e3cebd022f ("KVM: arm64: Delay the polling of the GICR_VPENDBASER.Dirty bit")
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

5b4b6fe... by Peter Zijlstra <email address hidden>

x86,static_call: Fix __static_call_return0 for i386

commit 1cd5f059d956e6f614ba6666ecdbcf95db05d5f5 upstream.

Paolo reported that the instruction sequence that is used to replace:

    call __static_call_return0

namely:

    66 66 48 31 c0 data16 data16 xor %rax,%rax

decodes to something else on i386, namely:

    66 66 48 data16 dec %ax
    31 c0 xor %eax,%eax

Which is a nonsensical sequence that happens to have the same outcome.
*However* an important distinction is that it consists of 2
instructions which is a problem when the thing needs to be overwriten
with a regular call instruction again.

As such, replace the instruction with something that decodes the same
on both i386 and x86_64.

Fixes: 3f2a8fc4b15d ("static_call/x86: Add __static_call_return0()")
Reported-by: Paolo Bonzini <email address hidden>
Signed-off-by: Peter Zijlstra (Intel) <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

d5181c4... by Sebastian Andrzej Siewior <email address hidden>

sched: Teach the forced-newidle balancer about CPU affinity limitation.

commit 386ef214c3c6ab111d05e1790e79475363abaa05 upstream.

try_steal_cookie() looks at task_struct::cpus_mask to decide if the
task could be moved to `this' CPU. It ignores that the task might be in
a migration disabled section while not on the CPU. In this case the task
must not be moved otherwise per-CPU assumption are broken.

Use is_cpu_allowed(), as suggested by Peter Zijlstra, to decide if the a
task can be moved.

Fixes: d2dfa17bc7de6 ("sched: Trivial forced-newidle balancer")
Signed-off-by: Sebastian Andrzej Siewior <email address hidden>
Signed-off-by: Peter Zijlstra (Intel) <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

ccc31fc... by darunia_goron

x86/bug: Prevent shadowing in __WARN_FLAGS

commit 9ce02f0fc68326dd1f87a0a3a4c6ae7fdd39e6f6 upstream.

The macro __WARN_FLAGS() uses a local variable named "f". This being a
common name, there is a risk of shadowing other variables.

For example, GCC would yield:

| In file included from ./include/linux/bug.h:5,
| from ./include/linux/cpumask.h:14,
| from ./arch/x86/include/asm/cpumask.h:5,
| from ./arch/x86/include/asm/msr.h:11,
| from ./arch/x86/include/asm/processor.h:22,
| from ./arch/x86/include/asm/timex.h:5,
| from ./include/linux/timex.h:65,
| from ./include/linux/time32.h:13,
| from ./include/linux/time.h:60,
| from ./include/linux/stat.h:19,
| from ./include/linux/module.h:13,
| from virt/lib/irqbypass.mod.c:1:
| ./include/linux/rcupdate.h: In function 'rcu_head_after_call_rcu':
| ./arch/x86/include/asm/bug.h:80:21: warning: declaration of 'f' shadows a parameter [-Wshadow]
| 80 | __auto_type f = BUGFLAG_WARNING|(flags); \
| | ^
| ./include/asm-generic/bug.h:106:17: note: in expansion of macro '__WARN_FLAGS'
| 106 | __WARN_FLAGS(BUGFLAG_ONCE | \
| | ^~~~~~~~~~~~
| ./include/linux/rcupdate.h:1007:9: note: in expansion of macro 'WARN_ON_ONCE'
| 1007 | WARN_ON_ONCE(func != (rcu_callback_t)~0L);
| | ^~~~~~~~~~~~
| In file included from ./include/linux/rbtree.h:24,
| from ./include/linux/mm_types.h:11,
| from ./include/linux/buildid.h:5,
| from ./include/linux/module.h:14,
| from virt/lib/irqbypass.mod.c:1:
| ./include/linux/rcupdate.h:1001:62: note: shadowed declaration is here
| 1001 | rcu_head_after_call_rcu(struct rcu_head *rhp, rcu_callback_t f)
| | ~~~~~~~~~~~~~~~^

For reference, sparse also warns about it, c.f. [1].

This patch renames the variable from f to __flags (with two underscore
prefixes as suggested in the Linux kernel coding style [2]) in order
to prevent collisions.

[1] https://lore.kernel<email address hidden>/

[2] Linux kernel coding style, section 12) Macros, Enums and RTL,
paragraph 5) namespace collisions when defining local variables in
macros resembling functions
https://www.kernel.org/doc/html/latest/process/coding-style.html#macros-enums-and-rtl

Fixes: bfb1a7c91fb7 ("x86/bug: Merge annotate_reachable() into_BUG_FLAGS() asm")
Signed-off-by: Vincent Mailhol <email address hidden>
Signed-off-by: Peter Zijlstra (Intel) <email address hidden>
Reviewed-by: Nick Desaulniers <email address hidden>
Acked-by: Josh Poimboeuf <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

78c4740... by Kefeng Wang <email address hidden>

Revert "powerpc: Set max_mapnr correctly"

commit 1ff5c8e8c835e8a81c0868e3050c76563dd56a2c upstream.

This reverts commit 602946ec2f90d5bd965857753880db29d2d9a1e9.

If CONFIG_HIGHMEM is enabled, no highmem will be added with max_mapnr
set to max_low_pfn, see mem_init():

  for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) {
        ...
        free_highmem_page();
  }

Now that virt_addr_valid() has been fixed in the previous commit, we can
revert the change to max_mapnr.

Fixes: 602946ec2f90 ("powerpc: Set max_mapnr correctly")
Signed-off-by: Kefeng Wang <email address hidden>
Reviewed-by: Christophe Leroy <email address hidden>
Reported-by: Erhard F. <email address hidden>
[mpe: Update change log to reflect series reordering]
Signed-off-by: Michael Ellerman <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>