MISC:https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.5


Download: text/plain
Original: cdn.kernel.org
commit 92b4b5943ca68e4849f809e4a14b3168aba3fe4d
Author: Greg Kroah-Hartman <[email protected]>
Date:   Tue Feb 1 17:29:20 2022 +0100

    Linux 5.16.5
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Ronald Warsow <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Zan Aziz <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-By: Scott Bruce <[email protected]>
    Tested-by: Bagas Sanjaya <[email protected]>
    Tested-by: Rudi Heitbaum <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 36c3017551dbeecbbc1dafe7a56cf07e7a159972
Author: Geert Uytterhoeven <[email protected]>
Date:   Mon Nov 22 14:21:38 2021 +0100

    mtd: rawnand: mpc5121: Remove unused variable in ads5121_select_chip()
    
    commit 33a0da68fb073360d36ce1a0e852f75fede7c21e upstream.
    
    drivers/mtd/nand/raw/mpc5121_nfc.c: In function ‘ads5121_select_chip’:
    drivers/mtd/nand/raw/mpc5121_nfc.c:294:19: warning: unused variable ‘mtd’ [-Wunused-variable]
      294 |  struct mtd_info *mtd = nand_to_mtd(nand);
          |                   ^~~
    
    Fixes: 758b56f58b66bebc ("mtd: rawnand: Pass a nand_chip object to chip->select_chip()")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Cc: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 941d5180c430ce5b0f7a3622ef9b76077bfa3d82
Author: OGAWA Hirofumi <[email protected]>
Date:   Sun Jan 9 18:36:43 2022 +0900

    block: Fix wrong offset in bio_truncate()
    
    commit 3ee859e384d453d6ac68bfd5971f630d9fa46ad3 upstream.
    
    bio_truncate() clears the buffer outside of last block of bdev, however
    current bio_truncate() is using the wrong offset of page. So it can
    return the uninitialized data.
    
    This happened when both of truncated/corrupted FS and userspace (via
    bdev) are trying to read the last of bdev.
    
    Reported-by: [email protected]
    Signed-off-by: OGAWA Hirofumi <[email protected]>
    Reviewed-by: Ming Lei <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b8d19063e700c20d91821c4c827cd6c51a6baebb
Author: Vitaly Kuznetsov <[email protected]>
Date:   Wed Jan 12 18:01:34 2022 +0100

    KVM: nVMX: Allow VMREAD when Enlightened VMCS is in use
    
    commit 6cbbaab60ff33f59355492c241318046befd9ffc upstream.
    
    Hyper-V TLFS explicitly forbids VMREAD and VMWRITE instructions when
    Enlightened VMCS interface is in use:
    
    "Any VMREAD or VMWRITE instructions while an enlightened VMCS is
    active is unsupported and can result in unexpected behavior.""
    
    Windows 11 + WSL2 seems to ignore this, attempts to VMREAD VMCS field
    0x4404 ("VM-exit interruption information") are observed. Failing
    these attempts with nested_vmx_failInvalid() makes such guests
    unbootable.
    
    Microsoft confirms this is a Hyper-V bug and claims that it'll get fixed
    eventually but for the time being we need a workaround. (Temporary) allow
    VMREAD to get data from the currently loaded Enlightened VMCS.
    
    Note: VMWRITE instructions remain forbidden, it is not clear how to
    handle them properly and hopefully won't ever be needed.
    
    Reviewed-by: Sean Christopherson <[email protected]>
    Signed-off-by: Vitaly Kuznetsov <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 01a15e36b1fb209a0cd589a1ce007e11776b640b
Author: Vitaly Kuznetsov <[email protected]>
Date:   Wed Jan 12 18:01:33 2022 +0100

    KVM: nVMX: Implement evmcs_field_offset() suitable for handle_vmread()
    
    commit 892a42c10ddb945d3a4dcf07dccdf9cb98b21548 upstream.
    
    In preparation to allowing reads from Enlightened VMCS from
    handle_vmread(), implement evmcs_field_offset() to get the correct
    read offset. get_evmcs_offset(), which is being used by KVM-on-Hyper-V,
    is almost what's needed but a few things need to be adjusted. First,
    WARN_ON() is unacceptable for handle_vmread() as any field can (in
    theory) be supplied by the guest and not all fields are defined in
    eVMCS v1. Second, we need to handle 'holes' in eVMCS (missing fields).
    It also sounds like a good idea to WARN_ON() if such fields are ever
    accessed by KVM-on-Hyper-V.
    
    Implement dedicated evmcs_field_offset() helper.
    
    No functional change intended.
    
    Signed-off-by: Vitaly Kuznetsov <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ea30a90df837a3442f15e6b171fba390674227fe
Author: Vitaly Kuznetsov <[email protected]>
Date:   Wed Jan 12 18:01:32 2022 +0100

    KVM: nVMX: Rename vmcs_to_field_offset{,_table}
    
    commit 2423a4c0d17418eca1ba1e3f48684cb2ab7523d5 upstream.
    
    vmcs_to_field_offset{,_table} may sound misleading as VMCS is an opaque
    blob which is not supposed to be accessed directly. In fact,
    vmcs_to_field_offset{,_table} are related to KVM defined VMCS12 structure.
    
    Rename vmcs_field_to_offset() to get_vmcs12_field_offset() for clarity.
    
    No functional change intended.
    
    Reviewed-by: Sean Christopherson <[email protected]>
    Signed-off-by: Vitaly Kuznetsov <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d9ee5d1f377b3671036d78ec3608c8ceb632c9d2
Author: Maor Gottlieb <[email protected]>
Date:   Sat Jan 29 13:41:07 2022 -0800

    tools/testing/scatterlist: add missing defines
    
    [ Upstream commit 0226bd64da52aa23120d1450c37a424387827a21 ]
    
    The cited commits replaced preemptible with pagefault_disabled and
    flush_kernel_dcache_page with flush_dcache_page respectively, hence need
    to update the corresponding defines in the test.
    
      scatterlist.c: In function ‘sg_miter_stop’:
      scatterlist.c:919:4: warning: implicit declaration of function ‘flush_dcache_page’ [-Wimplicit-function-declaration]
          flush_dcache_page(miter->page);
          ^~~~~~~~~~~~~~~~~
      In file included from linux/scatterlist.h:8:0,
                       from scatterlist.c:9:
      scatterlist.c:922:18: warning: implicit declaration of function ‘pagefault_disabled’ [-Wimplicit-function-declaration]
          WARN_ON_ONCE(!pagefault_disabled());
                        ^
      linux/mm.h:23:25: note: in definition of macro ‘WARN_ON_ONCE’
        int __ret_warn_on = !!(condition);                      \
                               ^~~~~~~~~
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 723aca208516 ("mm/scatterlist: replace the !preemptible warning in sg_miter_stop()")
    Fixes: 0e84f5dbf8d6 ("scatterlist: replace flush_kernel_dcache_page with flush_dcache_page")
    Signed-off-by: Maor Gottlieb <[email protected]>
    Tested-by: Sebastian Andrzej Siewior <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e35b0264f706fb9e05191485ce50bc9b79eb52a7
Author: Dmitry V. Levin <[email protected]>
Date:   Mon Jan 3 04:24:02 2022 +0300

    usr/include/Makefile: add linux/nfc.h to the compile-test coverage
    
    commit 10756dc5b02bff370ddd351d7744bc99ada659c2 upstream.
    
    As linux/nfc.h userspace compilation was finally fixed by commits
    79b69a83705e ("nfc: uapi: use kernel size_t to fix user-space builds")
    and 7175f02c4e5f ("uapi: fix linux/nfc.h userspace compilation errors"),
    there is no need to keep the compile-test exception for it in
    usr/include/Makefile.
    
    Signed-off-by: Dmitry V. Levin <[email protected]>
    Signed-off-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b7a266a79ec5467dbf7fddffb0da5c8c06d2db75
Author: Robert Hancock <[email protected]>
Date:   Thu Jan 27 16:15:00 2022 -0600

    usb: dwc3: xilinx: fix uninitialized return value
    
    commit b470947c3672f7eb7c4c271d510383d896831cc2 upstream.
    
    A previous patch to skip part of the initialization when a USB3 PHY was
    not present could result in the return value being uninitialized in that
    case, causing spurious probe failures. Initialize ret to 0 to avoid this.
    
    Fixes: 9678f3361afc ("usb: dwc3: xilinx: Skip resets and USB3 register settings for USB2.0 mode")
    Cc: <[email protected]>
    Reviewed-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Robert Hancock <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fea51b4799141ea3ec827a087ae4331bd1406e2d
Author: Suren Baghdasaryan <[email protected]>
Date:   Sat Jan 29 13:41:20 2022 -0800

    psi: fix "defined but not used" warnings when CONFIG_PROC_FS=n
    
    commit 44585f7bc0cb01095bc2ad4258049c02bbad21ef upstream.
    
    When CONFIG_PROC_FS is disabled psi code generates the following
    warnings:
    
      kernel/sched/psi.c:1364:30: warning: 'psi_cpu_proc_ops' defined but not used [-Wunused-const-variable=]
          1364 | static const struct proc_ops psi_cpu_proc_ops = {
               |                              ^~~~~~~~~~~~~~~~
      kernel/sched/psi.c:1355:30: warning: 'psi_memory_proc_ops' defined but not used [-Wunused-const-variable=]
          1355 | static const struct proc_ops psi_memory_proc_ops = {
               |                              ^~~~~~~~~~~~~~~~~~~
      kernel/sched/psi.c:1346:30: warning: 'psi_io_proc_ops' defined but not used [-Wunused-const-variable=]
          1346 | static const struct proc_ops psi_io_proc_ops = {
               |                              ^~~~~~~~~~~~~~~
    
    Make definitions of these structures and related functions conditional
    on CONFIG_PROC_FS config.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 0e94682b73bf ("psi: introduce psi monitor")
    Signed-off-by: Suren Baghdasaryan <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Acked-by: Johannes Weiner <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fb5b2f46f15e7c7c240de5c4a3c1fa822e5acb47
Author: Suren Baghdasaryan <[email protected]>
Date:   Sat Jan 29 13:41:17 2022 -0800

    psi: fix "no previous prototype" warnings when CONFIG_CGROUPS=n
    
    commit 51e50fbd3efc6064c30ed73a5e009018b36e290a upstream.
    
    When CONFIG_CGROUPS is disabled psi code generates the following
    warnings:
    
      kernel/sched/psi.c:1112:21: warning: no previous prototype for 'psi_trigger_create' [-Wmissing-prototypes]
          1112 | struct psi_trigger *psi_trigger_create(struct psi_group *group,
               |                     ^~~~~~~~~~~~~~~~~~
      kernel/sched/psi.c:1182:6: warning: no previous prototype for 'psi_trigger_destroy' [-Wmissing-prototypes]
          1182 | void psi_trigger_destroy(struct psi_trigger *t)
               |      ^~~~~~~~~~~~~~~~~~~
      kernel/sched/psi.c:1249:10: warning: no previous prototype for 'psi_trigger_poll' [-Wmissing-prototypes]
          1249 | __poll_t psi_trigger_poll(void **trigger_ptr,
               |          ^~~~~~~~~~~~~~~~
    
    Change the declarations of these functions in the header to provide the
    prototypes even when they are unused.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 0e94682b73bf ("psi: introduce psi monitor")
    Signed-off-by: Suren Baghdasaryan <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Acked-by: Johannes Weiner <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bbfe488a622a64d74fec76bdd47f7571f5e537d3
Author: Namhyung Kim <[email protected]>
Date:   Mon Jan 24 11:58:08 2022 -0800

    perf/core: Fix cgroup event list management
    
    commit c5de60cd622a2607c043ba65e25a6e9998a369f9 upstream.
    
    The active cgroup events are managed in the per-cpu cgrp_cpuctx_list.
    This list is only accessed from current cpu and not protected by any
    locks.  But from the commit ef54c1a476ae ("perf: Rework
    perf_event_exit_event()"), it's possible to access (actually modify)
    the list from another cpu.
    
    In the perf_remove_from_context(), it can remove an event from the
    context without an IPI when the context is not active.  This is not
    safe with cgroup events which can have some active events in the
    context even if ctx->is_active is 0 at the moment.  The target cpu
    might be in the middle of list iteration at the same time.
    
    If the event is enabled when it's about to be closed, it might call
    perf_cgroup_event_disable() and list_del() with the cgrp_cpuctx_list
    on a different cpu.
    
    This resulted in a crash due to an invalid list pointer access during
    the cgroup list traversal on the cpu which the event belongs to.
    
    Let's fallback to IPI to access the cgrp_cpuctx_list from that cpu.
    Similarly, perf_install_in_context() should use IPI for the cgroup
    events too.
    
    Fixes: ef54c1a476ae ("perf: Rework perf_event_exit_event()")
    Signed-off-by: Namhyung Kim <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit e2a9068e95cca944ce3c109e10c852b853549474
Author: Sergio Paracuellos <[email protected]>
Date:   Mon Jan 24 12:30:03 2022 +0100

    PCI: mt7621: Remove unused function pcie_rmw()
    
    commit c035366d9c9fe48d947ee6c43465ab43d42e20f2 upstream.
    
    Function pcie_rmw() is not being used at all and can be deleted. Hence get
    rid of it, which fixes this warning:
    
      drivers/pci/controller/pcie-mt7621.c:112:20: warning: unused function 'pcie_rmw' [-Wunused-function]
    
    Fixes: 2bdd5238e756 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver")
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/all/[email protected]/
    Reported-by: kernel test robot <[email protected]>
    Signed-off-by: Sergio Paracuellos <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 974a83241e211680017ff794dc40b29dad33d4fc
Author: Marc Kleine-Budde <[email protected]>
Date:   Fri Jan 14 18:47:41 2022 +0100

    dt-bindings: can: tcan4x5x: fix mram-cfg RX FIFO config
    
    commit 17a30422621c0e04cb6060d20d7edcefd7463347 upstream.
    
    This tcan4x5x only comes with 2K of MRAM, a RX FIFO with a dept of 32
    doesn't fit into the MRAM. Use a depth of 16 instead.
    
    Fixes: 4edd396a1911 ("dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver")
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 087b892441aedfda7400bd3d3af3193a23d01af3
Author: Sander Vanheule <[email protected]>
Date:   Sun Jan 9 15:54:33 2022 +0100

    irqchip/realtek-rtl: Fix off-by-one in routing
    
    commit 91351b5dd0fd494eb2d85e1bb6aca77b067447e0 upstream.
    
    There is an offset between routing values (1..6) and the connected MIPS
    CPU interrupts (2..7), but no distinction was made between these two
    values.
    
    This issue was previously hidden during testing, because an interrupt
    mapping was used where for each required interrupt another (unused)
    routing was configured, with an offset of +1.
    
    Offset the CPU IRQ numbers by -1 to retrieve the correct routing value.
    
    Fixes: 9f3a0f34b84a ("irqchip: Add support for Realtek RTL838x/RTL839x interrupt controller")
    Signed-off-by: Sander Vanheule <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]vanheule.net
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit bc9de85a9e2dc6b2e1ef57652e895ca0c09a9b9e
Author: Sander Vanheule <[email protected]>
Date:   Sun Jan 9 15:54:32 2022 +0100

    irqchip/realtek-rtl: Map control data to virq
    
    commit 291e79c7e2eb6fdc016453597b78482e06199d0f upstream.
    
    The driver assigned the irqchip and irq handler to the hardware irq,
    instead of the virq. This is incorrect, and only worked because these
    irq numbers happened to be the same on the devices used for testing the
    original driver.
    
    Fixes: 9f3a0f34b84a ("irqchip: Add support for Realtek RTL838x/RTL839x interrupt controller")
    Signed-off-by: Sander Vanheule <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]vanheule.net
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 14be8d448fca6fe7b2a413831eedd55aef6c6511
Author: Tim Yi <[email protected]>
Date:   Thu Jan 27 15:49:53 2022 +0800

    net: bridge: vlan: fix memory leak in __allowed_ingress
    
    [ Upstream commit fd20d9738395cf8e27d0a17eba34169699fccdff ]
    
    When using per-vlan state, if vlan snooping and stats are disabled,
    untagged or priority-tagged ingress frame will go to check pvid state.
    If the port state is forwarding and the pvid state is not
    learning/forwarding, untagged or priority-tagged frame will be dropped
    but skb memory is not freed.
    Should free skb when __allowed_ingress returns false.
    
    Fixes: a580c76d534c ("net: bridge: vlan: add per-vlan state")
    Signed-off-by: Tim Yi <[email protected]>
    Acked-by: Nikolay Aleksandrov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 64e59e5f55532c672b9d0598d7081c6ff9fbc90e
Author: Eric Dumazet <[email protected]>
Date:   Wed Jan 26 17:34:04 2022 -0800

    ipv4: remove sparse error in ip_neigh_gw4()
    
    [ Upstream commit 3c42b2019863b327caa233072c50739d4144dd16 ]
    
    ./include/net/route.h:373:48: warning: incorrect type in argument 2 (different base types)
    ./include/net/route.h:373:48:    expected unsigned int [usertype] key
    ./include/net/route.h:373:48:    got restricted __be32 [usertype] daddr
    
    Fixes: 5c9f7c1dfc2e ("ipv4: Add helpers for neigh lookup for nexthop")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit d14713b68adb9c85fe32571bc3fecd01cc5b9057
Author: Eric Dumazet <[email protected]>
Date:   Wed Jan 26 17:10:21 2022 -0800

    ipv4: tcp: send zero IPID in SYNACK messages
    
    [ Upstream commit 970a5a3ea86da637471d3cd04d513a0755aba4bf ]
    
    In commit 431280eebed9 ("ipv4: tcp: send zero IPID for RST and
    ACK sent in SYN-RECV and TIME-WAIT state") we took care of some
    ctl packets sent by TCP.
    
    It turns out we need to use a similar strategy for SYNACK packets.
    
    By default, they carry IP_DF and IPID==0, but there are ways
    to ask them to use the hashed IP ident generator and thus
    be used to build off-path attacks.
    (Ref: Off-Path TCP Exploits of the Mixed IPID Assignment)
    
    One of this way is to force (before listener is started)
    echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc
    
    Another way is using forged ICMP ICMP_FRAG_NEEDED
    with a very small MTU (like 68) to force a false return from
    ip_dont_fragment()
    
    In this patch, ip_build_and_send_pkt() uses the following
    heuristics.
    
    1) Most SYNACK packets are smaller than IPV4_MIN_MTU and therefore
    can use IP_DF regardless of the listener or route pmtu setting.
    
    2) In case the SYNACK packet is bigger than IPV4_MIN_MTU,
    we use prandom_u32() generator instead of the IPv4 hashed ident one.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Ray Che <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Cc: Geoff Alexander <[email protected]>
    Cc: Willy Tarreau <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 9543145c93d89a1a83d339e2deb50b4b861ac796
Author: Eric Dumazet <[email protected]>
Date:   Wed Jan 26 16:51:16 2022 -0800

    ipv4: raw: lock the socket in raw_bind()
    
    [ Upstream commit 153a0d187e767c68733b8e9f46218eb1f41ab902 ]
    
    For some reason, raw_bind() forgot to lock the socket.
    
    BUG: KCSAN: data-race in __ip4_datagram_connect / raw_bind
    
    write to 0xffff8881170d4308 of 4 bytes by task 5466 on cpu 0:
     raw_bind+0x1b0/0x250 net/ipv4/raw.c:739
     inet_bind+0x56/0xa0 net/ipv4/af_inet.c:443
     __sys_bind+0x14b/0x1b0 net/socket.c:1697
     __do_sys_bind net/socket.c:1708 [inline]
     __se_sys_bind net/socket.c:1706 [inline]
     __x64_sys_bind+0x3d/0x50 net/socket.c:1706
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    read to 0xffff8881170d4308 of 4 bytes by task 5468 on cpu 1:
     __ip4_datagram_connect+0xb7/0x7b0 net/ipv4/datagram.c:39
     ip4_datagram_connect+0x2a/0x40 net/ipv4/datagram.c:89
     inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576
     __sys_connect_file net/socket.c:1900 [inline]
     __sys_connect+0x197/0x1b0 net/socket.c:1917
     __do_sys_connect net/socket.c:1927 [inline]
     __se_sys_connect net/socket.c:1924 [inline]
     __x64_sys_connect+0x3d/0x50 net/socket.c:1924
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    value changed: 0x00000000 -> 0x0003007f
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 5468 Comm: syz-executor.5 Not tainted 5.17.0-rc1-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: syzbot <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a91b51d5b85da05e21ba68631f4093104b4c97ed
Author: Nikolay Aleksandrov <[email protected]>
Date:   Wed Jan 26 15:10:25 2022 +0200

    net: bridge: vlan: fix single net device option dumping
    
    [ Upstream commit dcb2c5c6ca9b9177f04abaf76e5a983d177c9414 ]
    
    When dumping vlan options for a single net device we send the same
    entries infinitely because user-space expects a 0 return at the end but
    we keep returning skb->len and restarting the dump on retry. Fix it by
    returning the value from br_vlan_dump_dev() if it completed or there was
    an error. The only case that must return skb->len is when the dump was
    incomplete and needs to continue (-EMSGSIZE).
    
    Reported-by: Benjamin Poirier <[email protected]>
    Fixes: 8dcea187088b ("net: bridge: vlan: add rtm definitions and dump support")
    Signed-off-by: Nikolay Aleksandrov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 8d6f16130aadc4f5e9334ef1cd6aef0a4ec6db11
Author: Guillaume Nault <[email protected]>
Date:   Wed Jan 26 16:38:52 2022 +0100

    Revert "ipv6: Honor all IPv6 PIO Valid Lifetime values"
    
    [ Upstream commit 36268983e90316b37000a005642af42234dabb36 ]
    
    This reverts commit b75326c201242de9495ff98e5d5cff41d7fc0d9d.
    
    This commit breaks Linux compatibility with USGv6 tests. The RFC this
    commit was based on is actually an expired draft: no published RFC
    currently allows the new behaviour it introduced.
    
    Without full IETF endorsement, the flash renumbering scenario this
    patch was supposed to enable is never going to work, as other IPv6
    equipements on the same LAN will keep the 2 hours limit.
    
    Fixes: b75326c20124 ("ipv6: Honor all IPv6 PIO Valid Lifetime values")
    Signed-off-by: Guillaume Nault <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 7811229f02b1ddee56b45faffbb6c54963587e80
Author: Catherine Sullivan <[email protected]>
Date:   Tue Jan 25 16:38:43 2022 -0800

    gve: Fix GFP flags when allocing pages
    
    [ Upstream commit a92f7a6feeb3884c69c1c7c1f13bccecb2228ad0 ]
    
    Use GFP_ATOMIC when allocating pages out of the hotpath,
    continue to use GFP_KERNEL when allocating pages during setup.
    
    GFP_KERNEL will allow blocking which allows it to succeed
    more often in a low memory enviornment but in the hotpath we do
    not want to allow the allocation to block.
    
    Fixes: f5cedc84a30d2 ("gve: Add transmit and receive support")
    Signed-off-by: Catherine Sullivan <[email protected]>
    Signed-off-by: David Awogbemila <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 4305a3bf6efc7b96e2b638b9ea258c6ab903fcc7
Author: Xiubo Li <[email protected]>
Date:   Wed Jan 12 12:29:04 2022 +0800

    ceph: put the requests/sessions when it fails to alloc memory
    
    [ Upstream commit 89d43d0551a848e70e63d9ba11534aaeabc82443 ]
    
    When failing to allocate the sessions memory we should make sure
    the req1 and req2 and the sessions get put. And also in case the
    max_sessions decreased so when kreallocate the new memory some
    sessions maybe missed being put.
    
    And if the max_sessions is 0 krealloc will return ZERO_SIZE_PTR,
    which will lead to a distinct access fault.
    
    URL: https://tracker.ceph.com/issues/53819
    Fixes: e1a4541ec0b9 ("ceph: flush the mdlog before waiting on unsafe reqs")
    Signed-off-by: Xiubo Li <[email protected]>
    Reviewed-by: Venky Shankar <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit b3ae9767c7e1590ef4a0b3ae48fe9239039ac614
Author: Sean Christopherson <[email protected]>
Date:   Tue Jan 25 22:17:25 2022 +0000

    KVM: selftests: Don't skip L2's VMCALL in SMM test for SVM guest
    
    [ Upstream commit 4cf3d3ebe8794c449af3e0e8c1d790c97e461d20 ]
    
    Don't skip the vmcall() in l2_guest_code() prior to re-entering L2, doing
    so will result in L2 running to completion, popping '0' off the stack for
    RET, jumping to address '0', and ultimately dying with a triple fault
    shutdown.
    
    It's not at all obvious why the test re-enters L2 and re-executes VMCALL,
    but presumably it serves a purpose.  The VMX path doesn't skip vmcall(),
    and the test can't possibly have passed on SVM, so just do what VMX does.
    
    Fixes: d951b2210c1a ("KVM: selftests: smm_test: Test SMM enter from L2")
    Cc: Maxim Levitsky <[email protected]>
    Signed-off-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Reviewed-by: Vitaly Kuznetsov <[email protected]>
    Tested-by: Vitaly Kuznetsov <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 75ad6eb6481608deb9997b7260077d6392163164
Author: Dave Airlie <[email protected]>
Date:   Thu Jan 20 14:05:27 2022 +1000

    Revert "drm/ast: Support 1600x900 with 108MHz PCLK"
    
    [ Upstream commit 76cea3d95513fe40000d06a3719c4bb6b53275e2 ]
    
    This reverts commit 9bb7b689274b67ecb3641e399e76f84adc627df1.
    
    This caused a regression reported to Red Hat.
    
    Fixes: 9bb7b689274b ("drm/ast: Support 1600x900 with 108MHz PCLK")
    Signed-off-by: Dave Airlie <[email protected]>
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit 42986f43685a9ca19b5cbed0d0a4ee591cf08f75
Author: Maxim Mikityanskiy <[email protected]>
Date:   Tue Jan 25 12:06:54 2022 +0200

    sch_htb: Fail on unsupported parameters when offload is requested
    
    [ Upstream commit 429c3be8a5e2695b5b92a6a12361eb89eb185495 ]
    
    The current implementation of HTB offload doesn't support some
    parameters. Instead of ignoring them, actively return the EINVAL error
    when they are set to non-defaults.
    
    As this patch goes to stable, the driver API is not changed here. If
    future drivers support more offload parameters, the checks can be moved
    to the driver side.
    
    Note that the buffer and cbuffer parameters are also not supported, but
    the tc userspace tool assigns some default values derived from rate and
    ceil, and identifying these defaults in sch_htb would be unreliable, so
    they are still ignored.
    
    Fixes: d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload")
    Reported-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Maxim Mikityanskiy <[email protected]>
    Reviewed-by: Tariq Toukan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a7fce09f160e21f82906ec1effe6105541855d72
Author: David Matlack <[email protected]>
Date:   Thu Jan 20 00:38:26 2022 +0000

    KVM: selftests: Re-enable access_tracking_perf_test
    
    [ Upstream commit de1956f48543e90f94b1194395f33140898b39b2 ]
    
    This selftest was accidentally removed by commit 6a58150859fd
    ("selftest: KVM: Add intra host migration tests"). Add it back.
    
    Fixes: 6a58150859fd ("selftest: KVM: Add intra host migration tests")
    Signed-off-by: David Matlack <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit dc66881387e6f761b16adb5e67735d00d63cb4fc
Author: Yufeng Mo <[email protected]>
Date:   Tue Jan 25 15:03:12 2022 +0800

    net: hns3: handle empty unknown interrupt for VF
    
    [ Upstream commit 2f61353cd2f789a4229b6f5c1c24a40a613357bb ]
    
    Since some interrupt states may be cleared by hardware, the driver
    may receive an empty interrupt. Currently, the VF driver directly
    disables the vector0 interrupt in this case. As a result, the VF
    is unavailable. Therefore, the vector0 interrupt should be enabled
    in this case.
    
    Fixes: b90fcc5bd904 ("net: hns3: add reset handling for VF when doing Core/Global/IMP reset")
    Signed-off-by: Yufeng Mo <[email protected]>
    Signed-off-by: Guangbin Huang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit e41ea0ebf87e204e0723c2d091fadbe407fd7ee3
Author: Toke Høiland-Jørgensen <[email protected]>
Date:   Mon Jan 24 15:35:29 2022 +0100

    net: cpsw: Properly initialise struct page_pool_params
    
    [ Upstream commit c63003e3d99761afb280add3b30de1cf30fa522b ]
    
    The cpsw driver didn't properly initialise the struct page_pool_params
    before calling page_pool_create(), which leads to crashes after the struct
    has been expanded with new parameters.
    
    The second Fixes tag below is where the buggy code was introduced, but
    because the code was moved around this patch will only apply on top of the
    commit in the first Fixes tag.
    
    Fixes: c5013ac1dd0e ("net: ethernet: ti: cpsw: move set of common functions in cpsw_priv")
    Fixes: 9ed4050c0d75 ("net: ethernet: ti: cpsw: add XDP support")
    Reported-by: Colin Foster <[email protected]>
    Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
    Tested-by: Colin Foster <[email protected]>
    Acked-by: Jesper Dangaard Brouer <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit deb0f02d08276d87212c1f19d9d919b13dc4c033
Author: Hangyu Hua <[email protected]>
Date:   Mon Jan 24 11:29:54 2022 +0800

    yam: fix a memory leak in yam_siocdevprivate()
    
    [ Upstream commit 29eb31542787e1019208a2e1047bb7c76c069536 ]
    
    ym needs to be free when ym->cmd != SIOCYAMSMCS.
    
    Fixes: 0781168e23a2 ("yam: fix a missing-check bug")
    Signed-off-by: Hangyu Hua <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 36f9629b96082c3a1fb845bc45e6ba41e1d46746
Author: Rob Clark <[email protected]>
Date:   Thu Jan 13 08:32:13 2022 -0800

    drm/msm/a6xx: Add missing suspend_count increment
    
    [ Upstream commit 860a7b2a87b7c743154824d0597b6c3eb3b53154 ]
    
    Reported-by: Danylo Piliaiev <[email protected]>
    Fixes: 3ab1c5cc3939 ("drm/msm: Add param for userspace to query suspend count")
    Signed-off-by: Rob Clark <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 1ebc18836d5df09061657f8c548e594cbb519476
Author: José Expósito <[email protected]>
Date:   Sun Jan 9 20:24:31 2022 +0100

    drm/msm/dpu: invalid parameter check in dpu_setup_dspp_pcc
    
    [ Upstream commit 170b22234d5495f5e0844246e23f004639ee89ba ]
    
    The function performs a check on the "ctx" input parameter, however, it
    is used before the check.
    
    Initialize the "base" variable after the sanity check to avoid a
    possible NULL pointer dereference.
    
    Fixes: 4259ff7ae509e ("drm/msm/dpu: add support for pcc color block in dpu driver")
    Addresses-Coverity-ID: 1493866 ("Null pointer dereference")
    Signed-off-by: José Expósito <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 502fc7dd748643d0d75577687fa07f4812ba3061
Author: Miaoqian Lin <[email protected]>
Date:   Fri Jan 7 08:50:22 2022 +0000

    drm/msm/hdmi: Fix missing put_device() call in msm_hdmi_get_phy
    
    [ Upstream commit 774fe0cd838d1b1419d41ab4ea0613c80d4ecbd7 ]
    
    The reference taken by 'of_find_device_by_node()' must be released when
    not needed anymore.
    Add the corresponding 'put_device()' in the error handling path.
    
    Fixes: e00012b256d4 ("drm/msm/hdmi: Make HDMI core get its PHY")
    Signed-off-by: Miaoqian Lin <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit cfb7d12f2e4a4d694f49e9b4ebb352f7b67cdfbb
Author: Guenter Roeck <[email protected]>
Date:   Sun Jan 23 18:23:22 2022 -0800

    hwmon: (nct6775) Fix crash in clear_caseopen
    
    [ Upstream commit 79da533d3cc717ccc05ddbd3190da8a72bc2408b ]
    
    Paweł Marciniak reports the following crash, observed when clearing
    the chassis intrusion alarm.
    
    BUG: kernel NULL pointer dereference, address: 0000000000000028
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP PTI
    CPU: 3 PID: 4815 Comm: bash Tainted: G S                5.16.2-200.fc35.x86_64 #1
    Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme4, BIOS P2.60A 05/03/2018
    RIP: 0010:clear_caseopen+0x5a/0x120 [nct6775]
    Code: 68 70 e8 e9 32 b1 e3 85 c0 0f 85 d2 00 00 00 48 83 7c 24 ...
    RSP: 0018:ffffabcb02803dd8 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000
    RDX: ffff8e8808192880 RSI: 0000000000000000 RDI: ffff8e87c7509a68
    RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000000a
    R10: 000000000000000a R11: f000000000000000 R12: 000000000000001f
    R13: ffff8e87c7509828 R14: ffff8e87c7509a68 R15: ffff8e88494527a0
    FS:  00007f4db9151740(0000) GS:ffff8e8ebfec0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000028 CR3: 0000000166b66001 CR4: 00000000001706e0
    Call Trace:
     <TASK>
     kernfs_fop_write_iter+0x11c/0x1b0
     new_sync_write+0x10b/0x180
     vfs_write+0x209/0x2a0
     ksys_write+0x4f/0xc0
     do_syscall_64+0x3b/0x90
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    The problem is that the device passed to clear_caseopen() is the hwmon
    device, not the platform device, and the platform data is not set in the
    hwmon device. Store the pointer to sio_data in struct nct6775_data and
    get if from there if needed.
    
    Fixes: 2e7b9886968b ("hwmon: (nct6775) Use superio_*() function pointers in sio_data.")
    Cc: Denis Pauk <[email protected]>
    Cc: Bernhard Seibold <[email protected]>
    Reported-by: Paweł Marciniak <[email protected]>
    Tested-by: Denis Pauk <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 64c3f1e08e33c9b96ec493037ee47e0b95d73d40
Author: Marc Kleine-Budde <[email protected]>
Date:   Fri Jan 14 18:50:54 2022 +0100

    can: tcan4x5x: regmap: fix max register value
    
    [ Upstream commit e59986de5ff701494e14c722b78b6e6d513e0ab5 ]
    
    The MRAM of the tcan4x5x has a size of 2K and starts at 0x8000. There
    are no further registers in the tcan4x5x making 0x87fc the biggest
    addressable register.
    
    This patch fixes the max register value of the regmap config from
    0x8ffc to 0x87fc.
    
    Fixes: 6e1caaf8ed22 ("can: tcan4x5x: fix max register value")
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 83f8dafcdc43a64217d20ac6da72bb66ee5bf659
Author: Michael Kelley <[email protected]>
Date:   Sun Jan 16 11:18:31 2022 -0800

    video: hyperv_fb: Fix validation of screen resolution
    
    [ Upstream commit 9ff5549b1d1d3c3a9d71220d44bd246586160f1d ]
    
    In the WIN10 version of the Synthetic Video protocol with Hyper-V,
    Hyper-V reports a list of supported resolutions as part of the protocol
    negotiation. The driver calculates the maximum width and height from
    the list of resolutions, and uses those maximums to validate any screen
    resolution specified in the video= option on the kernel boot line.
    
    This method of validation is incorrect. For example, the list of
    supported resolutions could contain 1600x1200 and 1920x1080, both of
    which fit in an 8 Mbyte frame buffer.  But calculating the max width
    and height yields 1920 and 1200, and 1920x1200 resolution does not fit
    in an 8 Mbyte frame buffer.  Unfortunately, this resolution is accepted,
    causing a kernel fault when the driver accesses memory outside the
    frame buffer.
    
    Instead, validate the specified screen resolution by calculating
    its size, and comparing against the frame buffer size.  Delete the
    code for calculating the max width and height from the list of
    resolutions, since these max values have no use.  Also add the
    frame buffer size to the info message to aid in understanding why
    a resolution might be rejected.
    
    Fixes: 67e7cdb4829d ("video: hyperv: hyperv_fb: Obtain screen resolution from Hyper-V host")
    Signed-off-by: Michael Kelley <[email protected]>
    Reviewed-by: Haiyang Zhang <[email protected]>
    Acked-by: Helge Deller <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 4284225cd8001e134f5cf533a7cd244bbb654d0f
Author: Wen Gu <[email protected]>
Date:   Sat Jan 22 17:43:09 2022 +0800

    net/smc: Transitional solution for clcsock race issue
    
    [ Upstream commit c0bf3d8a943b6f2e912b7c1de03e2ef28e76f760 ]
    
    We encountered a crash in smc_setsockopt() and it is caused by
    accessing smc->clcsock after clcsock was released.
    
     BUG: kernel NULL pointer dereference, address: 0000000000000020
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 0 P4D 0
     Oops: 0000 [#1] PREEMPT SMP PTI
     CPU: 1 PID: 50309 Comm: nginx Kdump: loaded Tainted: G E     5.16.0-rc4+ #53
     RIP: 0010:smc_setsockopt+0x59/0x280 [smc]
     Call Trace:
      <TASK>
      __sys_setsockopt+0xfc/0x190
      __x64_sys_setsockopt+0x20/0x30
      do_syscall_64+0x34/0x90
      entry_SYSCALL_64_after_hwframe+0x44/0xae
     RIP: 0033:0x7f16ba83918e
      </TASK>
    
    This patch tries to fix it by holding clcsock_release_lock and
    checking whether clcsock has already been released before access.
    
    In case that a crash of the same reason happens in smc_getsockopt()
    or smc_switch_to_fallback(), this patch also checkes smc->clcsock
    in them too. And the caller of smc_switch_to_fallback() will identify
    whether fallback succeeds according to the return value.
    
    Fixes: fd57770dd198 ("net/smc: wait for pending work before clcsock release_sock")
    Link: https://lore.kernel.org/lkml/[email protected]/T/
    Signed-off-by: Wen Gu <[email protected]>
    Acked-by: Karsten Graul <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit e3496f8127f1b97ded5fa1ace04210c2de0eace8
Author: Sukadev Bhattiprolu <[email protected]>
Date:   Fri Jan 21 18:59:20 2022 -0800

    ibmvnic: don't spin in tasklet
    
    [ Upstream commit 48079e7fdd0269d66b1d7d66ae88bd03162464ad ]
    
    ibmvnic_tasklet() continuously spins waiting for responses to all
    capability requests. It does this to avoid encountering an error
    during initialization of the vnic. However if there is a bug in the
    VIOS and we do not receive a response to one or more queries the
    tasklet ends up spinning continuously leading to hard lock ups.
    
    If we fail to receive a message from the VIOS it is reasonable to
    timeout the login attempt rather than spin indefinitely in the tasklet.
    
    Fixes: 249168ad07cd ("ibmvnic: Make CRQ interrupt tasklet wait for all capabilities crqs")
    Signed-off-by: Sukadev Bhattiprolu <[email protected]>
    Reviewed-by: Dany Madden <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit e6b36dec482ed35514573e97f0c4822c8e103314
Author: Sukadev Bhattiprolu <[email protected]>
Date:   Fri Jan 21 18:59:19 2022 -0800

    ibmvnic: init ->running_cap_crqs early
    
    [ Upstream commit 151b6a5c06b678687f64f2d9a99fd04d5cd32b72 ]
    
    We use ->running_cap_crqs to determine when the ibmvnic_tasklet() should
    send out the next protocol message type. i.e when we get back responses
    to all our QUERY_CAPABILITY CRQs we send out REQUEST_CAPABILITY crqs.
    Similiary, when we get responses to all the REQUEST_CAPABILITY crqs, we
    send out the QUERY_IP_OFFLOAD CRQ.
    
    We currently increment ->running_cap_crqs as we send out each CRQ and
    have the ibmvnic_tasklet() send out the next message type, when this
    running_cap_crqs count drops to 0.
    
    This assumes that all the CRQs of the current type were sent out before
    the count drops to 0. However it is possible that we send out say 6 CRQs,
    get preempted and receive all the 6 responses before we send out the
    remaining CRQs. This can result in ->running_cap_crqs count dropping to
    zero before all messages of the current type were sent and we end up
    sending the next protocol message too early.
    
    Instead initialize the ->running_cap_crqs upfront so the tasklet will
    only send the next protocol message after all responses are received.
    
    Use the cap_reqs local variable to also detect any discrepancy (either
    now or in future) in the number of capability requests we actually send.
    
    Currently only send_query_cap() is affected by this behavior (of sending
    next message early) since it is called from the worker thread (during
    reset) and from application thread (during ->ndo_open()) and they can be
    preempted. send_request_cap() is only called from the tasklet  which
    processes CRQ responses sequentially, is not be affected.  But to
    maintain the existing symmtery with send_query_capability() we update
    send_request_capability() also.
    
    Fixes: 249168ad07cd ("ibmvnic: Make CRQ interrupt tasklet wait for all capabilities crqs")
    Signed-off-by: Sukadev Bhattiprolu <[email protected]>
    Reviewed-by: Dany Madden <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit b521a4e1a8ef15f6130e6df0cc3ae37e658512ba
Author: Sukadev Bhattiprolu <[email protected]>
Date:   Fri Jan 21 18:59:18 2022 -0800

    ibmvnic: Allow extra failures before disabling
    
    [ Upstream commit db9f0e8bf79e6da7068b5818fea0ffd9d0d4b4da ]
    
    If auto-priority-failover (APF) is enabled and there are at least two
    backing devices of different priorities, some resets like fail-over,
    change-param etc can cause at least two back to back failovers. (Failover
    from high priority backing device to lower priority one and then back
    to the higher priority one if that is still functional).
    
    Depending on the timimg of the two failovers it is possible to trigger
    a "hard" reset and for the hard reset to fail due to failovers. When this
    occurs, the driver assumes that the network is unstable and disables the
    VNIC for a 60-second "settling time". This in turn can cause the ethtool
    command to fail with "No such device" while the vnic automatically recovers
    a little while later.
    
    Given that it's possible to have two back to back failures, allow for extra
    failures before disabling the vnic for the settling time.
    
    Fixes: f15fde9d47b8 ("ibmvnic: delay next reset if hard reset fails")
    Signed-off-by: Sukadev Bhattiprolu <[email protected]>
    Reviewed-by: Dany Madden <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit d501d0535309577d0412e9266879893eeaea09aa
Author: Jakub Kicinski <[email protected]>
Date:   Fri Jan 21 16:57:31 2022 -0800

    ipv4: fix ip option filtering for locally generated fragments
    
    [ Upstream commit 27a8caa59babb96c5890569e131bc0eb6d45daee ]
    
    During IP fragmentation we sanitize IP options. This means overwriting
    options which should not be copied with NOPs. Only the first fragment
    has the original, full options.
    
    ip_fraglist_prepare() copies the IP header and options from previous
    fragment to the next one. Commit 19c3401a917b ("net: ipv4: place control
    buffer handling away from fragmentation iterators") moved sanitizing
    options before ip_fraglist_prepare() which means options are sanitized
    and then overwritten again with the old values.
    
    Fixing this is not enough, however, nor did the sanitization work
    prior to aforementioned commit.
    
    ip_options_fragment() (which does the sanitization) uses ipcb->opt.optlen
    for the length of the options. ipcb->opt of fragments is not populated
    (it's 0), only the head skb has the state properly built. So even when
    called at the right time ip_options_fragment() does nothing. This seems
    to date back all the way to v2.5.44 when the fast path for pre-fragmented
    skbs had been introduced. Prior to that ip_options_build() would have been
    called for every fragment (in fact ever since v2.5.44 the fragmentation
    handing in ip_options_build() has been dead code, I'll clean it up in
    -next).
    
    In the original patch (see Link) caixf mentions fixing the handling
    for fragments other than the second one, but I'm not sure how _any_
    fragment could have had their options sanitized with the code
    as it stood.
    
    Tested with python (MTU on lo lowered to 1000 to force fragmentation):
    
      import socket
      s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
      s.setsockopt(socket.IPPROTO_IP, socket.IP_OPTIONS,
                   bytearray([7,4,5,192, 20|0x80,4,1,0]))
      s.sendto(b'1'*2000, ('127.0.0.1', 1234))
    
    Before:
    
    IP (tos 0x0, ttl 64, id 1053, offset 0, flags [+], proto UDP (17), length 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
        localhost.36500 > localhost.search-agent: UDP, length 2000
    IP (tos 0x0, ttl 64, id 1053, offset 968, flags [+], proto UDP (17), length 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
        localhost > localhost: udp
    IP (tos 0x0, ttl 64, id 1053, offset 1936, flags [none], proto UDP (17), length 100, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
        localhost > localhost: udp
    
    After:
    
    IP (tos 0x0, ttl 96, id 42549, offset 0, flags [+], proto UDP (17), length 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
        localhost.51607 > localhost.search-agent: UDP, bad length 2000 > 960
    IP (tos 0x0, ttl 96, id 42549, offset 968, flags [+], proto UDP (17), length 996, options (NOP,NOP,NOP,NOP,RA value 256))
        localhost > localhost: udp
    IP (tos 0x0, ttl 96, id 42549, offset 1936, flags [none], proto UDP (17), length 100, options (NOP,NOP,NOP,NOP,RA value 256))
        localhost > localhost: udp
    
    RA (20 | 0x80) is now copied as expected, RR (7) is "NOPed out".
    
    Link: https://lore.kernel.org/netdev/[email protected]/
    Fixes: 19c3401a917b ("net: ipv4: place control buffer handling away from fragmentation iterators")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: caixf <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit fa4ad064a6bd49208221df5e62adf27b426d1720
Author: Athira Rajeev <[email protected]>
Date:   Sat Jan 22 09:04:29 2022 +0530

    powerpc/perf: Fix power_pmu_disable to call clear_pmi_irq_pending only if PMI is pending
    
    [ Upstream commit fb6433b48a178d4672cb26632454ee0b21056eaa ]
    
    Running selftest with CONFIG_PPC_IRQ_SOFT_MASK_DEBUG enabled in kernel
    triggered below warning:
    
    [  172.851380] ------------[ cut here ]------------
    [  172.851391] WARNING: CPU: 8 PID: 2901 at arch/powerpc/include/asm/hw_irq.h:246 power_pmu_disable+0x270/0x280
    [  172.851402] Modules linked in: dm_mod bonding nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink sunrpc xfs libcrc32c pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables ext4 mbcache jbd2 sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp fuse
    [  172.851442] CPU: 8 PID: 2901 Comm: lost_exception_ Not tainted 5.16.0-rc5-03218-g798527287598 #2
    [  172.851451] NIP:  c00000000013d600 LR: c00000000013d5a4 CTR: c00000000013b180
    [  172.851458] REGS: c000000017687860 TRAP: 0700   Not tainted  (5.16.0-rc5-03218-g798527287598)
    [  172.851465] MSR:  8000000000029033 <SF,EE,ME,IR,DR,RI,LE>  CR: 48004884  XER: 20040000
    [  172.851482] CFAR: c00000000013d5b4 IRQMASK: 1
    [  172.851482] GPR00: c00000000013d5a4 c000000017687b00 c000000002a10600 0000000000000004
    [  172.851482] GPR04: 0000000082004000 c0000008ba08f0a8 0000000000000000 00000008b7ed0000
    [  172.851482] GPR08: 00000000446194f6 0000000000008000 c00000000013b118 c000000000d58e68
    [  172.851482] GPR12: c00000000013d390 c00000001ec54a80 0000000000000000 0000000000000000
    [  172.851482] GPR16: 0000000000000000 0000000000000000 c000000015d5c708 c0000000025396d0
    [  172.851482] GPR20: 0000000000000000 0000000000000000 c00000000a3bbf40 0000000000000003
    [  172.851482] GPR24: 0000000000000000 c0000008ba097400 c0000000161e0d00 c00000000a3bb600
    [  172.851482] GPR28: c000000015d5c700 0000000000000001 0000000082384090 c0000008ba0020d8
    [  172.851549] NIP [c00000000013d600] power_pmu_disable+0x270/0x280
    [  172.851557] LR [c00000000013d5a4] power_pmu_disable+0x214/0x280
    [  172.851565] Call Trace:
    [  172.851568] [c000000017687b00] [c00000000013d5a4] power_pmu_disable+0x214/0x280 (unreliable)
    [  172.851579] [c000000017687b40] [c0000000003403ac] perf_pmu_disable+0x4c/0x60
    [  172.851588] [c000000017687b60] [c0000000003445e4] __perf_event_task_sched_out+0x1d4/0x660
    [  172.851596] [c000000017687c50] [c000000000d1175c] __schedule+0xbcc/0x12a0
    [  172.851602] [c000000017687d60] [c000000000d11ea8] schedule+0x78/0x140
    [  172.851608] [c000000017687d90] [c0000000001a8080] sys_sched_yield+0x20/0x40
    [  172.851615] [c000000017687db0] [c0000000000334dc] system_call_exception+0x18c/0x380
    [  172.851622] [c000000017687e10] [c00000000000c74c] system_call_common+0xec/0x268
    
    The warning indicates that MSR_EE being set(interrupt enabled) when
    there was an overflown PMC detected. This could happen in
    power_pmu_disable since it runs under interrupt soft disable
    condition ( local_irq_save ) and not with interrupts hard disabled.
    commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear
    pending PMI before resetting an overflown PMC") intended to clear
    PMI pending bit in Paca when disabling the PMU. It could happen
    that PMC gets overflown while code is in power_pmu_disable
    callback function. Hence add a check to see if PMI pending bit
    is set in Paca before clearing it via clear_pmi_pending.
    
    Fixes: 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC")
    Reported-by: Sachin Sant <[email protected]>
    Signed-off-by: Athira Rajeev <[email protected]>
    Tested-by: Sachin Sant <[email protected]>
    Reviewed-by: Nicholas Piggin <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit 1f679a6e19727dc57f528639db423abbdb9348b6
Author: Dan Carpenter <[email protected]>
Date:   Fri Jan 21 14:55:43 2022 +0300

    hwmon: (adt7470) Prevent divide by zero in adt7470_fan_write()
    
    [ Upstream commit c1ec0cabc36718efc7fe8b4157d41b82d08ec1d2 ]
    
    The "val" variable is controlled by the user and comes from
    hwmon_attr_store().  The FAN_RPM_TO_PERIOD() macro divides by "val"
    so a zero will crash the system.  Check for that and return -EINVAL.
    Negatives are also invalid so return -EINVAL for those too.
    
    Fixes: fc958a61ff6d ("hwmon: (adt7470) Convert to devm_hwmon_device_register_with_info API")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a7d3b89a7095b167ab2c49fd534dc69be38549ae
Author: Guenter Roeck <[email protected]>
Date:   Mon Jan 10 23:23:31 2022 -0800

    hwmon: (lm90) Fix sysfs and udev notifications
    
    [ Upstream commit d379880d9adb9f1ada3f1266aa49ea2561328e08 ]
    
    sysfs and udev notifications need to be sent to the _alarm
    attributes, not to the value attributes.
    
    Fixes: 94dbd23ed88c ("hwmon: (lm90) Use hwmon_notify_event()")
    Cc: Dmitry Osipenko <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 52e143f68fcb2252113ae3b5936b2ac7d4303a5d
Author: Guenter Roeck <[email protected]>
Date:   Fri Jan 7 11:05:23 2022 -0800

    hwmon: (lm90) Mark alert as broken for MAX6654
    
    [ Upstream commit a53fff96f35763d132a36c620b183fdf11022d7a ]
    
    Experiments with MAX6654 show that its alert function is broken,
    similar to other chips supported by the lm90 driver. Mark it accordingly.
    
    Fixes: 229d495d8189 ("hwmon: (lm90) Add max6654 support to lm90 driver")
    Cc: Josh Lehan <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 6d1e32218578ea6314c874b602235bb178896354
Author: Guenter Roeck <[email protected]>
Date:   Sat Jan 8 11:37:19 2022 -0800

    hwmon: (lm90) Re-enable interrupts after alert clears
    
    [ Upstream commit bc341a1a98827925082e95db174734fc8bd68af6 ]
    
    If alert handling is broken, interrupts are disabled after an alert and
    re-enabled after the alert clears. However, if there is an interrupt
    handler, this does not apply if alerts were originally disabled and enabled
    when the driver was loaded. In that case, interrupts will stay disabled
    after an alert was handled though the alert handler even after the alert
    condition clears. Address the situation by always re-enabling interrupts
    after the alert condition clears if there is an interrupt handler.
    
    Fixes: 2abdc357c55d9 ("hwmon: (lm90) Unmask hardware interrupt")
    Cc: Dmitry Osipenko <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 72f50424b0a1806d81a30110a3809655374b8277
Author: Yanming Liu <[email protected]>
Date:   Thu Jan 20 04:20:52 2022 +0800

    Drivers: hv: balloon: account for vmbus packet header in max_pkt_size
    
    [ Upstream commit 96d9d1fa5cd505078534113308ced0aa56d8da58 ]
    
    Commit adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V
    out of the ring buffer") introduced a notion of maximum packet size in
    vmbus channel and used that size to initialize a buffer holding all
    incoming packet along with their vmbus packet header. hv_balloon uses
    the default maximum packet size VMBUS_DEFAULT_MAX_PKT_SIZE which matches
    its maximum message size, however vmbus_open expects this size to also
    include vmbus packet header. This leads to 4096 bytes
    dm_unballoon_request messages being truncated to 4080 bytes. When the
    driver tries to read next packet it starts from a wrong read_index,
    receives garbage and prints a lot of "Unhandled message: type:
    <garbage>" in dmesg.
    
    Allocate the buffer with HV_HYP_PAGE_SIZE more bytes to make room for
    the header.
    
    Fixes: adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V out of the ring buffer")
    Suggested-by: Michael Kelley (LINUX) <[email protected]>
    Suggested-by: Andrea Parri (Microsoft) <[email protected]>
    Signed-off-by: Yanming Liu <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Reviewed-by: Andrea Parri (Microsoft) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit fe4214a07e0b53d2af711f57519e33739c5df23f
Author: Miaoqian Lin <[email protected]>
Date:   Thu Jan 20 10:10:25 2022 +0000

    block: fix memory leak in disk_register_independent_access_ranges
    
    [ Upstream commit 83114df32ae779df57e0af99a8ba6c3968b2ba3d ]
    
    kobject_init_and_add() takes reference even when it fails.
    According to the doc of kobject_init_and_add()
    
       If this function returns an error, kobject_put() must be called to
       properly clean up the memory associated with the object.
    
    Fix this issue by adding kobject_put().
    Callback function blk_ia_ranges_sysfs_release() in kobject_put()
    can handle the pointer "iars" properly.
    
    Fixes: a2247f19ee1c ("block: Add independent access ranges support")
    Signed-off-by: Miaoqian Lin <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit d7462bf68b187f1d27482d52c214d23bc386cd7a
Author: Dylan Yudaken <[email protected]>
Date:   Fri Jan 21 04:38:56 2022 -0800

    io_uring: fix bug in slow unregistering of nodes
    
    [ Upstream commit b36a2050040b2d839bdc044007cdd57101d7f881 ]
    
    In some cases io_rsrc_ref_quiesce will call io_rsrc_node_switch_start,
    and then immediately flush the delayed work queue &ctx->rsrc_put_work.
    
    However the percpu_ref_put does not immediately destroy the node, it
    will be called asynchronously via RCU. That ends up with
    io_rsrc_node_ref_zero only being called after rsrc_put_work has been
    flushed, and so the process ends up sleeping for 1 second unnecessarily.
    
    This patch executes the put code immediately if we are busy
    quiescing.
    
    Fixes: 4a38aed2a0a7 ("io_uring: batch reap of dead file registrations")
    Signed-off-by: Dylan Yudaken <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 6ef46e116965657d0fa76e0a6fbd0f8532d9fbff
Author: Mihai Carabas <[email protected]>
Date:   Wed Jan 19 18:14:27 2022 +0200

    efi/libstub: arm64: Fix image check alignment at entry
    
    [ Upstream commit e9b7c3a4263bdcfd31bc3d03d48ce0ded7a94635 ]
    
    The kernel is aligned at SEGMENT_SIZE and this is the size populated in the PE
    headers:
    
    arch/arm64/kernel/efi-header.S: .long   SEGMENT_ALIGN // SectionAlignment
    
    EFI_KIMG_ALIGN is defined as: (SEGMENT_ALIGN > THREAD_ALIGN ? SEGMENT_ALIGN :
    THREAD_ALIGN)
    
    So it depends on THREAD_ALIGN. On newer builds this message started to appear
    even though the loader is taking into account the PE header (which is stating
    SEGMENT_ALIGN).
    
    Fixes: c32ac11da3f8 ("efi/libstub: arm64: Double check image alignment at entry")
    Signed-off-by: Mihai Carabas <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit db3d197219139c6804d2625331dc9a0aedcb9aa5
Author: David Howells <[email protected]>
Date:   Fri Jan 21 23:12:58 2022 +0000

    rxrpc: Adjust retransmission backoff
    
    [ Upstream commit 2c13c05c5ff4b9fc907b07f7311821910ebaaf8a ]
    
    Improve retransmission backoff by only backing off when we retransmit data
    packets rather than when we set the lost ack timer.
    
    To this end:
    
     (1) In rxrpc_resend(), use rxrpc_get_rto_backoff() when setting the
         retransmission timer and only tell it that we are retransmitting if we
         actually have things to retransmit.
    
         Note that it's possible for the retransmission algorithm to race with
         the processing of a received ACK, so we may see no packets needing
         retransmission.
    
     (2) In rxrpc_send_data_packet(), don't bump the backoff when setting the
         ack_lost_at timer, as it may then get bumped twice.
    
    With this, when looking at one particular packet, the retransmission
    intervals were seen to be 1.5ms, 2ms, 3ms, 5ms, 9ms, 17ms, 33ms, 71ms,
    136ms, 264ms, 544ms, 1.088s, 2.1s, 4.2s and 8.3s.
    
    Fixes: c410bf01933e ("rxrpc: Fix the excessive initial retransmission timeout")
    Suggested-by: Marc Dionne <[email protected]>
    Signed-off-by: David Howells <[email protected]>
    Reviewed-by: Marc Dionne <[email protected]>
    Tested-by: Marc Dionne <[email protected]>
    cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]org.uk/
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 52599359c0dab74a72de9ebb05f1a78453df3d84
Author: Kiran Kumar K <[email protected]>
Date:   Fri Jan 21 12:04:47 2022 +0530

    octeontx2-af: Add KPU changes to parse NGIO as separate layer
    
    [ Upstream commit 745166fcf01cecc4f5ff3defc6586868349a43f9 ]
    
    With current KPU profile NGIO is being parsed along with CTAG as
    a single layer. Because of this MCAM/ntuple rules installed with
    ethertype as 0x8842 are not being hit. Adding KPU profile changes
    to parse NGIO in separate ltype and CTAG in separate ltype.
    
    Fixes: f9c49be90c05 ("octeontx2-af: Update the default KPU profile and fixes")
    Signed-off-by: Kiran Kumar K <[email protected]>
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit ecf6ec4076ae7199bd846c9bf8bbf09757709f62
Author: Subbaraya Sundeep <[email protected]>
Date:   Fri Jan 21 12:04:46 2022 +0530

    octeontx2-pf: Forward error codes to VF
    
    [ Upstream commit a8db854be28622a2477cb21cdf7f829adbb2c42d ]
    
    PF forwards its VF messages to AF and corresponding
    replies from AF to VF. AF sets proper error code in the
    replies after processing message requests. Currently PF
    checks the error codes in replies and sends invalid
    message to VF. This way VF lacks the information of
    error code set by AF for its messages. This patch
    changes that such that PF simply forwards AF replies
    so that VF can handle error codes.
    
    Fixes: d424b6c02415 ("octeontx2-pf: Enable SRIOV and added VF mbox handling")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a7e3a731dfbaffe4328430682f44429c70d5610c
Author: Geetha sowjanya <[email protected]>
Date:   Fri Jan 21 12:04:45 2022 +0530

    octeontx2-af: cn10k: Do not enable RPM loopback for LPC interfaces
    
    [ Upstream commit df66b6ebc5dcf7253e35a640b9ec4add54195c25 ]
    
    Internal looback is not supported to low rate LPCS interface like
    SGMII/QSGMII. Hence don't allow to enable for such interfaces.
    
    Fixes: 3ad3f8f93c81 ("octeontx2-af: cn10k: MAC internal loopback support")
    Signed-off-by: Geetha sowjanya <[email protected]>
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 97008a3a8622e58fbfa7ddf681cd417010e4885b
Author: Geetha sowjanya <[email protected]>
Date:   Fri Jan 21 12:04:44 2022 +0530

    octeontx2-af: Increase link credit restore polling timeout
    
    [ Upstream commit 1581d61b42d985cefe7b71eea67ab3bfcbf34d0f ]
    
    It's been observed that sometimes link credit restore takes
    a lot of time than the current timeout. This patch increases
    the default timeout value and return the proper error value
    on failure.
    
    Fixes: 1c74b89171c3 ("octeontx2-af: Wait for TX link idle for credits change")
    Signed-off-by: Geetha sowjanya <[email protected]>
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 97d7446c1612d7dcd194bb0d1ef5e3ce5b89c3b8
Author: Geetha sowjanya <[email protected]>
Date:   Fri Jan 21 12:04:43 2022 +0530

    octeontx2-pf: cn10k: Ensure valid pointers are freed to aura
    
    [ Upstream commit c5d731c54a17677939bd59ee8be4ed74d7485ba4 ]
    
    While freeing SQB pointers to aura, driver first memcpy to
    target address and then triggers lmtst operation to free pointer
    to the aura. We need to ensure(by adding dmb barrier)that memcpy
    is finished before pointers are freed to the aura. This patch also
    adds the missing sq context structure entry in debugfs.
    
    Fixes: ef6c8da71eaf ("octeontx2-pf: cn10K: Reserve LMTST lines per core")
    Signed-off-by: Geetha sowjanya <[email protected]>
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 59a3393f74665fdf3ab942af7a5937128b7ef394
Author: Geetha sowjanya <[email protected]>
Date:   Fri Jan 21 12:04:42 2022 +0530

    octeontx2-af: cn10k: Use appropriate register for LMAC enable
    
    [ Upstream commit fae80edeafbbba5ef9a0423aa5e5515518626433 ]
    
    CN10K platforms uses RPM(0..2)_MTI_MAC100(0..3)_COMMAND_CONFIG
    register for lmac TX/RX enable whereas CN9xxx platforms use
    CGX_CMRX_CONFIG register. This config change was missed when
    adding support for CN10K RPM.
    
    Fixes: 91c6945ea1f9 ("octeontx2-af: cn10k: Add RPM MAC support")
    Signed-off-by: Geetha sowjanya <[email protected]>
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 7c1f8357870ea711364896c71abba7ac0554d977
Author: Geetha sowjanya <[email protected]>
Date:   Fri Jan 21 12:04:41 2022 +0530

    octeontx2-af: Retry until RVU block reset complete
    
    [ Upstream commit 03ffbc9914bd1130fba464f0a41c01372e5fc359 ]
    
    Few RVU blocks like SSO require more time for reset on some
    silicons. Hence retrying the block reset until success.
    
    Fixes: c0fa2cff8822c ("octeontx2-af: Handle return value in block reset")
    Signed-off-by: Geetha sowjanya <[email protected]>
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 7e32f747248db26aad6fed4b59a86e89fbb8395a
Author: Sunil Goutham <[email protected]>
Date:   Fri Jan 21 12:04:40 2022 +0530

    octeontx2-af: Fix LBK backpressure id count
    
    [ Upstream commit 00bfe94e388fe12bfd0d4f6361b1b1343374ff5b ]
    
    In rvu_nix_get_bpid() lbk_bpid_cnt is being read from
    wrong register. Due to this backpressure enable is failing
    for LBK VF32 onwards. This patch fixes that.
    
    Fixes: fe1939bb2340 ("octeontx2-af: Add SDP interface support")
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 4d22bc49ffd39a6a498d7a84aa70158effe56570
Author: Subbaraya Sundeep <[email protected]>
Date:   Fri Jan 21 12:04:39 2022 +0530

    octeontx2-af: Do not fixup all VF action entries
    
    [ Upstream commit d225c449ab2be25273a3674f476c6c0b57c50254 ]
    
    AF modifies all the rules destined for VF to use
    the action same as default RSS action. This fixup
    was needed because AF only installs default rules with
    RSS action. But the action in rules installed by a PF
    for its VFs should not be changed by this fixup.
    This is because action can be drop or direct to
    queue as specified by user(ntuple filters).
    This patch fixes that problem.
    
    Fixes: 967db3529eca ("octeontx2-af: add support for multicast/promisc packet")
    Signed-off-by: Subbaraya Sundeep <[email protected]>
    Signed-off-by: Naveen Mamindlapalli <[email protected]>
    Signed-off-by: Sunil Goutham <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit cb2fab10fc5e7a3aa1bb0a68a3abdcf3e37852af
Author: Marek Behún <[email protected]>
Date:   Wed Jan 19 17:27:48 2022 +0100

    phylib: fix potential use-after-free
    
    [ Upstream commit cbda1b16687580d5beee38273f6241ae3725960c ]
    
    Commit bafbdd527d56 ("phylib: Add device reset GPIO support") added call
    to phy_device_reset(phydev) after the put_device() call in phy_detach().
    
    The comment before the put_device() call says that the phydev might go
    away with put_device().
    
    Fix potential use-after-free by calling phy_device_reset() before
    put_device().
    
    Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support")
    Signed-off-by: Marek Behún <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit d217c3248219f1070c6e9c69617831cb6bcc3885
Author: Yuji Ishikawa <[email protected]>
Date:   Wed Jan 19 13:46:48 2022 +0900

    net: stmmac: dwmac-visconti: Fix clock configuration for RMII mode
    
    [ Upstream commit 0959bc4bd4206433ed101a1332a23e93ad16ec77 ]
    
    Bit pattern of the ETHER_CLOCK_SEL register for RMII/MII mode should be fixed.
    Also, some control bits should be modified with a specific sequence.
    
    Fixes: b38dd98ff8d0 ("net: stmmac: Add Toshiba Visconti SoCs glue driver")
    Signed-off-by: Yuji Ishikawa <[email protected]>
    Reviewed-by: Nobuhiro Iwamatsu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 1b5bf52e20deb168cfc9a7599c6d8f8edf884b65
Author: Yuji Ishikawa <[email protected]>
Date:   Wed Jan 19 13:46:47 2022 +0900

    net: stmmac: dwmac-visconti: Fix bit definitions for ETHER_CLK_SEL
    
    [ Upstream commit 1ba1a4a90fa416a6f389206416c5f488cf8b1543 ]
    
    just 0 should be used to represent cleared bits
    
    * ETHER_CLK_SEL_DIV_SEL_20
    * ETHER_CLK_SEL_TX_CLK_EXT_SEL_IN
    * ETHER_CLK_SEL_RX_CLK_EXT_SEL_IN
    * ETHER_CLK_SEL_TX_CLK_O_TX_I
    * ETHER_CLK_SEL_RMII_CLK_SEL_IN
    
    Fixes: b38dd98ff8d0 ("net: stmmac: Add Toshiba Visconti SoCs glue driver")
    Signed-off-by: Yuji Ishikawa <[email protected]>
    Reviewed-by: Nobuhiro Iwamatsu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 529daf17749043eda74195ff72e72e040b76a7e9
Author: Moshe Tal <[email protected]>
Date:   Thu Jan 20 11:55:50 2022 +0200

    ethtool: Fix link extended state for big endian
    
    [ Upstream commit e2f08207c558bc0bc8abaa557cdb29bad776ac7b ]
    
    The link extended sub-states are assigned as enum that is an integer
    size but read from a union as u8, this is working for small values on
    little endian systems but for big endian this always give 0. Fix the
    variable in the union to match the enum size.
    
    Fixes: ecc31c60240b ("ethtool: Add link extended state")
    Signed-off-by: Moshe Tal <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Tested-by: Ido Schimmel <[email protected]>
    Reviewed-by: Gal Pressman <[email protected]>
    Reviewed-by: Amit Cohen <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit e61fe7d113625838fecdb6cd1b4599018947d2b6
Author: Robert Hancock <[email protected]>
Date:   Tue Jan 18 15:52:43 2022 -0600

    net: phy: broadcom: hook up soft_reset for BCM54616S
    
    [ Upstream commit d15c7e875d44367005370e6a82e8f3a382a04f9b ]
    
    A problem was encountered with the Bel-Fuse 1GBT-SFP05 SFP module (which
    is a 1 Gbps copper module operating in SGMII mode with an internal
    BCM54616S PHY device) using the Xilinx AXI Ethernet MAC core, where the
    module would work properly on the initial insertion or boot of the
    device, but after the device was rebooted, the link would either only
    come up at 100 Mbps speeds or go up and down erratically.
    
    I found no meaningful changes in the PHY configuration registers between
    the working and non-working boots, but the status registers seemed to
    have a lot of error indications set on the SERDES side of the device on
    the non-working boot. I suspect the problem is that whatever happens on
    the SGMII link when the device is rebooted and the FPGA logic gets
    reloaded ends up putting the module's onboard PHY into a bad state.
    
    Since commit 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
    the genphy_soft_reset call is not made automatically by the PHY core
    unless the callback is explicitly specified in the driver structure. For
    most of these Broadcom devices, there is probably a hardware reset that
    gets asserted to reset the PHY during boot, however for SFP modules
    (where the BCM54616S is commonly found) no such reset line exists, so if
    the board keeps the SFP cage powered up across a reboot, it will end up
    with no reset occurring during reboots.
    
    Hook up the genphy_soft_reset callback for BCM54616S to ensure that a
    PHY reset is performed before the device is initialized. This appears to
    fix the issue with erratic operation after a reboot with this SFP
    module.
    
    Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
    Signed-off-by: Robert Hancock <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 12fc88eb756dc3d15b23a1c641758cff3260a9c5
Author: Vincent Guittot <[email protected]>
Date:   Tue Jan 11 14:46:56 2022 +0100

    sched/pelt: Relax the sync of util_sum with util_avg
    
    [ Upstream commit 98b0d890220d45418cfbc5157b3382e6da5a12ab ]
    
    Rick reported performance regressions in bugzilla because of cpu frequency
    being lower than before:
        https://bugzilla.kernel.org/show_bug.cgi?id=215045
    
    He bisected the problem to:
    commit 1c35b07e6d39 ("sched/fair: Ensure _sum and _avg values stay consistent")
    
    This commit forces util_sum to be synced with the new util_avg after
    removing the contribution of a task and before the next periodic sync. By
    doing so util_sum is rounded to its lower bound and might lost up to
    LOAD_AVG_MAX-1 of accumulated contribution which has not yet been
    reflected in util_avg.
    
    Instead of always setting util_sum to the low bound of util_avg, which can
    significantly lower the utilization of root cfs_rq after propagating the
    change down into the hierarchy, we revert the change of util_sum and
    propagate the difference.
    
    In addition, we also check that cfs's util_sum always stays above the
    lower bound for a given util_avg as it has been observed that
    sched_entity's util_sum is sometimes above cfs one.
    
    Fixes: 1c35b07e6d39 ("sched/fair: Ensure _sum and _avg values stay consistent")
    Reported-by: Rick Yiu <[email protected]>
    Signed-off-by: Vincent Guittot <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Dietmar Eggemann <[email protected]>
    Tested-by: Sachin Sant <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit 04ae6dc63a6ab06f8c1d6bc398d5227ce476db8f
Author: Peter Zijlstra <[email protected]>
Date:   Mon Dec 20 13:19:52 2021 +0100

    perf: Fix perf_event_read_local() time
    
    [ Upstream commit 09f5e7dc7ad705289e1b1ec065439aa3c42951c4 ]
    
    Time readers that cannot take locks (due to NMI etc..) currently make
    use of perf_event::shadow_ctx_time, which, for that event gives:
    
      time' = now + (time - timestamp)
    
    or, alternatively arranged:
    
      time' = time + (now - timestamp)
    
    IOW, the progression of time since the last time the shadow_ctx_time
    was updated.
    
    There's problems with this:
    
     A) the shadow_ctx_time is per-event, even though the ctx_time it
        reflects is obviously per context. The direct concequence of this
        is that the context needs to iterate all events all the time to
        keep the shadow_ctx_time in sync.
    
     B) even with the prior point, the context itself might not be active
        meaning its time should not advance to begin with.
    
     C) shadow_ctx_time isn't consistently updated when ctx_time is
    
    There are 3 users of this stuff, that suffer differently from this:
    
     - calc_timer_values()
       - perf_output_read()
       - perf_event_update_userpage()       /* A */
    
     - perf_event_read_local()              /* A,B */
    
    In particular, perf_output_read() doesn't suffer at all, because it's
    sample driven and hence only relevant when the event is actually
    running.
    
    This same was supposed to be true for perf_event_update_userpage(),
    after all self-monitoring implies the context is active *HOWEVER*, as
    per commit f79256532682 ("perf/core: fix userpage->time_enabled of
    inactive events") this goes wrong when combined with counter
    overcommit, in that case those events that do not get scheduled when
    the context becomes active (task events typically) miss out on the
    EVENT_TIME update and ENABLED time is inflated (for a little while)
    with the time the context was inactive. Once the event gets rotated
    in, this gets corrected, leading to a non-monotonic timeflow.
    
    perf_event_read_local() made things even worse, it can request time at
    any point, suffering all the problems perf_event_update_userpage()
    does and more. Because while perf_event_update_userpage() is limited
    by the context being active, perf_event_read_local() users have no
    such constraint.
    
    Therefore, completely overhaul things and do away with
    perf_event::shadow_ctx_time. Instead have regular context time updates
    keep track of this offset directly and provide perf_event_time_now()
    to complement perf_event_time().
    
    perf_event_time_now() will, in adition to being context wide, also
    take into account if the context is active. For inactive context, it
    will not advance time.
    
    This latter property means the cgroup perf_cgroup_info context needs
    to grow addition state to track this.
    
    Additionally, since all this is strictly per-cpu, we can use barrier()
    to order context activity vs context time.
    
    Fixes: 7d9285e82db5 ("perf/bpf: Extend the perf_event_read_local() interface, a.k.a. "bpf: perf event change needed for subsequent bpf helpers"")
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Tested-by: Song Liu <[email protected]>
    Tested-by: Namhyung Kim <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit d8cd36a108fa7ee31fee9d61c30cbf5a9965f640
Author: Nicholas Piggin <[email protected]>
Date:   Mon Jan 17 23:44:03 2022 +1000

    powerpc/64s: Mask SRR0 before checking against the masked NIP
    
    [ Upstream commit aee101d7b95a03078945681dd7f7ea5e4a1e7686 ]
    
    Commit 314f6c23dd8d ("powerpc/64s: Mask NIP before checking against
    SRR0") masked off the low 2 bits of the NIP value in the interrupt
    stack frame in case they are non-zero and mis-compare against a SRR0
    register value of a CPU which always reads back 0 from the 2 low bits
    which are reserved.
    
    This now causes the opposite problem that an implementation which does
    implement those bits in SRR0 will mis-compare against the masked NIP
    value in which they have been cleared. QEMU is one such implementation,
    and this is allowed by the architecture.
    
    This can be triggered by sigfuz by setting low bits of PT_NIP in the
    signal context.
    
    Fix this for now by masking the SRR0 bits as well. Cleaner is probably
    to sanitise these values before putting them in registers or stack, but
    this is the quick and backportable fix.
    
    Fixes: 314f6c23dd8d ("powerpc/64s: Mask NIP before checking against SRR0")
    Signed-off-by: Nicholas Piggin <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit d21caf9023bb2d1d74afa24e17d4edd3480ccd1a
Author: Randy Dunlap <[email protected]>
Date:   Fri Jan 14 17:13:38 2022 -0800

    remoteproc: qcom: q6v5: fix service routines build errors
    
    [ Upstream commit eee412e968f7b950564880bc6a7a9f00f49034da ]
    
    When CONFIG_QCOM_AOSS_QMP=m and CONFIG_QCOM_Q6V5_MSS=y, the builtin
    driver cannot call into the loadable module's low-level service
    functions. Trying to build with that config combo causes linker errors.
    
    There are two problems here. First, drivers/remoteproc/qcom_q6v5.c
    should #include <linux/soc/qcom/qcom_aoss.h> for the definitions of
    the service functions, depending on whether CONFIG_QCOM_AOSS_QMP is
    set/enabled or not. Second, the qcom remoteproc drivers should depend
    on QCOM_AOSS_QMP iff it is enabled (=y or =m) so that the qcom
    remoteproc drivers can be built properly.
    
    This prevents these build errors:
    
    aarch64-linux-ld: drivers/remoteproc/qcom_q6v5.o: in function `q6v5_load_state_toggle':
    qcom_q6v5.c:(.text+0xc4): undefined reference to `qmp_send'
    aarch64-linux-ld: drivers/remoteproc/qcom_q6v5.o: in function `qcom_q6v5_deinit':
    (.text+0x2e4): undefined reference to `qmp_put'
    aarch64-linux-ld: drivers/remoteproc/qcom_q6v5.o: in function `qcom_q6v5_init':
    (.text+0x778): undefined reference to `qmp_get'
    aarch64-linux-ld: (.text+0x7d8): undefined reference to `qmp_put'
    
    Fixes: c1fe10d238c0 ("remoteproc: qcom: q6v5: Use qmp_send to update co-processor load state")
    Signed-off-by: Randy Dunlap <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Cc: Bjorn Andersson <[email protected]>
    Cc: Mathieu Poirier <[email protected]>
    Cc: [email protected]
    Cc: Sibi Sankar <[email protected]>
    Cc: Stephen Boyd <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit 47cf5bfa8d2ba569bd988c31266893d6b4503ff2
Author: Florian Westphal <[email protected]>
Date:   Thu Jan 13 21:37:58 2022 +0100

    netfilter: conntrack: don't increment invalid counter on NF_REPEAT
    
    [ Upstream commit 830af2eba40327abec64325a5b08b1e85c37a2e0 ]
    
    The packet isn't invalid, REPEAT means we're trying again after cleaning
    out a stale connection, e.g. via tcp tracker.
    
    This caused increases of invalid stat counter in a test case involving
    frequent connection reuse, even though no packet is actually invalid.
    
    Fixes: 56a62e2218f5 ("netfilter: conntrack: fix NF_REPEAT handling")
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit aaccfeeee1630b155e8ff0d6c449d3de1ef86e73
Author: Naveen N. Rao <[email protected]>
Date:   Thu Jan 6 17:15:12 2022 +0530

    powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06
    
    [ Upstream commit 3f5f766d5f7f95a69a630da3544a1a0cee1cdddf ]
    
    Johan reported the below crash with test_bpf on ppc64 e5500:
    
      test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1
      Oops: Exception in kernel mode, sig: 4 [#1]
      BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500
      Modules linked in: test_bpf(+)
      CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1
      NIP:  8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18
      REGS: c0000000032d3420 TRAP: 0700   Not tainted (5.14.0-03771-g98c2059e008a-dirty)
      MSR:  0000000080089000 <EE,ME>  CR: 88002822  XER: 20000000 IRQMASK: 0
      <...>
      NIP [8000000000061c3c] 0x8000000000061c3c
      LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf]
      Call Trace:
       .__run_one+0x60/0x17c [test_bpf] (unreliable)
       .test_bpf_init+0x6a8/0xdc8 [test_bpf]
       .do_one_initcall+0x6c/0x28c
       .do_init_module+0x68/0x28c
       .load_module+0x2460/0x2abc
       .__do_sys_init_module+0x120/0x18c
       .system_call_exception+0x110/0x1b8
       system_call_common+0xf0/0x210
      --- interrupt: c00 at 0x101d0acc
      <...>
      ---[ end trace 47b2bf19090bb3d0 ]---
    
      Illegal instruction
    
    The illegal instruction turned out to be 'ldbrx' emitted for
    BPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use of
    the same and implement an alternative approach for older processors.
    
    Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
    Reported-by: Johan Almbladh <[email protected]>
    Signed-off-by: Naveen N. Rao <[email protected]>
    Tested-by: Johan Almbladh <[email protected]>
    Acked-by: Johan Almbladh <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/d1e51[email protected]linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <[email protected]>

commit ca23c9d6e2f4aa072b69544112f63c2428ed1c56
Author: Chuck Lever <[email protected]>
Date:   Thu Jan 13 12:20:36 2022 -0500

    SUNRPC: Don't dereference xprt->snd_task if it's a cookie
    
    [ Upstream commit aed28b7a2d620cb5cd0c554cb889075c02e25e8e ]
    
    Fixes: e26d9972720e ("SUNRPC: Clean up scheduling of autoclose")
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 14c9086ea246b84e0d35e8a0b7f706202bd72f0a
Author: Marc Zyngier <[email protected]>
Date:   Fri Jan 14 08:57:58 2022 +0000

    KVM: arm64: pkvm: Use the mm_ops indirection for cache maintenance
    
    [ Upstream commit 094d00f8ca58c5d29b25e23b4daaed1ff1f13b41 ]
    
    CMOs issued from EL2 cannot directly use the kernel helpers,
    as EL2 doesn't have a mapping of the guest pages. Oops.
    
    Instead, use the mm_ops indirection to use helpers that will
    perform a mapping at EL2 and allow the CMO to be effective.
    
    Fixes: 25aa28691bb9 ("KVM: arm64: Move guest CMOs to the fault handlers")
    Reviewed-by: Quentin Perret <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit e2d4111a2c0be7d6a3493d143a68622b4947a4a6
Author: Trond Myklebust <[email protected]>
Date:   Wed Dec 15 16:38:16 2021 -0500

    NFS: Ensure the server has an up to date ctime before renaming
    
    [ Upstream commit 6ff9d99bb88faebf134ca668842349d9718e5464 ]
    
    Renaming a file is required by POSIX to update the file ctime, so
    ensure that the file data is synced to disk so that we don't clobber the
    updated ctime by writing back after creating the hard link.
    
    Fixes: f2c2c552f119 ("NFS: Move delegation recall into the NFSv4 callback for rename_setup()")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 498286ab591ffee4bc788acd5b94dfb23050d0eb
Author: Trond Myklebust <[email protected]>
Date:   Wed Dec 15 16:38:15 2021 -0500

    NFS: Ensure the server has an up to date ctime before hardlinking
    
    [ Upstream commit 204975036b34f55237bc44c8a302a88468ef21b5 ]
    
    Creating a hard link is required by POSIX to update the file ctime, so
    ensure that the file data is synced to disk so that we don't clobber the
    updated ctime by writing back after creating the hard link.
    
    Fixes: 9f7682728728 ("NFS: Move the delegation return down into nfs4_proc_link()")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 930767717902381d5362d69d7d0436514c576e46
Author: Eric Dumazet <[email protected]>
Date:   Thu Jan 20 09:41:12 2022 -0800

    ipv6: annotate accesses to fn->fn_sernum
    
    commit aafc2e3285c2d7a79b7ee15221c19fbeca7b1509 upstream.
    
    struct fib6_node's fn_sernum field can be
    read while other threads change it.
    
    Add READ_ONCE()/WRITE_ONCE() annotations.
    
    Do not change existing smp barriers in fib6_get_cookie_safe()
    and __fib6_update_sernum_upto_root()
    
    syzbot reported:
    
    BUG: KCSAN: data-race in fib6_clean_node / inet6_csk_route_socket
    
    write to 0xffff88813df62e2c of 4 bytes by task 1920 on cpu 1:
     fib6_clean_node+0xc2/0x260 net/ipv6/ip6_fib.c:2178
     fib6_walk_continue+0x38e/0x430 net/ipv6/ip6_fib.c:2112
     fib6_walk net/ipv6/ip6_fib.c:2160 [inline]
     fib6_clean_tree net/ipv6/ip6_fib.c:2240 [inline]
     __fib6_clean_all+0x1a9/0x2e0 net/ipv6/ip6_fib.c:2256
     fib6_flush_trees+0x6c/0x80 net/ipv6/ip6_fib.c:2281
     rt_genid_bump_ipv6 include/net/net_namespace.h:488 [inline]
     addrconf_dad_completed+0x57f/0x870 net/ipv6/addrconf.c:4230
     addrconf_dad_work+0x908/0x1170
     process_one_work+0x3f6/0x960 kernel/workqueue.c:2307
     worker_thread+0x616/0xa70 kernel/workqueue.c:2454
     kthread+0x1bf/0x1e0 kernel/kthread.c:359
     ret_from_fork+0x1f/0x30
    
    read to 0xffff88813df62e2c of 4 bytes by task 15701 on cpu 0:
     fib6_get_cookie_safe include/net/ip6_fib.h:285 [inline]
     rt6_get_cookie include/net/ip6_fib.h:306 [inline]
     ip6_dst_store include/net/ip6_route.h:234 [inline]
     inet6_csk_route_socket+0x352/0x3c0 net/ipv6/inet6_connection_sock.c:109
     inet6_csk_xmit+0x91/0x1e0 net/ipv6/inet6_connection_sock.c:121
     __tcp_transmit_skb+0x1323/0x1840 net/ipv4/tcp_output.c:1402
     tcp_transmit_skb net/ipv4/tcp_output.c:1420 [inline]
     tcp_write_xmit+0x1450/0x4460 net/ipv4/tcp_output.c:2680
     __tcp_push_pending_frames+0x68/0x1c0 net/ipv4/tcp_output.c:2864
     tcp_push+0x2d9/0x2f0 net/ipv4/tcp.c:725
     mptcp_push_release net/mptcp/protocol.c:1491 [inline]
     __mptcp_push_pending+0x46c/0x490 net/mptcp/protocol.c:1578
     mptcp_sendmsg+0x9ec/0xa50 net/mptcp/protocol.c:1764
     inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:643
     sock_sendmsg_nosec net/socket.c:705 [inline]
     sock_sendmsg net/socket.c:725 [inline]
     kernel_sendmsg+0x97/0xd0 net/socket.c:745
     sock_no_sendpage+0x84/0xb0 net/core/sock.c:3086
     inet_sendpage+0x9d/0xc0 net/ipv4/af_inet.c:834
     kernel_sendpage+0x187/0x200 net/socket.c:3492
     sock_sendpage+0x5a/0x70 net/socket.c:1007
     pipe_to_sendpage+0x128/0x160 fs/splice.c:364
     splice_from_pipe_feed fs/splice.c:418 [inline]
     __splice_from_pipe+0x207/0x500 fs/splice.c:562
     splice_from_pipe fs/splice.c:597 [inline]
     generic_splice_sendpage+0x94/0xd0 fs/splice.c:746
     do_splice_from fs/splice.c:767 [inline]
     direct_splice_actor+0x80/0xa0 fs/splice.c:936
     splice_direct_to_actor+0x345/0x650 fs/splice.c:891
     do_splice_direct+0x106/0x190 fs/splice.c:979
     do_sendfile+0x675/0xc40 fs/read_write.c:1245
     __do_sys_sendfile64 fs/read_write.c:1310 [inline]
     __se_sys_sendfile64 fs/read_write.c:1296 [inline]
     __x64_sys_sendfile64+0x102/0x140 fs/read_write.c:1296
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    value changed: 0x0000026f -> 0x00000271
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 15701 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    The Fixes tag I chose is probably arbitrary, I do not think
    we need to backport this patch to older kernels.
    
    Fixes: c5cff8561d2d ("ipv6: add rcu grace period before freeing fib6_node")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: syzbot <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2b7e7df1eacd280e561ede3e977853606871c951
Author: José Expósito <[email protected]>
Date:   Sun Jan 16 19:18:44 2022 +0100

    drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable
    
    commit 5e761a2287234bc402ba7ef07129f5103bcd775c upstream.
    
    The function performs a check on the "phy" input parameter, however, it
    is used before the check.
    
    Initialize the "dev" variable after the sanity check to avoid a possible
    NULL pointer dereference.
    
    Fixes: 5c8290284402b ("drm/msm/dsi: Split PHY drivers to separate files")
    Addresses-Coverity-ID: 1493860 ("Null pointer dereference")
    Signed-off-by: José Expósito <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1c7c675f63e0140c76c440408d0f2445c705165f
Author: Miaoqian Lin <[email protected]>
Date:   Thu Dec 30 07:09:40 2021 +0000

    drm/msm/dsi: Fix missing put_device() call in dsi_get_phy
    
    commit c04c3148ca12227d92f91b355b4538cc333c9922 upstream.
    
    If of_find_device_by_node() succeeds, dsi_get_phy() doesn't
    a corresponding put_device(). Thus add put_device() to fix the exception
    handling.
    
    Fixes: ec31abf ("drm/msm/dsi: Separate PHY to another platform device")
    Signed-off-by: Miaoqian Lin <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4c55f12ed31fd1defa87fdfb3a12c5cbca4dd8ee
Author: Xianting Tian <[email protected]>
Date:   Wed Jan 12 20:33:34 2022 +0800

    drm/msm: Fix wrong size calculation
    
    commit 0a727b459ee39bd4c5ced19d6024258ac87b6b2e upstream.
    
    For example, memory-region in .dts as below,
            reg = <0x0 0x50000000 0x0 0x20000000>
    
    We can get below values,
    struct resource r;
    r.start = 0x50000000;
    r.end   = 0x6fffffff;
    
    So the size should be:
    size = r.end - r.start + 1 = 0x20000000
    
    Signed-off-by: Xianting Tian <[email protected]>
    Fixes: 072f1f9168ed ("drm/msm: add support for "stolen" mem")
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 671ebb36709506d22b43e949ae1f7d448538dd0b
Author: Jianguo Wu <[email protected]>
Date:   Fri Jan 21 17:15:31 2022 +0800

    net-procfs: show net devices bound packet types
    
    commit 1d10f8a1f40b965d449e8f2d5ed7b96a7c138b77 upstream.
    
    After commit:7866a621043f ("dev: add per net_device packet type chains"),
    we can not get packet types that are bound to a specified net device by
    /proc/net/ptype, this patch fix the regression.
    
    Run "tcpdump -i ens192 udp -nns0" Before and after apply this patch:
    
    Before:
      [[email protected] ~]# cat /proc/net/ptype
      Type Device      Function
      0800          ip_rcv
      0806          arp_rcv
      86dd          ipv6_rcv
    
    After:
      [[email protected] ~]# cat /proc/net/ptype
      Type Device      Function
      ALL  ens192   tpacket_rcv
      0800          ip_rcv
      0806          arp_rcv
      86dd          ipv6_rcv
    
    v1 -> v2:
      - fix the regression rather than adding new /proc API as
        suggested by Stephen Hemminger.
    
    Fixes: 7866a621043f ("dev: add per net_device packet type chains")
    Signed-off-by: Jianguo Wu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 36a07159e335cd900946293bd5acb7b79f74235f
Author: Trond Myklebust <[email protected]>
Date:   Thu Jan 6 18:24:03 2022 -0500

    NFSv4: nfs_atomic_open() can race when looking up a non-regular file
    
    commit 1751fc1db36f6f411709e143d5393f92d12137a9 upstream.
    
    If the file type changes back to being a regular file on the server
    between the failed OPEN and our LOOKUP, then we need to re-run the OPEN.
    
    Fixes: 0dd2b474d0b6 ("nfs: implement i_op->atomic_open()")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f0583af88e7dd413229ea5e670a0db36fdf34ba2
Author: Trond Myklebust <[email protected]>
Date:   Thu Jan 6 18:24:02 2022 -0500

    NFSv4: Handle case where the lookup of a directory fails
    
    commit ac795161c93699d600db16c1a8cc23a65a1eceaf upstream.
    
    If the application sets the O_DIRECTORY flag, and tries to open a
    regular file, nfs_atomic_open() will punt to doing a regular lookup.
    If the server then returns a regular file, we will happily return a
    file descriptor with uninitialised open state.
    
    The fix is to return the expected ENOTDIR error in these cases.
    
    Reported-by: Lyu Tao <[email protected]>
    Fixes: 0dd2b474d0b6 ("nfs: implement i_op->atomic_open()")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 06c6378f9d0015bbb4d443b5fd46bca36042099d
Author: Guenter Roeck <[email protected]>
Date:   Thu Jan 6 11:48:52 2022 -0800

    hwmon: (lm90) Reduce maximum conversion rate for G781
    
    [ Upstream commit a66c5ed539277b9f2363bbace0dba88b85b36c26 ]
    
    According to its datasheet, G781 supports a maximum conversion rate value
    of 8 (62.5 ms). However, chips labeled G781 and G780 were found to only
    support a maximum conversion rate value of 7 (125 ms). On the other side,
    chips labeled G781-1 and G784 were found to support a conversion rate value
    of 8. There is no known means to distinguish G780 from G781 or G784; all
    chips report the same manufacturer ID and chip revision.
    Setting the conversion rate register value to 8 on chips not supporting
    it causes unexpected behavior since the real conversion rate is set to 0
    (16 seconds) if a value of 8 is written into the conversion rate register.
    Limit the conversion rate register value to 7 for all G78x chips to avoid
    the problem.
    
    Fixes: ae544f64cc7b ("hwmon: (lm90) Add support for GMT G781")
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 32ac95e4478f7aeb1d9f9539430361737eec8459
Author: Eric Dumazet <[email protected]>
Date:   Wed Jan 26 17:10:22 2022 -0800

    ipv4: avoid using shared IP generator for connected sockets
    
    commit 23f57406b82de51809d5812afd96f210f8b627f3 upstream.
    
    ip_select_ident_segs() has been very conservative about using
    the connected socket private generator only for packets with IP_DF
    set, claiming it was needed for some VJ compression implementations.
    
    As mentioned in this referenced document, this can be abused.
    (Ref: Off-Path TCP Exploits of the Mixed IPID Assignment)
    
    Before switching to pure random IPID generation and possibly hurt
    some workloads, lets use the private inet socket generator.
    
    Not only this will remove one vulnerability, this will also
    improve performance of TCP flows using pmtudisc==IP_PMTUDISC_DONT
    
    Fixes: 73f156a6e8c1 ("inetpeer: get rid of ip_id_count")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Reported-by: Ray Che <[email protected]>
    Cc: Willy Tarreau <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 177770672a088a76ad62479900be6d7c0446b6bb
Author: Xin Long <[email protected]>
Date:   Sat Jan 22 06:40:56 2022 -0500

    ping: fix the sk_bound_dev_if match in ping_lookup
    
    commit 2afc3b5a31f9edf3ef0f374f5d70610c79c93a42 upstream.
    
    When 'ping' changes to use PING socket instead of RAW socket by:
    
       # sysctl -w net.ipv4.ping_group_range="0 100"
    
    the selftests 'router_broadcast.sh' will fail, as such command
    
      # ip vrf exec vrf-h1 ping -I veth0 198.51.100.255 -b
    
    can't receive the response skb by the PING socket. It's caused by mismatch
    of sk_bound_dev_if and dif in ping_rcv() when looking up the PING socket,
    as dif is vrf-h1 if dif's master was set to vrf-h1.
    
    This patch is to fix this regression by also checking the sk_bound_dev_if
    against sdif so that the packets can stil be received even if the socket
    is not bound to the vrf device but to the real iif.
    
    Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
    Reported-by: Hangbin Liu <[email protected]>
    Signed-off-by: Xin Long <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 0ccc24fc1b25ceeb3d554f3aa7a2d9b0eb86c2ef
Author: Guenter Roeck <[email protected]>
Date:   Fri Jan 7 11:11:00 2022 -0800

    hwmon: (lm90) Mark alert as broken for MAX6680
    
    commit 94746b0ba479743355e0d3cc1cb9cfe3011fb8be upstream.
    
    Experiments with MAX6680 and MAX6681 show that the alert function of those
    chips is broken, similar to other chips supported by the lm90 driver.
    Mark it accordingly.
    
    Fixes: 4667bcb8d8fc ("hwmon: (lm90) Introduce chip parameter structure")
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 6724214a7bbff26b515041c8193d084149d85df4
Author: Guenter Roeck <[email protected]>
Date:   Fri Jan 7 12:36:41 2022 -0800

    hwmon: (lm90) Mark alert as broken for MAX6646/6647/6649
    
    commit f614629f9c1080dcc844a8430e3fb4c37ebbf05d upstream.
    
    Experiments with MAX6646 and MAX6648 show that the alert function of those
    chips is broken, similar to other chips supported by the lm90 driver.
    Mark it accordingly.
    
    Fixes: 4667bcb8d8fc ("hwmon: (lm90) Introduce chip parameter structure")
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 839ec7039513a4f84bfbaff953a9393471176bee
Author: Congyu Liu <[email protected]>
Date:   Tue Jan 18 14:20:13 2022 -0500

    net: fix information leakage in /proc/net/ptype
    
    commit 47934e06b65637c88a762d9c98329ae6e3238888 upstream.
    
    In one net namespace, after creating a packet socket without binding
    it to a device, users in other net namespaces can observe the new
    `packet_type` added by this packet socket by reading `/proc/net/ptype`
    file. This is minor information leakage as packet socket is
    namespace aware.
    
    Add a net pointer in `packet_type` to keep the net namespace of
    of corresponding packet socket. In `ptype_seq_show`, this net pointer
    must be checked when it is not NULL.
    
    Fixes: 2feb27dbe00c ("[NETNS]: Minor information leak via /proc/net/ptype file.")
    Signed-off-by: Congyu Liu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ba1863be105b06e10d0e2f6b1b8a0570801cfc71
Author: sparkhuang <[email protected]>
Date:   Wed Dec 15 10:08:23 2021 +0100

    ARM: 9170/1: fix panic when kasan and kprobe are enabled
    
    commit 8b59b0a53c840921b625378f137e88adfa87647e upstream.
    
    arm32 uses software to simulate the instruction replaced
    by kprobe. some instructions may be simulated by constructing
    assembly functions. therefore, before executing instruction
    simulation, it is necessary to construct assembly function
    execution environment in C language through binding registers.
    after kasan is enabled, the register binding relationship will
    be destroyed, resulting in instruction simulation errors and
    causing kernel panic.
    
    the kprobe emulate instruction function is distributed in three
    files: actions-common.c actions-arm.c actions-thumb.c, so disable
    KASAN when compiling these files.
    
    for example, use kprobe insert on cap_capable+20 after kasan
    enabled, the cap_capable assembly code is as follows:
    <cap_capable>:
    e92d47f0        push    {r4, r5, r6, r7, r8, r9, sl, lr}
    e1a05000        mov     r5, r0
    e280006c        add     r0, r0, #108    ; 0x6c
    e1a04001        mov     r4, r1
    e1a06002        mov     r6, r2
    e59fa090        ldr     sl, [pc, #144]  ;
    ebfc7bf8        bl      c03aa4b4 <__asan_load4>
    e595706c        ldr     r7, [r5, #108]  ; 0x6c
    e2859014        add     r9, r5, #20
    ......
    The emulate_ldr assembly code after enabling kasan is as follows:
    c06f1384 <emulate_ldr>:
    e92d47f0        push    {r4, r5, r6, r7, r8, r9, sl, lr}
    e282803c        add     r8, r2, #60     ; 0x3c
    e1a05000        mov     r5, r0
    e7e37855        ubfx    r7, r5, #16, #4
    e1a00008        mov     r0, r8
    e1a09001        mov     r9, r1
    e1a04002        mov     r4, r2
    ebf35462        bl      c03c6530 <__asan_load4>
    e357000f        cmp     r7, #15
    e7e36655        ubfx    r6, r5, #12, #4
    e205a00f        and     sl, r5, #15
    0a000001        beq     c06f13bc <emulate_ldr+0x38>
    e0840107        add     r0, r4, r7, lsl #2
    ebf3545c        bl      c03c6530 <__asan_load4>
    e084010a        add     r0, r4, sl, lsl #2
    ebf3545a        bl      c03c6530 <__asan_load4>
    e2890010        add     r0, r9, #16
    ebf35458        bl      c03c6530 <__asan_load4>
    e5990010        ldr     r0, [r9, #16]
    e12fff30        blx     r0
    e356000f        cm      r6, #15
    1a000014        bne     c06f1430 <emulate_ldr+0xac>
    e1a06000        mov     r6, r0
    e2840040        add     r0, r4, #64     ; 0x40
    ......
    
    when running in emulate_ldr to simulate the ldr instruction, panic
    occurred, and the log is as follows:
    Unable to handle kernel NULL pointer dereference at virtual address
    00000090
    pgd = ecb46400
    [00000090] *pgd=2e0fa003, *pmd=00000000
    Internal error: Oops: 206 [#1] SMP ARM
    PC is at cap_capable+0x14/0xb0
    LR is at emulate_ldr+0x50/0xc0
    psr: 600d0293 sp : ecd63af8  ip : 00000004  fp : c0a7c30c
    r10: 00000000  r9 : c30897f4  r8 : ecd63cd4
    r7 : 0000000f  r6 : 0000000a  r5 : e59fa090  r4 : ecd63c98
    r3 : c06ae294  r2 : 00000000  r1 : b7611300  r0 : bf4ec008
    Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
    Control: 32c5387d  Table: 2d546400  DAC: 55555555
    Process bash (pid: 1643, stack limit = 0xecd60190)
    (cap_capable) from (kprobe_handler+0x218/0x340)
    (kprobe_handler) from (kprobe_trap_handler+0x24/0x48)
    (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)
    (do_undefinstr) from (__und_svc_finish+0x0/0x30)
    (__und_svc_finish) from (cap_capable+0x18/0xb0)
    (cap_capable) from (cap_vm_enough_memory+0x38/0x48)
    (cap_vm_enough_memory) from
    (security_vm_enough_memory_mm+0x48/0x6c)
    (security_vm_enough_memory_mm) from
    (copy_process.constprop.5+0x16b4/0x25c8)
    (copy_process.constprop.5) from (_do_fork+0xe8/0x55c)
    (_do_fork) from (SyS_clone+0x1c/0x24)
    (SyS_clone) from (__sys_trace_return+0x0/0x10)
    Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)
    
    Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support")
    Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM")
    Signed-off-by: huangshaobo <[email protected]>
    Acked-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 184c4dc878b9355c21ea0641fd409f8587c09b09
Author: Ido Schimmel <[email protected]>
Date:   Thu Jan 20 10:05:46 2022 +0200

    ipv6_tunnel: Rate limit warning messages
    
    commit 6cee105e7f2ced596373951d9ea08dacc3883c68 upstream.
    
    The warning messages can be invoked from the data path for every packet
    transmitted through an ip6gre netdev, leading to high CPU utilization.
    
    Fix that by rate limiting the messages.
    
    Fixes: 09c6bbf090ec ("[IPV6]: Do mandatory IPv6 tunnel endpoint checks in realtime")
    Reported-by: Maksym Yaremchuk <[email protected]>
    Tested-by: Maksym Yaremchuk <[email protected]>
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: Amit Cohen <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit ace7b6ef41251c5fe47f629a9a922382fb7b0a6b
Author: John Meneghini <[email protected]>
Date:   Fri Jan 14 23:00:44 2022 -0500

    scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()
    
    commit 847f9ea4c5186fdb7b84297e3eeed9e340e83fce upstream.
    
    The bnx2fc_destroy() functions are removing the interface before calling
    destroy_work. This results multiple WARNings from sysfs_remove_group() as
    the controller rport device attributes are removed too early.
    
    Replace the fcoe_port's destroy_work queue. It's not needed.
    
    The problem is easily reproducible with the following steps.
    
    Example:
    
      $ dmesg -w &
      $ systemctl enable --now fcoe
      $ fipvlan -s -c ens2f1
      $ fcoeadm -d ens2f1.802
      [  583.464488] host2: libfc: Link down on port (7500a1)
      [  583.472651] bnx2fc: 7500a1 - rport not created Yet!!
      [  583.490468] ------------[ cut here ]------------
      [  583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0'
      [  583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80
      [  583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ...
      [  583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1
      [  583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
      [  584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc]
      [  584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80
      [  584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ...
      [  584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282
      [  584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000
      [  584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0
      [  584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00
      [  584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400
      [  584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004
      [  584.355379] FS:  0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000
      [  584.394419] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0
      [  584.454888] Call Trace:
      [  584.466108]  device_del+0xb2/0x3e0
      [  584.481701]  device_unregister+0x13/0x60
      [  584.501306]  bsg_unregister_queue+0x5b/0x80
      [  584.522029]  bsg_remove_queue+0x1c/0x40
      [  584.541884]  fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc]
      [  584.573823]  process_one_work+0x1e3/0x3b0
      [  584.592396]  worker_thread+0x50/0x3b0
      [  584.609256]  ? rescuer_thread+0x370/0x370
      [  584.628877]  kthread+0x149/0x170
      [  584.643673]  ? set_kthread_struct+0x40/0x40
      [  584.662909]  ret_from_fork+0x22/0x30
      [  584.680002] ---[ end trace 53575ecefa942ece ]---
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 0cbf32e1681d ("[SCSI] bnx2fc: Avoid calling bnx2fc_if_destroy with unnecessary locks")
    Tested-by: Guangwu Zhang <[email protected]>
    Co-developed-by: Maurizio Lombardi <[email protected]>
    Signed-off-by: Maurizio Lombardi <[email protected]>
    Signed-off-by: John Meneghini <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 960f0584ddc15b5c2fce2f91b7e1b2f820d4382f
Author: Yang Yingliang <[email protected]>
Date:   Tue Jan 11 09:24:41 2022 +0800

    scsi: elx: efct: Don't use GFP_KERNEL under spin lock
    
    commit 61263b3a11a2594b4e898f166c31162236182b5c upstream.
    
    GFP_KERNEL/GFP_DMA can't be used under a spin lock. According the comment,
    els_ios_lock is used to protect els ios list so we can move down the spin
    lock to avoid using this flag under the lock.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 8f406ef72859 ("scsi: elx: libefc: Extended link Service I/O handling")
    Reported-by: Hulk Robot <[email protected]>
    Reviewed-by: James Smart <[email protected]>
    Signed-off-by: Yang Yingliang <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 36e3b3ff1b4f07c20e2b064f43df0fb5b7785688
Author: Matthias Kaehlcke <[email protected]>
Date:   Mon Jan 10 10:47:37 2022 -0800

    rpmsg: char: Fix race between the release of rpmsg_eptdev and cdev
    
    commit 7a534ae89e34e9b51acb5a63dd0f88308178b46a upstream.
    
    struct rpmsg_eptdev contains a struct cdev. The current code frees
    the rpmsg_eptdev struct in rpmsg_eptdev_destroy(), but the cdev is
    a managed object, therefore its release is not predictable and the
    rpmsg_eptdev could be freed before the cdev is entirely released.
    
    The cdev_device_add/del() API was created to address this issue
    (see commit '233ed09d7fda ("chardev: add helper function to register
    char devs with a struct device")'), use it instead of cdev add/del().
    
    Fixes: c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface")
    Suggested-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Matthias Kaehlcke <[email protected]>
    Reviewed-by: Mathieu Poirier <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]angeid
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d6cdc6ae542845d4d0ac8b6d99362bde7042a3c7
Author: Sujit Kautkar <[email protected]>
Date:   Mon Jan 10 10:47:36 2022 -0800

    rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev
    
    commit b7fb2dad571d1e21173c06cef0bced77b323990a upstream.
    
    struct rpmsg_ctrldev contains a struct cdev. The current code frees
    the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the
    cdev is a managed object, therefore its release is not predictable
    and the rpmsg_ctrldev could be freed before the cdev is entirely
    released, as in the backtrace below.
    
    [   93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c
    [   93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0
    [   93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v
    [   93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G    B             5.4.163-lockdep #26
    [   93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
    [   93.730055] Workqueue: events kobject_delayed_cleanup
    [   93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO)
    [   93.740216] pc : debug_print_object+0x13c/0x1b0
    [   93.744890] lr : debug_print_object+0x13c/0x1b0
    [   93.749555] sp : ffffffacf5bc7940
    [   93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000
    [   93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000
    [   93.763916] x25: ffffffd0734f856c x24: dfffffd000000000
    [   93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0
    [   93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0
    [   93.780338] x19: ffffffd075199100 x18: 00000000000276e0
    [   93.785814] x17: 0000000000000000 x16: dfffffd000000000
    [   93.791291] x15: ffffffffffffffff x14: 6e6968207473696c
    [   93.796768] x13: 0000000000000000 x12: ffffffd075e2b000
    [   93.802244] x11: 0000000000000001 x10: 0000000000000000
    [   93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900
    [   93.813200] x7 : 0000000000000000 x6 : 0000000000000000
    [   93.818676] x5 : 0000000000000080 x4 : 0000000000000000
    [   93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001
    [   93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061
    [   93.835104] Call trace:
    [   93.837644]  debug_print_object+0x13c/0x1b0
    [   93.841963]  __debug_check_no_obj_freed+0x25c/0x3c0
    [   93.846987]  debug_check_no_obj_freed+0x18/0x20
    [   93.851669]  slab_free_freelist_hook+0xbc/0x1e4
    [   93.856346]  kfree+0xfc/0x2f4
    [   93.859416]  rpmsg_ctrldev_release_device+0x78/0xb8
    [   93.864445]  device_release+0x84/0x168
    [   93.868310]  kobject_cleanup+0x12c/0x298
    [   93.872356]  kobject_delayed_cleanup+0x10/0x18
    [   93.876948]  process_one_work+0x578/0x92c
    [   93.881086]  worker_thread+0x804/0xcf8
    [   93.884963]  kthread+0x2a8/0x314
    [   93.888303]  ret_from_fork+0x10/0x18
    
    The cdev_device_add/del() API was created to address this issue (see
    commit '233ed09d7fda ("chardev: add helper function to register char
    devs with a struct device")'), use it instead of cdev add/del().
    
    Fixes: c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface")
    Signed-off-by: Sujit Kautkar <[email protected]>
    Signed-off-by: Matthias Kaehlcke <[email protected]>
    Reviewed-by: Mathieu Poirier <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Reviewed-by: Stephen Boyd <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]angeid
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bad4b11b8e01d4e97b38aa742c26e7ad0ea962a9
Author: Linyu Yuan <[email protected]>
Date:   Mon Jan 10 20:43:28 2022 +0800

    usb: roles: fix include/linux/usb/role.h compile issue
    
    commit 945c37ed564770c78dfe6b9f08bed57a1b4e60ef upstream.
    
    when CONFIG_USB_ROLE_SWITCH is not defined,
    add usb_role_switch_find_by_fwnode() definition which return NULL.
    
    Fixes: c6919d5e0cd1 ("usb: roles: Add usb_role_switch_find_by_fwnode()")
    Signed-off-by: Linyu Yuan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3d8e5859639b6f6371a17b94c99b8640fbeefa94
Author: Joe Damato <[email protected]>
Date:   Wed Dec 8 17:56:33 2021 -0800

    i40e: fix unsigned stat widths
    
    commit 3b8428b84539c78fdc8006c17ebd25afd4722d51 upstream.
    
    Change i40e_update_vsi_stats and struct i40e_vsi to use u64 fields to match
    the width of the stats counters in struct i40e_rx_queue_stats.
    
    Update debugfs code to use the correct format specifier for u64.
    
    Fixes: 41c445ff0f48 ("i40e: main driver core")
    Signed-off-by: Joe Damato <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Tested-by: Gurucharan G <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fff687f44c7aae70117c54774ea531cb8daaf476
Author: Karen Sornek <[email protected]>
Date:   Thu Dec 2 12:52:01 2021 +0100

    i40e: Fix for failed to init adminq while VF reset
    
    commit 0f344c8129a5337dae50e31b817dd50a60ff238c upstream.
    
    Fix for failed to init adminq: -53 while VF is resetting via MAC
    address changing procedure.
    Added sync module to avoid reading deadbeef value in reinit adminq
    during software reset.
    Without this patch it is possible to trigger VF reset procedure
    during reinit adminq. This resulted in an incorrect reading of
    value from the AQP registers and generated the -53 error.
    
    Fixes: 5c3c48ac6bf5 ("i40e: implement virtual device interface")
    Signed-off-by: Grzegorz Szczurek <[email protected]>
    Signed-off-by: Karen Sornek <[email protected]>
    Tested-by: Konrad Jankowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4b3aa858268b7b9aeef02e5f9c4cd8f8fac101c8
Author: Sylwester Dziedziuch <[email protected]>
Date:   Fri Nov 26 11:11:22 2021 +0100

    i40e: Fix queues reservation for XDP
    
    commit 92947844b8beee988c0ce17082b705c2f75f0742 upstream.
    
    When XDP was configured on a system with large number of CPUs
    and X722 NIC there was a call trace with NULL pointer dereference.
    
    i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12
    i40e 0000:87:00.0: setup of MAIN VSI failed
    
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e]
    Call Trace:
    ? i40e_reconfig_rss_queues+0x130/0x130 [i40e]
    dev_xdp_install+0x61/0xe0
    dev_xdp_attach+0x18a/0x4c0
    dev_change_xdp_fd+0x1e6/0x220
    do_setlink+0x616/0x1030
    ? ahci_port_stop+0x80/0x80
    ? ata_qc_issue+0x107/0x1e0
    ? lock_timer_base+0x61/0x80
    ? __mod_timer+0x202/0x380
    rtnl_setlink+0xe5/0x170
    ? bpf_lsm_binder_transaction+0x10/0x10
    ? security_capable+0x36/0x50
    rtnetlink_rcv_msg+0x121/0x350
    ? rtnl_calcit.isra.0+0x100/0x100
    netlink_rcv_skb+0x50/0xf0
    netlink_unicast+0x1d3/0x2a0
    netlink_sendmsg+0x22a/0x440
    sock_sendmsg+0x5e/0x60
    __sys_sendto+0xf0/0x160
    ? __sys_getsockname+0x7e/0xc0
    ? _copy_from_user+0x3c/0x80
    ? __sys_setsockopt+0xc8/0x1a0
    __x64_sys_sendto+0x20/0x30
    do_syscall_64+0x33/0x40
    entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7f83fa7a39e0
    
    This was caused by PF queue pile fragmentation due to
    flow director VSI queue being placed right after main VSI.
    Because of this main VSI was not able to resize its
    queue allocation for XDP resulting in no queues allocated
    for main VSI when XDP was turned on.
    
    Fix this by always allocating last queue in PF queue pile
    for a flow director VSI.
    
    Fixes: 41c445ff0f48 ("i40e: main driver core")
    Fixes: 74608d17fe29 ("i40e: add support for XDP_TX action")
    Signed-off-by: Sylwester Dziedziuch <[email protected]>
    Signed-off-by: Mateusz Palczewski <[email protected]>
    Reviewed-by: Maciej Fijalkowski <[email protected]>
    Tested-by: Kiran Bhandare <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 987aca1c7914e11c126dfdf095f8c53b78549f4e
Author: Jedrzej Jagielski <[email protected]>
Date:   Fri Nov 5 11:17:00 2021 +0000

    i40e: Fix issue when maximum queues is exceeded
    
    commit d701658a50a471591094b3eb3961b4926cc8f104 upstream.
    
    Before this patch VF interface vanished when
    maximum queue number was exceeded. Driver tried
    to add next queues even if there was not enough
    space. PF sent incorrect number of queues to
    the VF when there were not enough of them.
    
    Add an additional condition introduced to check
    available space in 'qp_pile' before proceeding.
    This condition makes it impossible to add queues
    if they number is greater than the number resulting
    from available space.
    Also add the search for free space in PF queue
    pair piles.
    
    Without this patch VF interfaces are not seen
    when available space for queues has been
    exceeded and following logs appears permanently
    in dmesg:
    "Unable to get VF config (-32)".
    "VF 62 failed opcode 3, retval: -5"
    "Unable to get VF config due to PF error condition, not retrying"
    
    Fixes: 7daa6bf3294e ("i40e: driver core headers")
    Fixes: 41c445ff0f48 ("i40e: main driver core")
    Signed-off-by: Jaroslaw Gawin <[email protected]>
    Signed-off-by: Slawomir Laba <[email protected]>
    Signed-off-by: Jedrzej Jagielski <[email protected]>
    Tested-by: Konrad Jankowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 70889ca040f5caacb16053de5c4ab7d7f466a360
Author: Jedrzej Jagielski <[email protected]>
Date:   Thu Oct 28 13:51:14 2021 +0000

    i40e: Increase delay to 1 s after global EMP reset
    
    commit 9b13bd53134c9ddd544a790125199fdbdb505e67 upstream.
    
    Recently simplified i40e_rebuild causes that FW sometimes
    is not ready after NVM update, the ping does not return.
    
    Increase the delay in case of EMP reset.
    Old delay of 300 ms was introduced for specific cards for 710 series.
    Now it works for all the cards and delay was increased.
    
    Fixes: 1fa51a650e1d ("i40e: Add delay after EMP reset for firmware to recover")
    Signed-off-by: Arkadiusz Kubalewski <[email protected]>
    Signed-off-by: Jedrzej Jagielski <[email protected]>
    Tested-by: Gurucharan G <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit edc4c8f18592451b97cc55e99010ef0d6a6b80a4
Author: Christophe Leroy <[email protected]>
Date:   Wed Dec 22 13:07:31 2021 +0000

    powerpc/32: Fix boot failure with GCC latent entropy plugin
    
    commit bba496656a73fc1d1330b49c7f82843836e9feb1 upstream.
    
    Boot fails with GCC latent entropy plugin enabled.
    
    This is due to early boot functions trying to access 'latent_entropy'
    global data while the kernel is not relocated at its final
    destination yet.
    
    As there is no way to tell GCC to use PTRRELOC() to access it,
    disable latent entropy plugin in early_32.o and feature-fixups.o and
    code-patching.o
    
    Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
    Cc: [email protected] # v4.9+
    Reported-by: Erhard Furtner <[email protected]>
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215217
    Link: https://lore.kernel.org/r/2bac55483[email protected]csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d324727b0e5ae74cd5cd097cff37de627423a264
Author: Christophe Leroy <[email protected]>
Date:   Mon Jan 10 15:29:25 2022 +0000

    powerpc/32s: Fix kasan_init_region() for KASAN
    
    commit d37823c3528e5e0705fc7746bcbc2afffb619259 upstream.
    
    It has been reported some configuration where the kernel doesn't
    boot with KASAN enabled.
    
    This is due to wrong BAT allocation for the KASAN area:
    
            ---[ Data Block Address Translation ]---
            0: 0xc0000000-0xcfffffff 0x00000000       256M Kernel rw      m
            1: 0xd0000000-0xdfffffff 0x10000000       256M Kernel rw      m
            2: 0xe0000000-0xefffffff 0x20000000       256M Kernel rw      m
            3: 0xf8000000-0xf9ffffff 0x2a000000        32M Kernel rw      m
            4: 0xfa000000-0xfdffffff 0x2c000000        64M Kernel rw      m
    
    A BAT must have both virtual and physical addresses alignment matching
    the size of the BAT. This is not the case for BAT 4 above.
    
    Fix kasan_init_region() by using block_size() function that is in
    book3s32/mmu.c. To be able to reuse it here, make it non static and
    change its name to bat_block_size() in order to avoid name conflict
    with block_size() defined in <linux/blkdev.h>
    
    Also reuse find_free_bat() to avoid an error message from setbat()
    when no BAT is available.
    
    And allocate memory outside of linear memory mapping to avoid
    wasting that precious space.
    
    With this change we get correct alignment for BATs and KASAN shadow
    memory is allocated outside the linear memory space.
    
            ---[ Data Block Address Translation ]---
            0: 0xc0000000-0xcfffffff 0x00000000       256M Kernel rw
            1: 0xd0000000-0xdfffffff 0x10000000       256M Kernel rw
            2: 0xe0000000-0xefffffff 0x20000000       256M Kernel rw
            3: 0xf8000000-0xfbffffff 0x7c000000        64M Kernel rw
            4: 0xfc000000-0xfdffffff 0x7a000000        32M Kernel rw
    
    Fixes: 7974c4732642 ("powerpc/32s: Implement dedicated kasan_init_region()")
    Cc: [email protected]
    Reported-by: Maxime Bizon <[email protected]>
    Signed-off-by: Christophe Leroy <[email protected]>
    Tested-by: Maxime Bizon <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/7a50ef902[email protected]csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2910254ad596a2e0815f7093d6df8d25d23a2e18
Author: Christophe Leroy <[email protected]>
Date:   Fri Nov 26 13:40:35 2021 +0100

    powerpc/32s: Allocate one 256k IBAT instead of two consecutives 128k IBATs
    
    commit 37eb7ca91b692e8e49e7dd50158349a6c8fb5b09 upstream.
    
    Today we have the following IBATs allocated:
    
            ---[ Instruction Block Address Translation ]---
            0: 0xc0000000-0xc03fffff 0x00000000         4M Kernel   x     m
            1: 0xc0400000-0xc05fffff 0x00400000         2M Kernel   x     m
            2: 0xc0600000-0xc06fffff 0x00600000         1M Kernel   x     m
            3: 0xc0700000-0xc077ffff 0x00700000       512K Kernel   x     m
            4: 0xc0780000-0xc079ffff 0x00780000       128K Kernel   x     m
            5: 0xc07a0000-0xc07bffff 0x007a0000       128K Kernel   x     m
            6:         -
            7:         -
    
    The two 128K should be a single 256K instead.
    
    When _etext is not aligned to 128Kbytes, the system will allocate
    all necessary BATs to the lower 128Kbytes boundary, then allocate
    an additional 128Kbytes BAT for the remaining block.
    
    Instead, align the top to 128Kbytes so that the function directly
    allocates a 256Kbytes last block:
    
            ---[ Instruction Block Address Translation ]---
            0: 0xc0000000-0xc03fffff 0x00000000         4M Kernel   x     m
            1: 0xc0400000-0xc05fffff 0x00400000         2M Kernel   x     m
            2: 0xc0600000-0xc06fffff 0x00600000         1M Kernel   x     m
            3: 0xc0700000-0xc077ffff 0x00700000       512K Kernel   x     m
            4: 0xc0780000-0xc07bffff 0x00780000       256K Kernel   x     m
            5:         -
            6:         -
            7:         -
    
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/ab58b2968[email protected]csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 865c08c6a55e548b1c39a58330be176f44383cde
Author: Tony Luck <[email protected]>
Date:   Fri Jan 21 09:47:38 2022 -0800

    x86/cpu: Add Xeon Icelake-D to list of CPUs that support PPIN
    
    commit e464121f2d40eabc7d11823fb26db807ce945df4 upstream.
    
    Missed adding the Icelake-D CPU to the list. It uses the same MSRs
    to control and read the inventory number as all the other models.
    
    Fixes: dc6b025de95b ("x86/mce: Add Xeon Icelake to list of CPUs that support PPIN")
    Reported-by: Ailin Xu <[email protected]>
    Signed-off-by: Tony Luck <[email protected]>
    Signed-off-by: Borislav Petkov <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 757c8da2b3592da48d43ff0abea4cd759133afc3
Author: Yazen Ghannam <[email protected]>
Date:   Mon Jan 17 16:13:28 2022 +0000

    x86/MCE/AMD: Allow thresholding interface updates after init
    
    commit 1f52b0aba6fd37653416375cb8a1ca673acf8d5f upstream.
    
    Changes to the AMD Thresholding sysfs code prevents sysfs writes from
    updating the underlying registers once CPU init is completed, i.e.
    "threshold_banks" is set.
    
    Allow the registers to be updated if the thresholding interface is
    already initialized or if in the init path. Use the "set_lvt_off" value
    to indicate if running in the init path, since this value is only set
    during init.
    
    Fixes: a037f3ca0ea0 ("x86/mce/amd: Make threshold bank setting hotplug robust")
    Signed-off-by: Yazen Ghannam <[email protected]>
    Signed-off-by: Borislav Petkov <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0b8ec4e942f38d1934447b9d6ae373a0261f7e9e
Author: Bjorn Helgaas <[email protected]>
Date:   Wed Jan 26 09:40:01 2022 -0600

    PCI/sysfs: Find shadow ROM before static attribute initialization
    
    commit 66d28b21fe6b3da8d1e9f0a7ba38bc61b6c547e1 upstream.
    
    Ville reported that the sysfs "rom" file for VGA devices disappeared after
    527139d738d7 ("PCI/sysfs: Convert "rom" to static attribute").
    
    Prior to 527139d738d7, FINAL fixups, including pci_fixup_video() where we
    find shadow ROMs, were run before pci_create_sysfs_dev_files() created the
    sysfs "rom" file.
    
    After 527139d738d7, "rom" is a static attribute and is created before FINAL
    fixups are run, so we didn't create "rom" files for shadow ROMs:
    
      acpi_pci_root_add
        ...
          pci_scan_single_device
            pci_device_add
              pci_fixup_video                    # <-- new HEADER fixup
              device_add
                ...
                  if (grp->is_visible())
                    pci_dev_rom_attr_is_visible  # after 527139d738d7
        pci_bus_add_devices
          pci_bus_add_device
            pci_fixup_device(pci_fixup_final)
              pci_fixup_video                    # <-- previous FINAL fixup
            pci_create_sysfs_dev_files
              if (pci_resource_len(pdev, PCI_ROM_RESOURCE))
                sysfs_create_bin_file("rom")     # before 527139d738d7
    
    Change pci_fixup_video() to be a HEADER fixup so it runs before sysfs
    static attributes are initialized.
    
    Rename the Loongson pci_fixup_radeon() to pci_fixup_video() and make its
    dmesg logging identical to the others since it is doing the same job.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 527139d738d7 ("PCI/sysfs: Convert "rom" to static attribute")
    Link: https://lore.kernel.org/r/[email protected]
    Reported-by: Ville Syrjälä <[email protected]>
    Tested-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Cc: [email protected]                      # v5.13+
    Cc: Huacai Chen <[email protected]>
    Cc: Jiaxun Yang <[email protected]>
    Cc: Thomas Bogendoerfer <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: Dave Hansen <[email protected]>
    Cc: Krzysztof Wilczyński <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9d2245815b4abc1a7b255fc472ac91b48d470088
Author: Mathieu Desnoyers <[email protected]>
Date:   Mon Jan 17 15:30:10 2022 -0500

    sched/membarrier: Fix membarrier-rseq fence command missing from query bitmask
    
    commit 809232619f5b15e31fb3563985e705454f32621f upstream.
    
    The membarrier command MEMBARRIER_CMD_QUERY allows querying the
    available membarrier commands. When the membarrier-rseq fence commands
    were added, a new MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ_BITMASK was
    introduced with the intent to expose them with the MEMBARRIER_CMD_QUERY
    command, the but it was never added to MEMBARRIER_CMD_BITMASK.
    
    The membarrier-rseq fence commands are therefore not wired up with the
    query command.
    
    Rename MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ_BITMASK to
    MEMBARRIER_PRIVATE_EXPEDITED_RSEQ_BITMASK (the bitmask is not a command
    per-se), and change the erroneous
    MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ_BITMASK (which does not
    actually exist) to MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ.
    
    Wire up MEMBARRIER_PRIVATE_EXPEDITED_RSEQ_BITMASK in
    MEMBARRIER_CMD_BITMASK. Fixing this allows discovering availability of
    the membarrier-rseq fence feature.
    
    Fixes: 2a36ab717e8f ("rseq/membarrier: Add MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ")
    Signed-off-by: Mathieu Desnoyers <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Cc: <[email protected]> # 5.10+
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ca2dafd4cb6fbe7b796011301eae1827040f39f0
Author: Joseph Qi <[email protected]>
Date:   Sat Jan 29 13:41:27 2022 -0800

    ocfs2: fix a deadlock when commit trans
    
    commit ddf4b773aa40790dfa936bd845c18e735a49c61c upstream.
    
    commit 6f1b228529ae introduces a regression which can deadlock as
    follows:
    
      Task1:                              Task2:
      jbd2_journal_commit_transaction     ocfs2_test_bg_bit_allocatable
      spin_lock(&jh->b_state_lock)        jbd_lock_bh_journal_head
      __jbd2_journal_remove_checkpoint    spin_lock(&jh->b_state_lock)
      jbd2_journal_put_journal_head
      jbd_lock_bh_journal_head
    
    Task1 and Task2 lock bh->b_state and jh->b_state_lock in different
    order, which finally result in a deadlock.
    
    So use jbd2_journal_[grab|put]_journal_head instead in
    ocfs2_test_bg_bit_allocatable() to fix it.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 6f1b228529ae ("ocfs2: fix race between searching chunks and release journal_head from buffer_head")
    Signed-off-by: Joseph Qi <[email protected]>
    Reported-by: Gautham Ananthakrishna <[email protected]>
    Tested-by: Gautham Ananthakrishna <[email protected]>
    Reported-by: Saeed Mirzamohammadi <[email protected]>
    Cc: "Theodore Ts'o" <[email protected]>
    Cc: Andreas Dilger <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Jun Piao <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Mark Fasheh <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8cfdaaa4d6d166cfbfa5fd9cde6942e0ea4b25ba
Author: Joseph Qi <[email protected]>
Date:   Sat Jan 29 13:41:23 2022 -0800

    jbd2: export jbd2_journal_[grab|put]_journal_head
    
    commit 4cd1103d8c66b2cdb7e64385c274edb0ac5e8887 upstream.
    
    Patch series "ocfs2: fix a deadlock case".
    
    This fixes a deadlock case in ocfs2.  We firstly export jbd2 symbols
    jbd2_journal_[grab|put]_journal_head as preparation and later use them
    in ocfs2 insread of jbd_[lock|unlock]_bh_journal_head to fix the
    deadlock.
    
    This patch (of 2):
    
    This exports symbols jbd2_journal_[grab|put]_journal_head, which will be
    used outside modules, e.g.  ocfs2.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Joseph Qi <[email protected]>
    Cc: Mark Fasheh <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Jun Piao <[email protected]>
    Cc: Andreas Dilger <[email protected]>
    Cc: Gautham Ananthakrishna <[email protected]>
    Cc: Saeed Mirzamohammadi <[email protected]>
    Cc: "Theodore Ts'o" <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit dd22253c13d2795c566f52c30f1dba48d51c482d
Author: Peter Collingbourne <[email protected]>
Date:   Sat Jan 29 13:41:14 2022 -0800

    mm, kasan: use compare-exchange operation to set KASAN page tag
    
    commit 27fe73394a1c6d0b07fa4d95f1bca116d1cc66e9 upstream.
    
    It has been reported that the tag setting operation on newly-allocated
    pages can cause the page flags to be corrupted when performed
    concurrently with other flag updates as a result of the use of
    non-atomic operations.
    
    Fix the problem by using a compare-exchange loop to update the tag.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://linux-review.googlesource.com/id/I456b24a2b9067d93968d43b4bb3351c0cec63101
    Fixes: 2813b9c02962 ("kasan, mm, arm64: tag non slab memory allocated via pagealloc")
    Signed-off-by: Peter Collingbourne <[email protected]>
    Reviewed-by: Andrey Konovalov <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1cd8a5d24477c308c9e6f3bb1a8ce61fca1ed411
Author: Lorenzo Bianconi <[email protected]>
Date:   Thu Dec 9 14:06:27 2021 +0100

    mt76: connac: introduce MCU_CE_CMD macro
    
    commit 680a2ead741ad9b479a53adf154ed5eee74d2b9a upstream.
    
    Similar to MCU_EXT_CMD, introduce MCU_CE_CMD for CE commands
    
    Stable kernel notes:
    
    Upstream commit 547224024579 (mt76: connac: introduce MCU_UNI_CMD macro,
    2021-12-09) introduced a bug by removing MCU_UNI_PREFIX, but not
    updating MCU_CMD_MASK accordingly, so when commands are compared in
    mt7921_mcu_parse_response() one has the extra bit __MCU_CMD_FIELD_UNI
    set and the comparison fails:
    
      if (mcu_cmd != event->cid)
      if (20001 != 1)
    
    The fix was sneaked by in the next commit 680a2ead741a (mt76: connac:
    introduce MCU_CE_CMD macro, 2021-12-09):
    
    -       int mcu_cmd = cmd & MCU_CMD_MASK;
    +       int mcu_cmd = FIELD_GET(__MCU_CMD_FIELD_ID, cmd);
    
    But it was never merged into linux-stable.
    
    We need either both commits, or none.
    
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Felipe Contreras <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 45809ba049fb35949483580d497ab65c521d3223
Author: Sing-Han Chen <[email protected]>
Date:   Wed Jan 12 17:41:43 2022 +0800

    ucsi_ccg: Check DEV_INT bit only when starting CCG4
    
    commit 825911492eb15bf8bb7fb94bc0c0421fe7a6327d upstream.
    
    CCGx clears Bit 0:Device Interrupt in the INTR_REG
    if CCGx is reset successfully. However, there might
    be a chance that other bits in INTR_REG are not
    cleared due to internal data queued in PPM. This case
    misleads the driver that CCGx reset failed.
    
    The commit checks bit 0 in INTR_REG and ignores other
    bits. The ucsi driver would reset PPM later.
    
    Fixes: 247c554a14aa ("usb: typec: ucsi: add support for Cypress CCGx")
    Cc: [email protected]
    Reviewed-by: Heikki Krogerus <[email protected]>
    Signed-off-by: Sing-Han Chen <[email protected]>
    Signed-off-by: Wayne Chang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 93f9cd5d6eafd2ffa971f8fe25d85a152f1c567f
Author: Badhri Jagan Sridharan <[email protected]>
Date:   Fri Jan 21 17:55:20 2022 -0800

    usb: typec: tcpm: Do not disconnect when receiving VSAFE0V
    
    commit 746f96e7d6f7a276726860f696671766bfb24cf0 upstream.
    
    With some chargers, vbus might momentarily raise above VSAFE5V and fall
    back to 0V causing VSAFE0V to be triggered. This will
    will report a VBUS off event causing TCPM to transition to
    SNK_UNATTACHED state where it should be waiting in either SNK_ATTACH_WAIT
    or SNK_DEBOUNCED state. This patch makes TCPM avoid VSAFE0V events
    while in SNK_ATTACH_WAIT or SNK_DEBOUNCED state.
    
    Stub from the spec:
        "4.5.2.2.4.2 Exiting from AttachWait.SNK State
        A Sink shall transition to Unattached.SNK when the state of both
        the CC1 and CC2 pins is SNK.Open for at least tPDDebounce.
        A DRP shall transition to Unattached.SRC when the state of both
        the CC1 and CC2 pins is SNK.Open for at least tPDDebounce."
    
    [23.194131] CC1: 0 -> 0, CC2: 0 -> 5 [state SNK_UNATTACHED, polarity 0, connected]
    [23.201777] state change SNK_UNATTACHED -> SNK_ATTACH_WAIT [rev3 NONE_AMS]
    [23.209949] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS]
    [23.300579] VBUS off
    [23.300668] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [rev3 NONE_AMS]
    [23.301014] VBUS VSAFE0V
    [23.301111] Start toggling
    
    Fixes: 28b43d3d746b8 ("usb: typec: tcpm: Introduce vsafe0v for vbus")
    Cc: [email protected]
    Acked-by: Heikki Krogerus <[email protected]>
    Signed-off-by: Badhri Jagan Sridharan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 941ee15e16d05e98bbc330307ba2975080a94034
Author: Badhri Jagan Sridharan <[email protected]>
Date:   Fri Jan 21 17:55:19 2022 -0800

    usb: typec: tcpm: Do not disconnect while receiving VBUS off
    
    commit 90b8aa9f5b09edae6928c0561f933fec9f7a9987 upstream.
    
    With some chargers, vbus might momentarily raise above VSAFE5V and fall
    back to 0V before tcpm gets to read port->tcpc->get_vbus. This will
    will report a VBUS off event causing TCPM to transition to
    SNK_UNATTACHED where it should be waiting in either SNK_ATTACH_WAIT
    or SNK_DEBOUNCED state. This patch makes TCPM avoid vbus off events
    while in SNK_ATTACH_WAIT or SNK_DEBOUNCED state.
    
    Stub from the spec:
        "4.5.2.2.4.2 Exiting from AttachWait.SNK State
        A Sink shall transition to Unattached.SNK when the state of both
        the CC1 and CC2 pins is SNK.Open for at least tPDDebounce.
        A DRP shall transition to Unattached.SRC when the state of both
        the CC1 and CC2 pins is SNK.Open for at least tPDDebounce."
    
    [23.194131] CC1: 0 -> 0, CC2: 0 -> 5 [state SNK_UNATTACHED, polarity 0, connected]
    [23.201777] state change SNK_UNATTACHED -> SNK_ATTACH_WAIT [rev3 NONE_AMS]
    [23.209949] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS]
    [23.300579] VBUS off
    [23.300668] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [rev3 NONE_AMS]
    [23.301014] VBUS VSAFE0V
    [23.301111] Start toggling
    
    Fixes: f0690a25a140b8 ("staging: typec: USB Type-C Port Manager (tcpm)")
    Cc: [email protected]
    Acked-by: Heikki Krogerus <[email protected]>
    Signed-off-by: Badhri Jagan Sridharan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bfc1412cb1220367a94fc8f6a961526be8a4d1d7
Author: Xu Yang <[email protected]>
Date:   Thu Jan 13 17:29:43 2022 +0800

    usb: typec: tcpci: don't touch CC line if it's Vconn source
    
    commit 5638b0dfb6921f69943c705383ff40fb64b987f2 upstream.
    
    With the AMS and Collision Avoidance, tcpm often needs to change the CC's
    termination. When one CC line is sourcing Vconn, if we still change its
    termination, the voltage of the another CC line is likely to be fluctuant
    and unstable.
    
    Therefore, we should verify whether a CC line is sourcing Vconn before
    changing its termination and only change the termination that is not
    a Vconn line. This can be done by reading the Vconn Present bit of
    POWER_ STATUS register. To determine the polarity, we can read the
    Plug Orientation bit of TCPC_CONTROL register. Since Vconn can only be
    sourced if Plug Orientation is set.
    
    Fixes: 0908c5aca31e ("usb: typec: tcpm: AMS and Collision Avoidance")
    cc: <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Acked-by: Heikki Krogerus <[email protected]>
    Signed-off-by: Xu Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c9a18f7c5b071dce5e6939568829d40994866ab0
Author: Alan Stern <[email protected]>
Date:   Mon Jan 24 15:23:45 2022 -0500

    USB: core: Fix hang in usb_kill_urb by adding memory barriers
    
    commit 26fbe9772b8c459687930511444ce443011f86bf upstream.
    
    The syzbot fuzzer has identified a bug in which processes hang waiting
    for usb_kill_urb() to return.  It turns out the issue is not unlinking
    the URB; that works just fine.  Rather, the problem arises when the
    wakeup notification that the URB has completed is not received.
    
    The reason is memory-access ordering on SMP systems.  In outline form,
    usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on
    different CPUs perform the following actions:
    
    CPU 0                                   CPU 1
    ----------------------------            ---------------------------------
    usb_kill_urb():                         __usb_hcd_giveback_urb():
      ...                                     ...
      atomic_inc(&urb->reject);               atomic_dec(&urb->use_count);
      ...                                     ...
      wait_event(usb_kill_urb_queue,
            atomic_read(&urb->use_count) == 0);
                                              if (atomic_read(&urb->reject))
                                                    wake_up(&usb_kill_urb_queue);
    
    Confining your attention to urb->reject and urb->use_count, you can
    see that the overall pattern of accesses on CPU 0 is:
    
            write urb->reject, then read urb->use_count;
    
    whereas the overall pattern of accesses on CPU 1 is:
    
            write urb->use_count, then read urb->reject.
    
    This pattern is referred to in memory-model circles as SB (for "Store
    Buffering"), and it is well known that without suitable enforcement of
    the desired order of accesses -- in the form of memory barriers -- it
    is entirely possible for one or both CPUs to execute their reads ahead
    of their writes.  The end result will be that sometimes CPU 0 sees the
    old un-decremented value of urb->use_count while CPU 1 sees the old
    un-incremented value of urb->reject.  Consequently CPU 0 ends up on
    the wait queue and never gets woken up, leading to the observed hang
    in usb_kill_urb().
    
    The same pattern of accesses occurs in usb_poison_urb() and the
    failure pathway of usb_hcd_submit_urb().
    
    The problem is fixed by adding suitable memory barriers.  To provide
    proper memory-access ordering in the SB pattern, a full barrier is
    required on both CPUs.  The atomic_inc() and atomic_dec() accesses
    themselves don't provide any memory ordering, but since they are
    present, we can use the optimized smp_mb__after_atomic() memory
    barrier in the various routines to obtain the desired effect.
    
    This patch adds the necessary memory barriers.
    
    CC: <[email protected]>
    Reported-and-tested-by: [email protected]
    Signed-off-by: Alan Stern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3095502581ca3822c1cec10ca5897de1a3945959
Author: Robert Hancock <[email protected]>
Date:   Tue Jan 25 18:02:51 2022 -0600

    usb: dwc3: xilinx: Fix error handling when getting USB3 PHY
    
    commit 2cc9b1c93b1c4caa2d971856c0780fb5f7d04692 upstream.
    
    The code that looked up the USB3 PHY was ignoring all errors other than
    EPROBE_DEFER in an attempt to handle the PHY not being present. Fix and
    simplify the code by using devm_phy_optional_get and dev_err_probe so
    that a missing PHY is not treated as an error and unexpected errors
    are handled properly.
    
    Fixes: 84770f028fab ("usb: dwc3: Add driver for Xilinx platforms")
    Cc: stable <[email protected]>
    Signed-off-by: Robert Hancock <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5d4f90bd9131b16e1df1e828aaed2e694215bd32
Author: Robert Hancock <[email protected]>
Date:   Tue Jan 25 18:02:50 2022 -0600

    usb: dwc3: xilinx: Skip resets and USB3 register settings for USB2.0 mode
    
    commit 9678f3361afc27a3124cd2824aec0227739986fb upstream.
    
    It appears that the PIPE clock should not be selected when only USB 2.0
    is being used in the design and no USB 3.0 reference clock is used.
    Also, the core resets are not required if a USB3 PHY is not in use, and
    will break things if USB3 is actually used but the PHY entry is not
    listed in the device tree.
    
    Skip core resets and register settings that are only required for
    USB3 mode when no USB3 PHY is specified in the device tree.
    
    Fixes: 84770f028fab ("usb: dwc3: Add driver for Xilinx platforms")
    Cc: stable <[email protected]>
    Signed-off-by: Robert Hancock <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 315f8a59fe1a57e09c3d471d29fbe70aaf9cd988
Author: Pawel Laszczak <[email protected]>
Date:   Tue Jan 11 10:07:37 2022 +0100

    usb: cdnsp: Fix segmentation fault in cdns_lost_power function
    
    commit 79aa3e19fe8f5be30e846df8a436bfe306e8b1a6 upstream.
    
    CDNSP driver read not initialized cdns->otg_v0_regs
    which lead to segmentation fault. Patch fixes this issue.
    
    Fixes: 2cf2581cd229 ("usb: cdns3: add power lost support for system resume")
    cc: <[email protected]>
    Signed-off-by: Pawel Laszczak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 103938dd5798e150689362290274b87af54e3a52
Author: Pavankumar Kondeti <[email protected]>
Date:   Sat Jan 22 08:33:22 2022 +0530

    usb: gadget: f_sourcesink: Fix isoc transfer for USB_SPEED_SUPER_PLUS
    
    commit 904edf8aeb459697129be5fde847e2a502f41fd9 upstream.
    
    Currently when gadget enumerates in super speed plus, the isoc
    endpoint request buffer size is not calculated correctly. Fix
    this by checking the gadget speed against USB_SPEED_SUPER_PLUS
    and update the request buffer size.
    
    Fixes: 90c4d05780d4 ("usb: fix various gadgets null ptr deref on 10gbps cabling.")
    Cc: stable <[email protected]>
    Signed-off-by: Pavankumar Kondeti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 284ef44a8b233b15b5fe29e049cdf6218ccee15d
Author: Jon Hunter <[email protected]>
Date:   Mon Jan 17 15:00:39 2022 +0000

    usb: common: ulpi: Fix crash in ulpi_match()
    
    commit 2e3dd4a6246945bf84ea6f478365d116e661554c upstream.
    
    Commit 7495af930835 ("ARM: multi_v7_defconfig: Enable drivers for
    DragonBoard 410c") enables the CONFIG_PHY_QCOM_USB_HS for the ARM
    multi_v7_defconfig. Enabling this Kconfig is causing the kernel to crash
    on the Tegra20 Ventana platform in the ulpi_match() function.
    
    The Qualcomm USB HS PHY driver that is enabled by CONFIG_PHY_QCOM_USB_HS,
    registers a ulpi_driver but this driver does not provide an 'id_table',
    so when ulpi_match() is called on the Tegra20 Ventana platform, it
    crashes when attempting to deference the id_table pointer which is not
    valid. The Qualcomm USB HS PHY driver uses device-tree for matching the
    ULPI driver with the device and so fix this crash by using device-tree
    for matching if the id_table is not valid.
    
    Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT")
    Cc: stable <[email protected]>
    Signed-off-by: Jon Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8b05ad29acb972850ad795fa850e814b2e758b83
Author: Frank Li <[email protected]>
Date:   Mon Jan 10 11:27:38 2022 -0600

    usb: xhci-plat: fix crash when suspend if remote wake enable
    
    commit 9df478463d9feb90dae24f183383961cf123a0ec upstream.
    
    Crashed at i.mx8qm platform when suspend if enable remote wakeup
    
    Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12
    Hardware name: Freescale i.MX8QM MEK (DT)
    Workqueue: events_unbound async_run_entry_fn
    pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8
    lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8
    sp : ffff80001394bbf0
    x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578
    x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000
    x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001
    x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
    x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000
    x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0
    x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453
    x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c
    x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620
    Call trace:
     xhci_disable_hub_port_wake.isra.62+0x60/0xf8
     xhci_suspend+0x58/0x510
     xhci_plat_suspend+0x50/0x78
     platform_pm_suspend+0x2c/0x78
     dpm_run_callback.isra.25+0x50/0xe8
     __device_suspend+0x108/0x3c0
    
    The basic flow:
            1. run time suspend call xhci_suspend, xhci parent devices gate the clock.
            2. echo mem >/sys/power/state, system _device_suspend call xhci_suspend
            3. xhci_suspend call xhci_disable_hub_port_wake, which access register,
               but clock already gated by run time suspend.
    
    This problem was hidden by power domain driver, which call run time resume before it.
    
    But the below commit remove it and make this issue happen.
            commit c1df456d0f06e ("PM: domains: Don't runtime resume devices at genpd_prepare()")
    
    This patch call run time resume before suspend to make sure clock is on
    before access register.
    
    Reviewed-by: Peter Chen <[email protected]>
    Cc: stable <[email protected]>
    Signed-off-by: Frank Li <[email protected]>
    Testeb-by: Abel Vesa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e813a5e6c14a86e3957dc7b3b9b22c0d803d9df5
Author: Alan Stern <[email protected]>
Date:   Mon Jan 24 15:14:40 2022 -0500

    usb-storage: Add unusual-devs entry for VL817 USB-SATA bridge
    
    commit 5b67b315037250a61861119683e7fcb509deea25 upstream.
    
    Two people have reported (and mentioned numerous other reports on the
    web) that VIA's VL817 USB-SATA bridge does not work with the uas
    driver.  Typical log messages are:
    
    [ 3606.232149] sd 14:0:0:0: [sdg] tag#2 uas_zap_pending 0 uas-tag 1 inflight: CMD
    [ 3606.232154] sd 14:0:0:0: [sdg] tag#2 CDB: Write(16) 8a 00 00 00 00 00 18 0c c9 80 00 00 00 80 00 00
    [ 3606.306257] usb 4-4.4: reset SuperSpeed Plus Gen 2x1 USB device number 11 using xhci_hcd
    [ 3606.328584] scsi host14: uas_eh_device_reset_handler success
    
    Surprisingly, the devices do seem to work okay for some other people.
    The cause of the differing behaviors is not known.
    
    In the hope of getting the devices to work for the most users, even at
    the possible cost of degraded performance for some, this patch adds an
    unusual_devs entry for the VL817 to block it from binding to the uas
    driver by default.  Users will be able to override this entry by means
    of a module parameter, if they want.
    
    CC: <[email protected]>
    Reported-by: DocMAX <[email protected]>
    Reported-and-tested-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Alan Stern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 820a55c1f87b26ffe11895b3586e4fd80fd14161
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Jan 27 08:33:04 2022 +0100

    kbuild: remove include/linux/cyclades.h from header file check
    
    commit d1ad2721b1eb05d54e81393a7ebc332d4a35c68f upstream.
    
    The file now rightfully throws up a big warning that it should never be
    included, so remove it from the header_check test.
    
    Fixes: f23653fe6447 ("tty: Partially revert the removal of the Cyclades public API")
    Cc: stable <[email protected]>
    Cc: Masahiro Yamada <[email protected]>
    Cc: "Maciej W. Rozycki" <[email protected]>
    Reported-by: Stephen Rothwell <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9155ccf72afceb4714c4eaed1dcbcc9d6f964131
Author: Cameron Williams <[email protected]>
Date:   Mon Jan 24 09:42:23 2022 +0000

    tty: Add support for Brainboxes UC cards.
    
    commit 152d1afa834c84530828ee031cf07a00e0fc0b8c upstream.
    
    This commit adds support for the some of the Brainboxes PCI range of
    cards, including the UC-101, UC-235/246, UC-257, UC-268, UC-275/279,
    UC-302, UC-310, UC-313, UC-320/324, UC-346, UC-357, UC-368
    and UC-420/431.
    
    Signed-off-by: Cameron Williams <[email protected]>
    Cc: stable <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]2.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 820f5c4af492aca9e9a989004a4b1b31426ce816
Author: Maciej W. Rozycki <[email protected]>
Date:   Wed Jan 26 09:22:54 2022 +0000

    tty: Partially revert the removal of the Cyclades public API
    
    commit f23653fe64479d96910bfda2b700b1af17c991ac upstream.
    
    Fix a user API regression introduced with commit f76edd8f7ce0 ("tty:
    cyclades, remove this orphan"), which removed a part of the API and
    caused compilation errors for user programs using said part, such as
    GCC 9 in its libsanitizer component[1]:
    
    .../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:160:10: fatal error: linux/cyclades.h: No such file or directory
      160 | #include <linux/cyclades.h>
          |          ^~~~~~~~~~~~~~~~~~
    compilation terminated.
    make[4]: *** [Makefile:664: sanitizer_platform_limits_posix.lo] Error 1
    
    As the absolute minimum required bring `struct cyclades_monitor' and
    ioctl numbers back then so as to make the library build again.  Add a
    preprocessor warning as to the obsolescence of the features provided.
    
    References:
    
    [1] GCC PR sanitizer/100379, "cyclades.h is removed from linux kernel
        header files", <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379>
    
    Fixes: f76edd8f7ce0 ("tty: cyclades, remove this orphan")
    Cc: [email protected] # v5.13+
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Maciej W. Rozycki <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e1ed8832264689c24d49c9a84759b4229c9f23b7
Author: [email protected] <[email protected]>
Date:   Thu Jan 20 02:18:57 2022 -0800

    tty: n_gsm: fix SW flow control encoding/handling
    
    commit 8838b2af23caf1ff0610caef2795d6668a013b2d upstream.
    
    n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010.
    See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516
    The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to
    the newer 27.010 here. Chapter 5.2.7.3 states that DC1 (XON) and DC3 (XOFF)
    are the control characters defined in ISO/IEC 646. These shall be quoted if
    seen in the data stream to avoid interpretation as flow control characters.
    
    ISO/IEC 646 refers to the set of ISO standards described as the ISO
    7-bit coded character set for information interchange. Its final version
    is also known as ITU T.50.
    See https://www.itu.int/rec/T-REC-T.50-199209-I/en
    
    To abide the standard it is needed to quote DC1 and DC3 correctly if these
    are seen as data bytes and not as control characters. The current
    implementation already tries to enforce this but fails to catch all
    defined cases. 3GPP 27.010 chapter 5.2.7.3 clearly states that the most
    significant bit shall be ignored for DC1 and DC3 handling. The current
    implementation handles only the case with the most significant bit set 0.
    Cases in which DC1 and DC3 have the most significant bit set 1 are left
    unhandled.
    
    This patch fixes this by masking the data bytes with ISO_IEC_646_MASK (only
    the 7 least significant bits set 1) before comparing them with XON
    (a.k.a. DC1) and XOFF (a.k.a. DC3) when testing which byte values need
    quotation via byte stuffing.
    
    Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
    Cc: [email protected]
    Signed-off-by: Daniel Starke <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit eefd8f6e0ae9e631d102f6f289c54ef2f1294bee
Author: Arnaud Pouliquen <[email protected]>
Date:   Tue Jan 4 17:35:45 2022 +0100

    tty: rpmsg: Fix race condition releasing tty port
    
    commit db7f19c0aa0abcb751ff0ed694a071363f702b1d upstream.
    
    The tty_port struct is part of the rpmsg_tty_port structure.
    The issue is that the rpmsg_tty_port structure is freed on
    rpmsg_tty_remove while it is still referenced in the tty_struct.
    Its release is not predictable due to workqueues.
    
    For instance following ftrace shows that rpmsg_tty_close is called after
    rpmsg_tty_release_cport:
    
         nr_test.sh-389     [000] .....   212.093752: rpmsg_tty_remove <-rpmsg_dev_
    remove
                 cat-1191    [001] .....   212.095697: tty_release <-__fput
          nr_test.sh-389     [000] .....   212.099166: rpmsg_tty_release_cport <-rpm
    sg_tty_remove
                 cat-1191    [001] .....   212.115352: rpmsg_tty_close <-tty_release
                 cat-1191    [001] .....   212.115371: release_tty <-tty_release_str
    
    As consequence, the port must be free only when user has released the TTY
    interface.
    
    This path :
    - Introduce the .destruct port tty ops function to release the allocated
      rpmsg_tty_port structure.
    - Introduce the .hangup tty ops function to call tty_port_hangup.
    - Manages the tty port refcounting to trig the .destruct port ops,
    - Introduces the rpmsg_tty_cleanup function to ensure that the TTY is
      removed before decreasing the port refcount.
    
    Fixes: 7c0408d80579 ("tty: add rpmsg driver")
    Cc: stable <[email protected]>
    Signed-off-by: Arnaud Pouliquen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1b8b83b8fa221c74e9aae76a2d50308a32c98302
Author: Valentin Caron <[email protected]>
Date:   Tue Jan 11 17:44:41 2022 +0100

    serial: stm32: fix software flow control transfer
    
    commit 037b91ec7729524107982e36ec4b40f9b174f7a2 upstream.
    
    x_char is ignored by stm32_usart_start_tx() when xmit buffer is empty.
    
    Fix start_tx condition to allow x_char to be sent.
    
    Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver")
    Cc: stable <[email protected]>
    Signed-off-by: Erwan Le Ray <[email protected]>
    Signed-off-by: Valentin Caron <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2cfc85132bfa1d704fec3d2aa77c6ca0fda2b772
Author: Robert Hancock <[email protected]>
Date:   Wed Jan 12 13:42:14 2022 -0600

    serial: 8250: of: Fix mapped region size when using reg-offset property
    
    commit d06b1cf28297e27127d3da54753a3a01a2fa2f28 upstream.
    
    8250_of supports a reg-offset property which is intended to handle
    cases where the device registers start at an offset inside the region
    of memory allocated to the device. The Xilinx 16550 UART, for which this
    support was initially added, requires this. However, the code did not
    adjust the overall size of the mapped region accordingly, causing the
    driver to request an area of memory past the end of the device's
    allocation. For example, if the UART was allocated an address of
    0xb0130000, size of 0x10000 and reg-offset of 0x1000 in the device
    tree, the region of memory reserved was b0131000-b0140fff, which caused
    the driver for the region starting at b0140000 to fail to probe.
    
    Fix this by subtracting reg-offset from the mapped region size.
    
    Fixes: b912b5e2cfb3 ([POWERPC] Xilinx: of_serial support for Xilinx uart 16550.)
    Cc: stable <[email protected]>
    Signed-off-by: Robert Hancock <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 15c513baf4ae229f4f36e13716043a52c44e7748
Author: Jochen Mades <[email protected]>
Date:   Sat Jan 23 05:10:14 2021 +0100

    serial: pl011: Fix incorrect rs485 RTS polarity on set_mctrl
    
    commit 62f676ff7898f6c1bd26ce014564773a3dc00601 upstream.
    
    Commit 8d479237727c ("serial: amba-pl011: add RS485 support") sought to
    keep RTS deasserted on set_mctrl if rs485 is enabled.  However it did so
    only if deasserted RTS polarity is high.  Fix it in case it's low.
    
    Fixes: 8d479237727c ("serial: amba-pl011: add RS485 support")
    Cc: [email protected] # v5.15+
    Cc: Lino Sanfilippo <[email protected]>
    Signed-off-by: Jochen Mades <[email protected]>
    [lukas: copyedit commit message, add stable designation]
    Signed-off-by: Lukas Wunner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]nner.de
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 59274a00b13ef4352dc2e54438cddedff67c2f3e
Author: Mike Snitzer <[email protected]>
Date:   Fri Jan 28 10:58:41 2022 -0500

    dm: properly fix redundant bio-based IO accounting
    
    commit b879f915bc48a18d4f4462729192435bb0f17052 upstream.
    
    Record the start_time for a bio but defer the starting block core's IO
    accounting until after IO is submitted using bio_start_io_acct_time().
    
    This approach avoids the need to mess around with any of the
    individual IO stats in response to a bio_split() that follows bio
    submission.
    
    Reported-by: Bud Brown <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Cc: [email protected]
    Depends-on: e45c47d1f94e ("block: add bio_start_io_acct_time() to control start_time")
    Signed-off-by: Mike Snitzer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a7f5b1a95fc7245bfa40e07907e8b5ac0878a709
Author: Mike Snitzer <[email protected]>
Date:   Fri Jan 28 10:58:39 2022 -0500

    block: add bio_start_io_acct_time() to control start_time
    
    commit e45c47d1f94e0cc7b6b079fdb4bcce2995e2adc4 upstream.
    
    bio_start_io_acct_time() interface is like bio_start_io_acct() that
    allows start_time to be passed in. This gives drivers the ability to
    defer starting accounting until after IO is issued (but possibily not
    entirely due to bio splitting).
    
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit dc93c7ad7092329a54d99f2ccb797a76908a0739
Author: Mike Snitzer <[email protected]>
Date:   Fri Jan 28 10:58:40 2022 -0500

    dm: revert partial fix for redundant bio-based IO accounting
    
    commit f524d9c95fab54783d0038f7a3e8c014d5b56857 upstream.
    
    Reverts a1e1cb72d9649 ("dm: fix redundant IO accounting for bios that
    need splitting") because it was too narrow in scope (only addressed
    redundant 'sectors[]' accounting and not ios, nsecs[], etc).
    
    Cc: [email protected]
    Signed-off-by: Mike Snitzer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 47fe7a1c5e3e011eeb4ab79f2d54a794fdd1c3eb
Author: Evgenii Stepanov <[email protected]>
Date:   Tue Jan 25 10:22:17 2022 -0800

    arm64: extable: fix load_unaligned_zeropad() reg indices
    
    commit 3758a6c74e08bdc15ccccd6872a6ad37d165239a upstream.
    
    In ex_handler_load_unaligned_zeropad() we erroneously extract the data and
    addr register indices from ex->type rather than ex->data. As ex->type will
    contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4):
     * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is
       extracted from bits [9:5]. Thus, we may attempt to dereference an
       arbitrary address as X0 may hold an arbitrary value.
     * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is
       extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary
       behaviour within load_unaligned_zeropad() and its caller.
    
    Fix this by extracting both values from ex->data as originally intended.
    
    On an MTE-enabled QEMU image we are hitting the following crash:
     Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
     Call trace:
      fixup_exception+0xc4/0x108
      __do_kernel_fault+0x3c/0x268
      do_tag_check_fault+0x3c/0x104
      do_mem_abort+0x44/0xf4
      el1_abort+0x40/0x64
      el1h_64_sync_handler+0x60/0xa0
      el1h_64_sync+0x7c/0x80
      link_path_walk+0x150/0x344
      path_openat+0xa0/0x7dc
      do_filp_open+0xb8/0x168
      do_sys_openat2+0x88/0x17c
      __arm64_sys_openat+0x74/0xa0
      invoke_syscall+0x48/0x148
      el0_svc_common+0xb8/0xf8
      do_el0_svc+0x28/0x88
      el0_svc+0x24/0x84
      el0t_64_sync_handler+0x88/0xec
      el0t_64_sync+0x1b4/0x1b8
     Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)
    
    Fixes: 753b32368705 ("arm64: extable: add load_unaligned_zeropad() handler")
    Cc: <[email protected]> # 5.16.x
    Reviewed-by: Mark Rutland <[email protected]>
    Signed-off-by: Evgenii Stepanov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Catalin Marinas <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b830fd118fddf4af0a41027dfc2a3dfb85b62e25
Author: Vivek Goyal <[email protected]>
Date:   Wed Jan 26 15:35:14 2022 -0500

    security, lsm: dentry_init_security() Handle multi LSM registration
    
    commit 7f5056b9e7b71149bf11073f00a57fa1ac2921a9 upstream.
    
    A ceph user has reported that ceph is crashing with kernel NULL pointer
    dereference. Following is the backtrace.
    
    /proc/version: Linux version 5.16.2-arch1-1 ([email protected]) (gcc (GCC)
    11.1.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP PREEMPT Thu, 20 Jan 2022
    16:18:29 +0000
    distro / arch: Arch Linux / x86_64
    SELinux is not enabled
    ceph cluster version: 16.2.7 (dd0603118f56ab514f133c8d2e3adfc983942503)
    
    relevant dmesg output:
    [   30.947129] BUG: kernel NULL pointer dereference, address:
    0000000000000000
    [   30.947206] #PF: supervisor read access in kernel mode
    [   30.947258] #PF: error_code(0x0000) - not-present page
    [   30.947310] PGD 0 P4D 0
    [   30.947342] Oops: 0000 [#1] PREEMPT SMP PTI
    [   30.947388] CPU: 5 PID: 778 Comm: touch Not tainted 5.16.2-arch1-1 #1
    86fbf2c313cc37a553d65deb81d98e9dcc2a3659
    [   30.947486] Hardware name: Gigabyte Technology Co., Ltd. B365M
    DS3H/B365M DS3H, BIOS F5 08/13/2019
    [   30.947569] RIP: 0010:strlen+0x0/0x20
    [   30.947616] Code: b6 07 38 d0 74 16 48 83 c7 01 84 c0 74 05 48 39 f7 75
    ec 31 c0 31 d2 89 d6 89 d7 c3 48 89 f8 31 d2 89 d6 89 d7 c3 0
    f 1f 40 00 <80> 3f 00 74 12 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 31
    ff
    [   30.947782] RSP: 0018:ffffa4ed80ffbbb8 EFLAGS: 00010246
    [   30.947836] RAX: 0000000000000000 RBX: ffffa4ed80ffbc60 RCX:
    0000000000000000
    [   30.947904] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
    0000000000000000
    [   30.947971] RBP: ffff94b0d15c0ae0 R08: 0000000000000000 R09:
    0000000000000000
    [   30.948040] R10: 0000000000000000 R11: 0000000000000000 R12:
    0000000000000000
    [   30.948106] R13: 0000000000000001 R14: ffffa4ed80ffbc60 R15:
    0000000000000000
    [   30.948174] FS:  00007fc7520f0740(0000) GS:ffff94b7ced40000(0000)
    knlGS:0000000000000000
    [   30.948252] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   30.948308] CR2: 0000000000000000 CR3: 0000000104a40001 CR4:
    00000000003706e0
    [   30.948376] Call Trace:
    [   30.948404]  <TASK>
    [   30.948431]  ceph_security_init_secctx+0x7b/0x240 [ceph
    49f9c4b9bf5be8760f19f1747e26da33920bce4b]
    [   30.948582]  ceph_atomic_open+0x51e/0x8a0 [ceph
    49f9c4b9bf5be8760f19f1747e26da33920bce4b]
    [   30.948708]  ? get_cached_acl+0x4d/0xa0
    [   30.948759]  path_openat+0x60d/0x1030
    [   30.948809]  do_filp_open+0xa5/0x150
    [   30.948859]  do_sys_openat2+0xc4/0x190
    [   30.948904]  __x64_sys_openat+0x53/0xa0
    [   30.948948]  do_syscall_64+0x5c/0x90
    [   30.948989]  ? exc_page_fault+0x72/0x180
    [   30.949034]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [   30.949091] RIP: 0033:0x7fc7521e25bb
    [   30.950849] Code: 25 00 00 41 00 3d 00 00 41 00 74 4b 64 8b 04 25 18 00
    00 00 85 c0 75 67 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 0
    0 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 91 00 00 00 48 8b 54 24 28 64 48 2b 14
    25
    
    Core of the problem is that ceph checks for return code from
    security_dentry_init_security() and if return code is 0, it assumes
    everything is fine and continues to call strlen(name), which crashes.
    
    Typically SELinux LSM returns 0 and sets name to "security.selinux" and
    it is not a problem. Or if selinux is not compiled in or disabled, it
    returns -EOPNOTSUP and ceph deals with it.
    
    But somehow in this configuration, 0 is being returned and "name" is
    not being initialized and that's creating the problem.
    
    Our suspicion is that BPF LSM is registering a hook for
    dentry_init_security() and returns hook default of 0.
    
    LSM_HOOK(int, 0, dentry_init_security, struct dentry *dentry,...)
    
    I have not been able to reproduce it just by doing CONFIG_BPF_LSM=y.
    Stephen has tested the patch though and confirms it solves the problem
    for him.
    
    dentry_init_security() is written in such a way that it expects only one
    LSM to register the hook. Atleast that's the expectation with current code.
    
    If another LSM returns a hook and returns default, it will simply return
    0 as of now and that will break ceph.
    
    Hence, suggestion is that change semantics of this hook a bit. If there
    are no LSMs or no LSM is taking ownership and initializing security context,
    then return -EOPNOTSUP. Also allow at max one LSM to initialize security
    context. This hook can't deal with multiple LSMs trying to init security
    context. This patch implements this new behavior.
    
    Reported-by: Stephen Muth <[email protected]>
    Tested-by: Stephen Muth <[email protected]>
    Suggested-by: Casey Schaufler <[email protected]>
    Acked-by: Casey Schaufler <[email protected]>
    Reviewed-by: Serge Hallyn <[email protected]>
    Cc: Jeff Layton <[email protected]>
    Cc: Christian Brauner <[email protected]>
    Cc: Paul Moore <[email protected]>
    Cc: <[email protected]> # 5.16.0
    Signed-off-by: Vivek Goyal <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Acked-by: Paul Moore <[email protected]>
    Acked-by: Christian Brauner <[email protected]>
    Signed-off-by: James Morris <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1699bd143077c6de1dd314fa1ff231a6173cf8fe
Author: Nicholas Piggin <[email protected]>
Date:   Sat Jan 22 20:55:30 2022 +1000

    KVM: PPC: Book3S HV Nested: Fix nested HFSCR being clobbered with multiple vCPUs
    
    commit 22f7ff0dea9491e90b6fe808ed40c30bd791e5c2 upstream.
    
    The L0 is storing HFSCR requested by the L1 for the L2 in struct
    kvm_nested_guest when the L1 requests a vCPU enter L2. kvm_nested_guest
    is not a per-vCPU structure. Hilarity ensues.
    
    Fix it by moving the nested hfscr into the vCPU structure together with
    the other per-vCPU nested fields.
    
    Fixes: 8b210a880b35 ("KVM: PPC: Book3S HV Nested: Make nested HFSCR state accessible")
    Cc: [email protected] # v5.15+
    Signed-off-by: Nicholas Piggin <[email protected]>
    Reviewed-by: Fabiano Rosas <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e9bf4e129d8b78886c88a6a94200bc401c72b7ab
Author: Like Xu <[email protected]>
Date:   Wed Jan 26 17:22:26 2022 +0000

    KVM: x86: Sync the states size with the XCR0/IA32_XSS at, any time
    
    commit 05a9e065059e566f218f8778c4d17ee75db56c55 upstream.
    
    XCR0 is reset to 1 by RESET but not INIT and IA32_XSS is zeroed by
    both RESET and INIT. The kvm_set_msr_common()'s handling of MSR_IA32_XSS
    also needs to update kvm_update_cpuid_runtime(). In the above cases, the
    size in bytes of the XSAVE area containing all states enabled by XCR0 or
    (XCRO | IA32_XSS) needs to be updated.
    
    For simplicity and consistency, existing helpers are used to write values
    and call kvm_update_cpuid_runtime(), and it's not exactly a fast path.
    
    Fixes: a554d207dc46 ("KVM: X86: Processor States following Reset or INIT")
    Cc: [email protected]
    Signed-off-by: Like Xu <[email protected]>
    Signed-off-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0c5130cccf4a420a44820463ac8168b32cab6d47
Author: Like Xu <[email protected]>
Date:   Wed Jan 26 17:22:25 2022 +0000

    KVM: x86: Update vCPU's runtime CPUID on write to MSR_IA32_XSS
    
    commit 4c282e51e4450b94680d6ca3b10f830483b1f243 upstream.
    
    Do a runtime CPUID update for a vCPU if MSR_IA32_XSS is written, as the
    size in bytes of the XSAVE area is affected by the states enabled in XSS.
    
    Fixes: 203000993de5 ("kvm: vmx: add MSR logic for XSAVES")
    Cc: [email protected]
    Signed-off-by: Like Xu <[email protected]>
    [sean: split out as a separate patch, adjust Fixes tag]
    Signed-off-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b9a33734fb79292972cc8933e99a24ab9a2420fa
Author: Xiaoyao Li <[email protected]>
Date:   Wed Jan 26 17:22:24 2022 +0000

    KVM: x86: Keep MSR_IA32_XSS unchanged for INIT
    
    commit be4f3b3f82271c3193ce200a996dc70682c8e622 upstream.
    
    It has been corrected from SDM version 075 that MSR_IA32_XSS is reset to
    zero on Power up and Reset but keeps unchanged on INIT.
    
    Fixes: a554d207dc46 ("KVM: X86: Processor States following Reset or INIT")
    Cc: [email protected]
    Signed-off-by: Xiaoyao Li <[email protected]>
    Signed-off-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b7d0597c69096be963c4a22449697e90467f6b2a
Author: Vitaly Kuznetsov <[email protected]>
Date:   Wed Jan 26 14:18:04 2022 +0100

    KVM: x86: Check .flags in kvm_cpuid_check_equal() too
    
    commit 033a3ea59a19df63edb4db6bfdbb357cd028258a upstream.
    
    kvm_cpuid_check_equal() checks for the (full) equality of the supplied
    CPUID data so .flags need to be checked too.
    
    Reported-by: Sean Christopherson <[email protected]>
    Fixes: c6617c61e8fe ("KVM: x86: Partially allow KVM_SET_CPUID{,2} after KVM_RUN")
    Signed-off-by: Vitaly Kuznetsov <[email protected]>
    Message-Id: <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b4c0d89c92e957ecccce12e66b63875d0cc7af7e
Author: Sean Christopherson <[email protected]>
Date:   Tue Jan 25 22:03:58 2022 +0000

    KVM: x86: Forcibly leave nested virt when SMM state is toggled
    
    commit f7e570780efc5cec9b2ed1e0472a7da14e864fdb upstream.
    
    Forcibly leave nested virtualization operation if userspace toggles SMM
    state via KVM_SET_VCPU_EVENTS or KVM_SYNC_X86_EVENTS.  If userspace
    forces the vCPU out of SMM while it's post-VMXON and then injects an SMI,
    vmx_enter_smm() will overwrite vmx->nested.smm.vmxon and end up with both
    vmxon=false and smm.vmxon=false, but all other nVMX state allocated.
    
    Don't attempt to gracefully handle the transition as (a) most transitions
    are nonsencial, e.g. forcing SMM while L2 is running, (b) there isn't
    sufficient information to handle all transitions, e.g. SVM wants access
    to the SMRAM save state, and (c) KVM_SET_VCPU_EVENTS must precede
    KVM_SET_NESTED_STATE during state restore as the latter disallows putting
    the vCPU into L2 if SMM is active, and disallows tagging the vCPU as
    being post-VMXON in SMM if SMM is not active.
    
    Abuse of KVM_SET_VCPU_EVENTS manifests as a WARN and memory leak in nVMX
    due to failure to free vmcs01's shadow VMCS, but the bug goes far beyond
    just a memory leak, e.g. toggling SMM on while L2 is active puts the vCPU
    in an architecturally impossible state.
    
      WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]
      WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656
      Modules linked in:
      CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]
      RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656
      Code: <0f> 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00
      Call Trace:
       <TASK>
       kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123
       kvm_vcpu_destroy arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 [inline]
       kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:460
       kvm_free_vcpus arch/x86/kvm/x86.c:11564 [inline]
       kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676
       kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1217 [inline]
       kvm_put_kvm+0x4fa/0xb00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1250
       kvm_vm_release+0x3f/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1273
       __fput+0x286/0x9f0 fs/file_table.c:311
       task_work_run+0xdd/0x1a0 kernel/task_work.c:164
       exit_task_work include/linux/task_work.h:32 [inline]
       do_exit+0xb29/0x2a30 kernel/exit.c:806
       do_group_exit+0xd2/0x2f0 kernel/exit.c:935
       get_signal+0x4b0/0x28c0 kernel/signal.c:2862
       arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868
       handle_signal_work kernel/entry/common.c:148 [inline]
       exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
       exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207
       __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]
       syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300
       do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
       entry_SYSCALL_64_after_hwframe+0x44/0xae
       </TASK>
    
    Cc: [email protected]
    Reported-by: [email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b9ee734a14bb685b2088f2176d82b34cb4e30dbc
Author: Sean Christopherson <[email protected]>
Date:   Tue Jan 25 21:04:45 2022 +0000

    KVM: x86: Free kvm_cpuid_entry2 array on post-KVM_RUN KVM_SET_CPUID{,2}
    
    commit 811f95ff95270e6048197821434d9301e3d7f07c upstream.
    
    Free the "struct kvm_cpuid_entry2" array on successful post-KVM_RUN
    KVM_SET_CPUID{,2} to fix a memory leak, the callers of kvm_set_cpuid()
    free the array only on failure.
    
     BUG: memory leak
     unreferenced object 0xffff88810963a800 (size 2048):
      comm "syz-executor025", pid 3610, jiffies 4294944928 (age 8.080s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 0d 00 00 00  ................
        47 65 6e 75 6e 74 65 6c 69 6e 65 49 00 00 00 00  GenuntelineI....
      backtrace:
        [<ffffffff814948ee>] kmalloc_node include/linux/slab.h:604 [inline]
        [<ffffffff814948ee>] kvmalloc_node+0x3e/0x100 mm/util.c:580
        [<ffffffff814950f2>] kvmalloc include/linux/slab.h:732 [inline]
        [<ffffffff814950f2>] vmemdup_user+0x22/0x100 mm/util.c:199
        [<ffffffff8109f5ff>] kvm_vcpu_ioctl_set_cpuid2+0x8f/0xf0 arch/x86/kvm/cpuid.c:423
        [<ffffffff810711b9>] kvm_arch_vcpu_ioctl+0xb99/0x1e60 arch/x86/kvm/x86.c:5251
        [<ffffffff8103e92d>] kvm_vcpu_ioctl+0x4ad/0x950 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4066
        [<ffffffff815afacc>] vfs_ioctl fs/ioctl.c:51 [inline]
        [<ffffffff815afacc>] __do_sys_ioctl fs/ioctl.c:874 [inline]
        [<ffffffff815afacc>] __se_sys_ioctl fs/ioctl.c:860 [inline]
        [<ffffffff815afacc>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860
        [<ffffffff844a3335>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
        [<ffffffff844a3335>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
        [<ffffffff84600068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fixes: c6617c61e8fe ("KVM: x86: Partially allow KVM_SET_CPUID{,2} after KVM_RUN")
    Cc: [email protected]
    Reported-by: [email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Reviewed-by: Vitaly Kuznetsov <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ab54b789cb075f67b20d8c3b58192a2f0e428687
Author: Vitaly Kuznetsov <[email protected]>
Date:   Mon Jan 24 11:36:05 2022 +0100

    KVM: x86: Move CPUID.(EAX=0x12,ECX=1) mangling to __kvm_update_cpuid_runtime()
    
    commit 5c89be1dd5cfb697614bc13626ba3bd0781aa160 upstream.
    
    Full equality check of CPUID data on update (kvm_cpuid_check_equal()) may
    fail for SGX enabled CPUs as CPUID.(EAX=0x12,ECX=1) is currently being
    mangled in kvm_vcpu_after_set_cpuid(). Move it to
    __kvm_update_cpuid_runtime() and split off cpuid_get_supported_xcr0()
    helper  as 'vcpu->arch.guest_supported_xcr0' update needs (logically)
    to stay in kvm_vcpu_after_set_cpuid().
    
    Cc: [email protected]
    Fixes: feb627e8d6f6 ("KVM: x86: Forbid KVM_SET_CPUID{,2} after KVM_RUN")
    Signed-off-by: Vitaly Kuznetsov <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f0c4ba4d5e11e0ae6d3f061b49bacc6a398f0a5a
Author: Denis Valeev <[email protected]>
Date:   Sat Jan 22 23:13:57 2022 +0300

    KVM: x86: nSVM: skip eax alignment check for non-SVM instructions
    
    commit 47c28d436f409f5b009dc82bd82d4971088aa391 upstream.
    
    The bug occurs on #GP triggered by VMware backdoor when eax value is
    unaligned. eax alignment check should not be applied to non-SVM
    instructions because it leads to incorrect omission of the instructions
    emulation.
    Apply the alignment check only to SVM instructions to fix.
    
    Fixes: d1cba6c92237 ("KVM: x86: nSVM: test eax for 4K alignment for GP errata workaround")
    Signed-off-by: Denis Valeev <[email protected]>
    Message-Id: <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c209aa816fb4590408e50ba735d9eb040e7be32d
Author: Sean Christopherson <[email protected]>
Date:   Thu Jan 20 01:07:13 2022 +0000

    KVM: SVM: Don't intercept #GP for SEV guests
    
    commit 0b0be065b7563ac708aaa9f69dd4941c80b3446d upstream.
    
    Never intercept #GP for SEV guests as reading SEV guest private memory
    will return cyphertext, i.e. emulating on #GP can't work as intended.
    
    Cc: [email protected]
    Cc: Tom Lendacky <[email protected]>
    Cc: Brijesh Singh <[email protected]>
    Signed-off-by: Sean Christopherson <[email protected]>
    Reviewed-by: Liam Merwick <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0b0dd3ef2d3586cc6518fe2430aa29a208ded295
Author: Sean Christopherson <[email protected]>
Date:   Thu Jan 20 01:07:11 2022 +0000

    KVM: SVM: Never reject emulation due to SMAP errata for !SEV guests
    
    commit 55467fcd55b89c622e62b4afe60ac0eb2fae91f2 upstream.
    
    Always signal that emulation is possible for !SEV guests regardless of
    whether or not the CPU provided a valid instruction byte stream.  KVM can
    read all guest state (memory and registers) for !SEV guests, i.e. can
    fetch the code stream from memory even if the CPU failed to do so because
    of the SMAP errata.
    
    Fixes: 05d5a4863525 ("KVM: SVM: Workaround errata#1096 (insn_len maybe zero on SMAP violation)")
    Cc: [email protected]
    Cc: Tom Lendacky <[email protected]>
    Cc: Brijesh Singh <[email protected]>
    Signed-off-by: Sean Christopherson <[email protected]>
    Reviewed-by: Liam Merwick <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ce55f63f6cea4cab8ae9212f73285648a5baa30d
Author: Wanpeng Li <[email protected]>
Date:   Tue Jan 25 01:17:00 2022 -0800

    KVM: LAPIC: Also cancel preemption timer during SET_LAPIC
    
    commit 35fe7cfbab2e81f1afb23fc4212210b1de6d9633 upstream.
    
    The below warning is splatting during guest reboot.
    
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
      CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G          I       5.17.0-rc1+ #5
      RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
      Call Trace:
       <TASK>
       kvm_vcpu_ioctl+0x279/0x710 [kvm]
       __x64_sys_ioctl+0x83/0xb0
       do_syscall_64+0x3b/0xc0
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      RIP: 0033:0x7fd39797350b
    
    This can be triggered by not exposing tsc-deadline mode and doing a reboot in
    the guest. The lapic_shutdown() function which is called in sys_reboot path
    will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears
    APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode
    switch between tsc-deadline and oneshot/periodic, which can result in preemption
    timer be cancelled in apic_update_lvtt(). However, We can't depend on this when
    not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption
    timer. Qemu will synchronise states around reset, let's cancel preemption timer
    under KVM_SET_LAPIC.
    
    Signed-off-by: Wanpeng Li <[email protected]>
    Message-Id: <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 456ba2433844a6483cc4c933aa8f43d24575e341
Author: Bas Nieuwenhuizen <[email protected]>
Date:   Mon Jan 24 01:23:36 2022 +0100

    drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU.
    
    commit 25f1488bdbba63415239ff301fe61a8546140d9f upstream.
    
    Mirrors the logic for dcn30. Cue lots of WARNs and some
    kernel panics without this fix.
    
    Cc: [email protected]
    Signed-off-by: Bas Nieuwenhuizen <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 88298b87cb81311cd21304ff3e028f34fcee2b8b
Author: Bas Nieuwenhuizen <[email protected]>
Date:   Mon Jan 24 01:23:35 2022 +0100

    drm/amd/display: Fix FP start/end for dcn30_internal_validate_bw.
    
    commit 72a8d87b87270bff0c0b2fed4d59c48d0dd840d7 upstream.
    
    It calls populate_dml_pipes which uses doubles to initialize the
    scale_ratio_depth params. Mirrors the dcn20 logic.
    
    Cc: [email protected]
    Signed-off-by: Bas Nieuwenhuizen <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ae368125b6acbb1ec67d11b77c43d2c30d661d62
Author: Bas Nieuwenhuizen <[email protected]>
Date:   Sun Jan 23 03:38:28 2022 +0100

    drm/amdgpu/display: Remove t_srx_delay_us.
    
    commit 2a807341ed1074ab83638f2fab08dffaa373f6b8 upstream.
    
    Unused. Convert the divisions into asserts on the divisor, to
    debug why it is zero. The divide by zero is suspected of causing
    kernel panics.
    
    While I have no idea where the zero is coming from I think this
    patch is a positive either way.
    
    Cc: [email protected]
    Reviewed-by: Harry Wentland <[email protected]>
    Signed-off-by: Bas Nieuwenhuizen <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4e6652edcdc82684ccd90699f595d428c1123fc2
Author: Alex Deucher <[email protected]>
Date:   Thu Jan 20 12:17:07 2022 -0500

    drm/amdgpu: filter out radeon secondary ids as well
    
    commit 9e5a14bce2402e84251a10269df0235cd7ce9234 upstream.
    
    Older radeon boards (r2xx-r5xx) had secondary PCI functions
    which we solely there for supporting multi-head on OSs with
    special requirements.  Add them to the unsupported list
    as well so we don't attempt to bind to them.  The driver
    would fail to bind to them anyway, but this does so
    in a cleaner way that should not confuse the user.
    
    Cc: [email protected]
    Acked-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4e3d0e95275b73a139be172c2a157ba4a8411c6e
Author: Manasi Navare <[email protected]>
Date:   Mon Oct 4 04:59:13 2021 -0700

    drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
    
    commit 5ec1cebd59300ddd26dbaa96c17c508764eef911 upstream.
    
    In case of a modeset where a mode gets split across multiple CRTCs
    in the driver specific implementation (bigjoiner in i915) we wrongly count
    the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as
    an affected CRTC in atomic_check_only().
    This triggers a warning since affected CRTCs doent match requested CRTC.
    
    To fix this in such bigjoiner configurations, we should only
    increment affected crtcs if that CRTC is enabled in UAPI not
    if it is just used internally in the driver to split the mode.
    
    v3: Add the same uapi crtc_state->enable check in requested
    crtc calc (Ville)
    
    Cc: Ville Syrjälä <[email protected]>
    Cc: Simon Ser <[email protected]>
    Cc: Pekka Paalanen <[email protected]>
    Cc: Daniel Stone <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Cc: [email protected]
    Cc: <[email protected]> # v5.11+
    Fixes: 919c2299a893 ("drm/i915: Enable bigjoiner")
    Signed-off-by: Manasi Navare <[email protected]>
    Reviewed-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b91c447b68b16e4c1cf263897119021968635391
Author: Lucas Stach <[email protected]>
Date:   Thu Jan 6 19:10:21 2022 +0100

    drm/etnaviv: relax submit size limits
    
    commit e3d26528e083e612314d4dcd713f3d5a26143ddc upstream.
    
    While all userspace tried to limit commandstreams to 64K in size,
    a bug in the Mesa driver lead to command streams of up to 128K
    being submitted. Allow those to avoid breaking existing userspace.
    
    Fixes: 6dfa2fab8ddd ("drm/etnaviv: limit submit sizes")
    Cc: [email protected]
    Signed-off-by: Lucas Stach <[email protected]>
    Reviewed-by: Christian Gmeiner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 722897397121c621e685ad58e20af21d144e1d94
Author: Kan Liang <[email protected]>
Date:   Tue Jan 11 10:20:38 2022 -0800

    perf/x86/intel: Add a quirk for the calculation of the number of counters on Alder Lake
    
    commit 7fa981cad216e9f64f49e22112f610c0bfed91bc upstream.
    
    For some Alder Lake machine with all E-cores disabled in a BIOS, the
    below warning may be triggered.
    
    [ 2.010766] hw perf events fixed 5 > max(4), clipping!
    
    Current perf code relies on the CPUID leaf 0xA and leaf 7.EDX[15] to
    calculate the number of the counters and follow the below assumption.
    
    For a hybrid configuration, the leaf 7.EDX[15] (X86_FEATURE_HYBRID_CPU)
    is set. The leaf 0xA only enumerate the common counters. Linux perf has
    to manually add the extra GP counters and fixed counters for P-cores.
    For a non-hybrid configuration, the X86_FEATURE_HYBRID_CPU should not
    be set. The leaf 0xA enumerates all counters.
    
    However, that's not the case when all E-cores are disabled in a BIOS.
    Although there are only P-cores in the system, the leaf 7.EDX[15]
    (X86_FEATURE_HYBRID_CPU) is still set. But the leaf 0xA is updated
    to enumerate all counters of P-cores. The inconsistency triggers the
    warning.
    
    Several software ways were considered to handle the inconsistency.
    - Drop the leaf 0xA and leaf 7.EDX[15] CPUID enumeration support.
      Hardcode the number of counters. This solution may be a problem for
      virtualization. A hypervisor cannot control the number of counters
      in a Linux guest via changing the guest CPUID enumeration anymore.
    - Find another CPUID bit that is also updated with E-cores disabled.
      There may be a problem in the virtualization environment too. Because
      a hypervisor may disable the feature/CPUID bit.
    - The P-cores have a maximum of 8 GP counters and 4 fixed counters on
      ADL. The maximum number can be used to detect the case.
      This solution is implemented in this patch.
    
    Fixes: ee72a94ea4a6 ("perf/x86/intel: Fix fixed counter check warning for some Alder Lake")
    Reported-by: Damjan Marion (damarion) <[email protected]>
    Reported-by: Chan Edison <[email protected]>
    Signed-off-by: Kan Liang <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Tested-by: Damjan Marion (damarion) <[email protected]>
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 308f30ec092d7a351c770ab33152689342d63835
Author: Zhengjun Xing <[email protected]>
Date:   Thu Dec 23 22:48:26 2021 +0800

    perf/x86/intel/uncore: Fix CAS_COUNT_WRITE issue for ICX
    
    commit 96fd2e89fba1aaada6f4b1e5d25a9d9ecbe1943d upstream.
    
    The user recently report a perf issue in the ICX platform, when test by
    perf event “uncore_imc_x/cas_count_write”,the write bandwidth is always
    very small (only 0.38MB/s), it is caused by the wrong "umask" for the
    "cas_count_write" event. When double-checking, find "cas_count_read"
    also is wrong.
    
    The public document for ICX uncore:
    
    3rd Gen Intel® Xeon® Processor Scalable Family, Codename Ice Lake,Uncore
    Performance Monitoring Reference Manual, Revision 1.00, May 2021
    
    On 2.4.7, it defines Unit Masks for CAS_COUNT:
    RD b00001111
    WR b00110000
    
    So corrected both "cas_count_read" and "cas_count_write" for ICX.
    
    Old settings:
     hswep_uncore_imc_events
            INTEL_UNCORE_EVENT_DESC(cas_count_read,  "event=0x04,umask=0x03")
            INTEL_UNCORE_EVENT_DESC(cas_count_write, "event=0x04,umask=0x0c")
    
    New settings:
     snr_uncore_imc_events
            INTEL_UNCORE_EVENT_DESC(cas_count_read,  "event=0x04,umask=0x0f")
            INTEL_UNCORE_EVENT_DESC(cas_count_write, "event=0x04,umask=0x30")
    
    Fixes: 2b3b76b5ec67 ("perf/x86/intel/uncore: Add Ice Lake server uncore support")
    Signed-off-by: Zhengjun Xing <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Adrian Hunter <[email protected]>
    Reviewed-by: Kan Liang <[email protected]>
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4910080471e9d8a292b20d463896ac670565765b
Author: Christophe Leroy <[email protected]>
Date:   Fri Jan 14 11:26:25 2022 +0000

    powerpc/audit: Fix syscall_get_arch()
    
    commit 252745240ba0ae774d2f80c5e185ed59fbc4fb41 upstream.
    
    Commit 770cec16cdc9 ("powerpc/audit: Simplify syscall_get_arch()")
    and commit 898a1ef06ad4 ("powerpc/audit: Avoid unneccessary #ifdef
    in syscall_get_arguments()")
    replaced test_tsk_thread_flag(task, TIF_32BIT)) by is_32bit_task().
    
    But is_32bit_task() applies on current task while be want the test
    done on task 'task'
    
    So add a new macro is_tsk_32bit_task() to check any task.
    
    Fixes: 770cec16cdc9 ("powerpc/audit: Simplify syscall_get_arch()")
    Fixes: 898a1ef06ad4 ("powerpc/audit: Avoid unneccessary #ifdef in syscall_get_arguments()")
    Cc: [email protected]
    Reported-by: Dmitry V. Levin <[email protected]>
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/c55cddb8f[email protected]csgroup.eu
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 991ced6a3a926e58df1f446819b9f2790e1c0daa
Author: Suren Baghdasaryan <[email protected]>
Date:   Tue Jan 11 15:23:09 2022 -0800

    psi: Fix uaf issue when psi trigger is destroyed while being polled
    
    commit a06247c6804f1a7c86a2e5398a4c1f1db1471848 upstream.
    
    With write operation on psi files replacing old trigger with a new one,
    the lifetime of its waitqueue is totally arbitrary. Overwriting an
    existing trigger causes its waitqueue to be freed and pending poll()
    will stumble on trigger->event_wait which was destroyed.
    Fix this by disallowing to redefine an existing psi trigger. If a write
    operation is used on a file descriptor with an already existing psi
    trigger, the operation will fail with EBUSY error.
    Also bypass a check for psi_disabled in the psi_trigger_destroy as the
    flag can be flipped after the trigger is created, leading to a memory
    leak.
    
    Fixes: 0e94682b73bf ("psi: introduce psi monitor")
    Reported-by: [email protected]
    Suggested-by: Linus Torvalds <[email protected]>
    Analyzed-by: Eric Biggers <[email protected]>
    Signed-off-by: Suren Baghdasaryan <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Eric Biggers <[email protected]>
    Acked-by: Johannes Weiner <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1e28e6c2c3709684178277616bb64f5be1c3ba9a
Author: Sean Christopherson <[email protected]>
Date:   Thu Jan 20 01:07:12 2022 +0000

    Revert "KVM: SVM: avoid infinite loop on NPF from bad address"
    
    commit 31c25585695abdf03d6160aa6d829e855b256329 upstream.
    
    Revert a completely broken check on an "invalid" RIP in SVM's workaround
    for the DecodeAssists SMAP errata.  kvm_vcpu_gfn_to_memslot() obviously
    expects a gfn, i.e. operates in the guest physical address space, whereas
    RIP is a virtual (not even linear) address.  The "fix" worked for the
    problematic KVM selftest because the test identity mapped RIP.
    
    Fully revert the hack instead of trying to translate RIP to a GPA, as the
    non-SEV case is now handled earlier, and KVM cannot access guest page
    tables to translate RIP.
    
    This reverts commit e72436bc3a5206f95bb384e741154166ddb3202e.
    
    Fixes: e72436bc3a52 ("KVM: SVM: avoid infinite loop on NPF from bad address")
    Reported-by: Liam Merwick <[email protected]>
    Cc: [email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Reviewed-by: Liam Merwick <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b15f86c8481996e5fb14b7373341754668e13ac8
Author: Amir Goldstein <[email protected]>
Date:   Thu Jan 20 23:53:05 2022 +0200

    fsnotify: fix fsnotify hooks in pseudo filesystems
    
    commit 29044dae2e746949ad4b9cbdbfb248994d1dcdb4 upstream.
    
    Commit 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of
    d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify
    will have access to a positive dentry.
    
    This allowed a race where opening the deleted file via cached dentry
    is now possible after receiving the IN_DELETE event.
    
    To fix the regression in pseudo filesystems, convert d_delete() calls
    to d_drop() (see commit 46c46f8df9aa ("devpts_pty_kill(): don't bother
    with d_delete()") and move the fsnotify hook after d_drop().
    
    Add a missing fsnotify_unlink() hook in nfsdfs that was found during
    the audit of fsnotify hooks in pseudo filesystems.
    
    Note that the fsnotify hooks in simple_recursive_removal() follow
    d_invalidate(), so they require no change.
    
    Link: https://lore.kernel.org/r/[email protected]
    Reported-by: Ivan Delalande <[email protected]>
    Link: https://lore.kernel.org/linux-fsdevel/[email protected]/
    Fixes: 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()")
    Cc: [email protected] # v5.3+
    Signed-off-by: Amir Goldstein <[email protected]>
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 753a1d633cb0ca3a1a71681421054209918fab54
Author: Amir Goldstein <[email protected]>
Date:   Thu Jan 20 23:53:04 2022 +0200

    fsnotify: invalidate dcache before IN_DELETE event
    
    commit a37d9a17f099072fe4d3a9048b0321978707a918 upstream.
    
    Apparently, there are some applications that use IN_DELETE event as an
    invalidation mechanism and expect that if they try to open a file with
    the name reported with the delete event, that it should not contain the
    content of the deleted file.
    
    Commit 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of
    d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify
    will have access to a positive dentry.
    
    This allowed a race where opening the deleted file via cached dentry
    is now possible after receiving the IN_DELETE event.
    
    To fix the regression, create a new hook fsnotify_delete() that takes
    the unlinked inode as an argument and use a helper d_delete_notify() to
    pin the inode, so we can pass it to fsnotify_delete() after d_delete().
    
    Backporting hint: this regression is from v5.3. Although patch will
    apply with only trivial conflicts to v5.4 and v5.10, it won't build,
    because fsnotify_delete() implementation is different in each of those
    versions (see fsnotify_link()).
    
    A follow up patch will fix the fsnotify_unlink/rmdir() calls in pseudo
    filesystem that do not need to call d_delete().
    
    Link: https://lore.kernel.org/r/[email protected]
    Reported-by: Ivan Delalande <[email protected]>
    Link: https://lore.kernel.org/linux-fsdevel/[email protected]/
    Fixes: 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()")
    Cc: [email protected] # v5.3+
    Signed-off-by: Amir Goldstein <[email protected]>
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1a99fb430ed672668e54875674497af6e38652b9
Author: Jeff Layton <[email protected]>
Date:   Wed Jan 26 12:36:49 2022 -0500

    ceph: set pool_ns in new inode layout for async creates
    
    commit 4584a768f22b7669cdebabc911543621ac661341 upstream.
    
    Dan reported that he was unable to write to files that had been
    asynchronously created when the client's OSD caps are restricted to a
    particular namespace.
    
    The issue is that the layout for the new inode is only partially being
    filled. Ensure that we populate the pool_ns_data and pool_ns_len in the
    iinfo before calling ceph_fill_inode.
    
    Cc: [email protected]
    URL: https://tracker.ceph.com/issues/54013
    Fixes: 9a8d03ca2e2c ("ceph: attempt to do async create when possible")
    Reported-by: Dan van der Ster <[email protected]>
    Signed-off-by: Jeff Layton <[email protected]>
    Reviewed-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a0c22e970cd78b81c94691e6cb09713e8074d580
Author: Jeff Layton <[email protected]>
Date:   Tue Jan 25 15:39:16 2022 -0500

    ceph: properly put ceph_string reference after async create attempt
    
    commit 932a9b5870d38b87ba0a9923c804b1af7d3605b9 upstream.
    
    The reference acquired by try_prep_async_create is currently leaked.
    Ensure we put it.
    
    Cc: [email protected]
    Fixes: 9a8d03ca2e2c ("ceph: attempt to do async create when possible")
    Signed-off-by: Jeff Layton <[email protected]>
    Reviewed-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6dc771e98b79a7ddda3a6266f9f3e05067800096
Author: Tom Zanussi <[email protected]>
Date:   Thu Jan 27 15:44:18 2022 -0600

    tracing: Don't inc err_log entry count if entry allocation fails
    
    commit 67ab5eb71b37b55f7c5522d080a1b42823351776 upstream.
    
    tr->n_err_log_entries should only be increased if entry allocation
    succeeds.
    
    Doing it when it fails won't cause any problems other than wasting an
    entry, but should be fixed anyway.
    
    Link: https://lkml.kernel.org/r/[email protected]kernel.org
    
    Cc: [email protected]
    Fixes: 2f754e771b1a6 ("tracing: Don't inc err_log entry count if entry allocation fails")
    Signed-off-by: Tom Zanussi <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 71443fe2ac1561d4f575412241c914d92c3b7c2b
Author: Tom Zanussi <[email protected]>
Date:   Thu Jan 27 15:44:17 2022 -0600

    tracing: Propagate is_signed to expression
    
    commit 097f1eefedeab528cecbd35586dfe293853ffb17 upstream.
    
    During expression parsing, a new expression field is created which
    should inherit the properties of the operands, such as size and
    is_signed.
    
    is_signed propagation was missing, causing spurious errors with signed
    operands.  Add it in parse_expr() and parse_unary() to fix the problem.
    
    Link: https://lkml.kernel.org/r/[email protected]kernel.org
    
    Cc: [email protected]
    Fixes: 100719dcef447 ("tracing: Add simple expression support to hist triggers")
    Reported-by: Yordan Karadzhov <[email protected]>
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215513
    Signed-off-by: Tom Zanussi <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit df86e2fe808c3536a9dba353cc2bebdfea00d0cf
Author: Xiaoke Wang <[email protected]>
Date:   Tue Jan 25 12:07:15 2022 +0800

    tracing/histogram: Fix a potential memory leak for kstrdup()
    
    commit e629e7b525a179e29d53463d992bdee759c950fb upstream.
    
    kfree() is missing on an error path to free the memory allocated by
    kstrdup():
    
      p = param = kstrdup(data->params[i], GFP_KERNEL);
    
    So it is better to free it via kfree(p).
    
    Link: https://lkml.kernel.org/r/[email protected]
    
    Cc: [email protected]
    Fixes: d380dcde9a07c ("tracing: Fix now invalid var_ref_vals assumption in trace action")
    Signed-off-by: Xiaoke Wang <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1ef81cd002079443dae37060d1d5867077db1dca
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Jan 13 19:44:20 2022 +0100

    PM: wakeup: simplify the output logic of pm_show_wakelocks()
    
    commit c9d967b2ce40d71e968eb839f36c936b8a9cf1ea upstream.
    
    The buffer handling in pm_show_wakelocks() is tricky, and hopefully
    correct.  Ensure it really is correct by using sysfs_emit_at() which
    handles all of the tricky string handling logic in a PAGE_SIZE buffer
    for us automatically as this is a sysfs file being read from.
    
    Reviewed-by: Lee Jones <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a4085859411c825c321c9b55b8a9dc5a128a6684
Author: Ard Biesheuvel <[email protected]>
Date:   Wed Jan 12 11:14:13 2022 +0100

    efi: runtime: avoid EFIv2 runtime services on Apple x86 machines
    
    commit f5390cd0b43c2e54c7cf5506c7da4a37c5cef746 upstream.
    
    Aditya reports [0] that his recent MacbookPro crashes in the firmware
    when using the variable services at runtime. The culprit appears to be a
    call to QueryVariableInfo(), which we did not use to call on Apple x86
    machines in the past as they only upgraded from EFI v1.10 to EFI v2.40
    firmware fairly recently, and QueryVariableInfo() (along with
    UpdateCapsule() et al) was added in EFI v2.00.
    
    The only runtime service introduced in EFI v2.00 that we actually use in
    Linux is QueryVariableInfo(), as the capsule based ones are optional,
    generally not used at runtime (all the LVFS/fwupd firmware update
    infrastructure uses helper EFI programs that invoke capsule update at
    boot time, not runtime), and not implemented by Apple machines in the
    first place. QueryVariableInfo() is used to 'safely' set variables,
    i.e., only when there is enough space. This prevents machines with buggy
    firmwares from corrupting their NVRAMs when they run out of space.
    
    Given that Apple machines have been using EFI v1.10 services only for
    the longest time (the EFI v2.0 spec was released in 2006, and Linux
    support for the newly introduced runtime services was added in 2011, but
    the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only),
    let's avoid the EFI v2.0 ones on all Apple x86 machines.
    
    [0] https://lore.kernel.org/all/[email protected]/
    
    Cc: <[email protected]>
    Cc: Jeremy Kerr <[email protected]>
    Cc: Matthew Garrett <[email protected]>
    Reported-by: Aditya Garg <[email protected]>
    Tested-by: Orlando Chamberlain <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Tested-by: Aditya Garg <[email protected]>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215277
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 620e8243cf5389e706c1c8f66ffacb3c84308a9e
Author: Jan Kara <[email protected]>
Date:   Mon Jan 17 18:22:13 2022 +0100

    udf: Fix NULL ptr deref when converting from inline format
    
    commit 7fc3b7c2981bbd1047916ade327beccb90994eee upstream.
    
    udf_expand_file_adinicb() calls directly ->writepage to write data
    expanded into a page. This however misses to setup inode for writeback
    properly and so we can crash on inode->i_wb dereference when submitting
    page for IO like:
    
      BUG: kernel NULL pointer dereference, address: 0000000000000158
      #PF: supervisor read access in kernel mode
    ...
      <TASK>
      __folio_start_writeback+0x2ac/0x350
      __block_write_full_page+0x37d/0x490
      udf_expand_file_adinicb+0x255/0x400 [udf]
      udf_file_write_iter+0xbe/0x1b0 [udf]
      new_sync_write+0x125/0x1c0
      vfs_write+0x28e/0x400
    
    Fix the problem by marking the page dirty and going through the standard
    writeback path to write the page. Strictly speaking we would not even
    have to write the page but we want to catch e.g. ENOSPC errors early.
    
    Reported-by: butt3rflyh4ck <[email protected]>
    CC: [email protected]
    Fixes: 52ebea749aae ("writeback: make backing_dev_info host cgroup-specific bdi_writebacks")
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8baf0dbef73e1d1ad41f5db77bf20234fb7a7773
Author: Jan Kara <[email protected]>
Date:   Tue Jan 18 09:57:25 2022 +0100

    udf: Restore i_lenAlloc when inode expansion fails
    
    commit ea8569194b43f0f01f0a84c689388542c7254a1f upstream.
    
    When we fail to expand inode from inline format to a normal format, we
    restore inode to contain the original inline formatting but we forgot to
    set i_lenAlloc back. The mismatch between i_lenAlloc and i_size was then
    causing further problems such as warnings and lost data down the line.
    
    Reported-by: butt3rflyh4ck <[email protected]>
    CC: [email protected]
    Fixes: 7e49b6f2480c ("udf: Convert UDF to new truncate calling sequence")
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit aa2b81857b6fcfd4662acd16f6f5777088058ad7
Author: Steffen Maier <[email protected]>
Date:   Tue Jan 18 17:58:03 2022 +0100

    scsi: zfcp: Fix failed recovery on gone remote port with non-NPIV FCP devices
    
    commit 8c9db6679be4348b8aae108e11d4be2f83976e30 upstream.
    
    Suppose we have an environment with a number of non-NPIV FCP devices
    (virtual HBAs / FCP devices / zfcp "adapter"s) sharing the same physical
    FCP channel (HBA port) and its I_T nexus. Plus a number of storage target
    ports zoned to such shared channel. Now one target port logs out of the
    fabric causing an RSCN. Zfcp reacts with an ADISC ELS and subsequent port
    recovery depending on the ADISC result. This happens on all such FCP
    devices (in different Linux images) concurrently as they all receive a copy
    of this RSCN. In the following we look at one of those FCP devices.
    
    Requests other than FSF_QTCB_FCP_CMND can be slow until they get a
    response.
    
    Depending on which requests are affected by slow responses, there are
    different recovery outcomes. Here we want to fix failed recoveries on port
    or adapter level by avoiding recovery requests that can be slow.
    
    We need the cached N_Port_ID for the remote port "link" test with ADISC.
    Just before sending the ADISC, we now intentionally forget the old cached
    N_Port_ID. The idea is that on receiving an RSCN for a port, we have to
    assume that any cached information about this port is stale.  This forces a
    fresh new GID_PN [FC-GS] nameserver lookup on any subsequent recovery for
    the same port. Since we typically can still communicate with the nameserver
    efficiently, we now reach steady state quicker: Either the nameserver still
    does not know about the port so we stop recovery, or the nameserver already
    knows the port potentially with a new N_Port_ID and we can successfully and
    quickly perform open port recovery.  For the one case, where ADISC returns
    successfully, we re-initialize port->d_id because that case does not
    involve any port recovery.
    
    This also solves a problem if the storage WWPN quickly logs into the fabric
    again but with a different N_Port_ID. Such as on virtual WWPN takeover
    during target NPIV failover.
    [https://www.redbooks.ibm.com/abstracts/redp5477.html] In that case the
    RSCN from the storage FDISC was ignored by zfcp and we could not
    successfully recover the failover. On some later failback on the storage,
    we could have been lucky if the virtual WWPN got the same old N_Port_ID
    from the SAN switch as we still had cached.  Then the related RSCN
    triggered a successful port reopen recovery.  However, there is no
    guarantee to get the same N_Port_ID on NPIV FDISC.
    
    Even though NPIV-enabled FCP devices are not affected by this problem, this
    code change optimizes recovery time for gone remote ports as a side effect.
    The timely drop of cached N_Port_IDs prevents unnecessary slow open port
    attempts.
    
    While the problem might have been in code before v2.6.32 commit
    799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp") this fix
    depends on the gid_pn_work introduced with that commit, so we mark it as
    culprit to satisfy fix dependencies.
    
    Note: Point-to-point remote port is already handled separately and gets its
    N_Port_ID from the cached peer_d_id. So resetting port->d_id in general
    does not affect PtP.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp")
    Cc: <[email protected]> #2.6.32+
    Suggested-by: Benjamin Block <[email protected]>
    Reviewed-by: Benjamin Block <[email protected]>
    Signed-off-by: Steffen Maier <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit aec8904396dc6c34a104f42b02d50ca9de58ab13
Author: Eric W. Biederman <[email protected]>
Date:   Mon Jan 24 12:46:50 2022 -0600

    ucount: Make get_ucount a safe get_user replacement
    
    commit f9d87929d451d3e649699d0f1d74f71f77ad38f5 upstream.
    
    When the ucount code was refactored to create get_ucount it was missed
    that some of the contexts in which a rlimit is kept elevated can be
    the only reference to the user/ucount in the system.
    
    Ordinary ucount references exist in places that also have a reference
    to the user namspace, but in POSIX message queues, the SysV shm code,
    and the SIGPENDING code there is no independent user namespace
    reference.
    
    Inspection of the the user_namespace show no instance of circular
    references between struct ucounts and the user_namespace.  So
    hold a reference from struct ucount to i's user_namespace to
    resolve this problem.
    
    Link: https://lore.kernel.org/lkml/[email protected]/
    Reported-by: Qian Cai <[email protected]>
    Reported-by: Mathias Krause <[email protected]>
    Tested-by: Mathias Krause <[email protected]>
    Reviewed-by: Mathias Krause <[email protected]>
    Reviewed-by: Alexey Gladkov <[email protected]>
    Fixes: d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts")
    Fixes: 6e52a9f0532f ("Reimplement RLIMIT_MSGQUEUE on top of ucounts")
    Fixes: d7c9e99aee48 ("Reimplement RLIMIT_MEMLOCK on top of ucounts")
    Cc: [email protected]
    Signed-off-by: "Eric W. Biederman" <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f96590a8fb0455c690517190b69703f9332dee17
Author: Naveen N. Rao <[email protected]>
Date:   Thu Jan 6 17:15:07 2022 +0530

    powerpc/bpf: Update ldimm64 instructions during extra pass
    
    commit f9320c49993ca3c0ec0f9a7026b313735306bb8b upstream.
    
    These instructions are updated after the initial JIT, so redo codegen
    during the extra pass. Rename bpf_jit_fixup_subprog_calls() to clarify
    that this is more than just subprog calls.
    
    Fixes: 69c087ba6225b5 ("bpf: Add bpf_for_each_map_elem() helper")
    Cc: [email protected] # v5.15
    Signed-off-by: Naveen N. Rao <[email protected]>
    Tested-by: Jiri Olsa <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/7cc16[email protected]linux.vnet.ibm.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 80e6e5ca97adf383d35a66379f42673b85a722b1
Author: Naveen N. Rao <[email protected]>
Date:   Thu Jan 6 17:15:06 2022 +0530

    powerpc32/bpf: Fix codegen for bpf-to-bpf calls
    
    commit fab07611fb2e6a15fac05c4583045ca5582fd826 upstream.
    
    Pad instructions emitted for BPF_CALL so that the number of instructions
    generated does not change for different function addresses. This is
    especially important for calls to other bpf functions, whose address
    will only be known during extra pass.
    
    Fixes: 51c66ad849a703 ("powerpc/bpf: Implement extended BPF on PPC32")
    Cc: [email protected] # v5.13+
    Signed-off-by: Naveen N. Rao <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/52d8f[email protected]linux.vnet.ibm.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b82ef4985a6d05e80f604624332430351df7b79a
Author: Naveen N. Rao <[email protected]>
Date:   Thu Jan 6 17:15:05 2022 +0530

    bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack()
    
    commit b992f01e66150fc5e90be4a96f5eb8e634c8249e upstream.
    
    task_pt_regs() can return NULL on powerpc for kernel threads. This is
    then used in __bpf_get_stack() to check for user mode, resulting in a
    kernel oops. Guard against this by checking return value of
    task_pt_regs() before trying to obtain the call chain.
    
    Fixes: fa28dcb82a38f8 ("bpf: Introduce helper bpf_get_task_stack()")
    Cc: [email protected] # v5.9+
    Signed-off-by: Naveen N. Rao <[email protected]>
    Acked-by: Daniel Borkmann <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/d5ef8[email protected]linux.vnet.ibm.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 25d3459948f60720209038a24778e9ac3a997623
Author: Christian Borntraeger <[email protected]>
Date:   Mon Jan 17 18:40:32 2022 +0100

    s390/nmi: handle vector validity failures for KVM guests
    
    commit f094a39c6ba168f2df1edfd1731cca377af5f442 upstream.
    
    The machine check validity bit tells about the context. If a KVM guest
    was running the bit tells about the guest validity and the host state is
    not affected. As a guest can disable the guest validity this might
    result in unwanted host errors on machine checks.
    
    Cc: [email protected]
    Fixes: c929500d7a5a ("s390/nmi: s390: New low level handling for machine check happening in guest")
    Signed-off-by: Christian Borntraeger <[email protected]>
    Reviewed-by: Heiko Carstens <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6820a30bd7d9e204255c8515fffc708c1d97e1ec
Author: Christian Borntraeger <[email protected]>
Date:   Thu Jan 13 11:44:19 2022 +0100

    s390/nmi: handle guarded storage validity failures for KVM guests
    
    commit 1ea1d6a847d2b1d17fefd9196664b95f052a0775 upstream.
    
    machine check validity bits reflect the state of the machine check. If a
    guest does not make use of guarded storage, the validity bit might be
    off. We can not use the host CR bit to decide if the validity bit must
    be on. So ignore "invalid" guarded storage controls for KVM guests in
    the host and rely on the machine check being forwarded to the guest.  If
    no other errors happen from a host perspective everything is fine and no
    process must be killed and the host can continue to run.
    
    Cc: [email protected]
    Fixes: c929500d7a5a ("s390/nmi: s390: New low level handling for machine check happening in guest")
    Reported-by: Carsten Otte <[email protected]>
    Signed-off-by: Christian Borntraeger <[email protected]>
    Tested-by: Carsten Otte <[email protected]>
    Reviewed-by: Heiko Carstens <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 62c368d137f97adc94c812b16b0c42373e7d34c7
Author: Vasily Gorbik <[email protected]>
Date:   Thu Jan 20 16:23:19 2022 +0100

    s390/hypfs: include z/VM guests with access control group set
    
    commit 663d34c8df98740f1e90241e78e456d00b3c6cad upstream.
    
    Currently if z/VM guest is allowed to retrieve hypervisor performance
    data globally for all guests (privilege class B) the query is formed in a
    way to include all guests but the group name is left empty. This leads to
    that z/VM guests which have access control group set not being included
    in the results (even local vm).
    
    Change the query group identifier from empty to "any" to retrieve
    information about all guests from any groups (or without a group set).
    
    Cc: [email protected]
    Fixes: 31cb4bd31a48 ("[S390] Hypervisor filesystem (s390_hypfs) for z/VM")
    Reviewed-by: Gerald Schaefer <[email protected]>
    Signed-off-by: Vasily Gorbik <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 529afef7357a5021c0ee7c0c4c417217b6adfc5e
Author: Ilya Leoshkevich <[email protected]>
Date:   Wed Jan 19 19:26:37 2022 +0100

    s390/module: fix loading modules with a lot of relocations
    
    commit f3b7e73b2c6619884351a3a0a7468642f852b8a2 upstream.
    
    If the size of the PLT entries generated by apply_rela() exceeds
    64KiB, the first ones can no longer reach __jump_r1 with brc. Fix by
    using brcl. An alternative solution is to add a __jump_r1 copy after
    every 64KiB, however, the space savings are quite small and do not
    justify the additional complexity.
    
    Fixes: f19fbd5ed642 ("s390: introduce execute-trampolines for branches")
    Cc: [email protected]
    Reported-by: Andrea Righi <[email protected]>
    Signed-off-by: Ilya Leoshkevich <[email protected]nux.ibm.com>
    Reviewed-by: Heiko Carstens <[email protected]>
    Cc: Vasily Gorbik <[email protected]>
    Cc: Christian Borntraeger <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6ef3c08edf062e8f7270c381308793c413a70c78
Author: Marc Zyngier <[email protected]>
Date:   Fri Jan 21 21:07:47 2022 +0000

    KVM: arm64: vgic-v3: Restrict SEIS workaround to known broken systems
    
    commit d11a327ed95dbec756b99cbfef2a7fd85c9eeb09 upstream.
    
    Contrary to what df652bcf1136 ("KVM: arm64: vgic-v3: Work around GICv3
    locally generated SErrors") was asserting, there is at least one other
    system out there (Cavium ThunderX2) implementing SEIS, and not in
    an obviously broken way.
    
    So instead of imposing the M1 workaround on an innocent bystander,
    let's limit it to the two known broken Apple implementations.
    
    Fixes: df652bcf1136 ("KVM: arm64: vgic-v3: Work around GICv3 locally generated SErrors")
    Reported-by: Ard Biesheuvel <[email protected]>
    Tested-by: Ard Biesheuvel <[email protected]>
    Acked-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4b7740ab9fe97867201ea3a5850104402c0cb0bf
Author: Marc Zyngier <[email protected]>
Date:   Fri Jan 21 18:42:07 2022 +0000

    KVM: arm64: Use shadow SPSR_EL1 when injecting exceptions on !VHE
    
    commit 278583055a237270fac70518275ba877bf9e4013 upstream.
    
    Injecting an exception into a guest with non-VHE is risky business.
    Instead of writing in the shadow register for the switch code to
    restore it, we override the CPU register instead. Which gets
    overriden a few instructions later by said restore code.
    
    The result is that although the guest correctly gets the exception,
    it will return to the original context in some random state,
    depending on what was there the first place... Boo.
    
    Fix the issue by writing to the shadow register. The original code
    is absolutely fine on VHE, as the state is already loaded, and writing
    to the shadow register in that case would actually be a bug.
    
    Fixes: bb666c472ca2 ("KVM: arm64: Inject AArch64 exceptions from HYP")
    Cc: [email protected]
    Signed-off-by: Marc Zyngier <[email protected]>
    Reviewed-by: Fuad Tabba <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7bb2b4df4cf9273b135f9a4b9e332bb4dbfecdcf
Author: Ard Biesheuvel <[email protected]>
Date:   Tue Jan 18 19:32:17 2022 +0100

    ARM: 9180/1: Thumb2: align ALT_UP() sections in modules sufficiently
    
    commit 9f80ccda53b9417236945bc7ece4b519037df74d upstream.
    
    When building for Thumb2, the .alt.smp.init sections that are emitted by
    the ALT_UP() patching code may not be 32-bit aligned, even though the
    fixup_smp_on_up() routine expects that. This results in alignment faults
    at module load time, which need to be fixed up by the fault handler.
    
    So let's align those sections explicitly, and prevent this from occurring.
    
    Cc: <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9d4190234e48dc1a764f85c95b381336ece7038c
Author: Ard Biesheuvel <[email protected]>
Date:   Tue Jan 18 13:45:09 2022 +0100

    ARM: 9179/1: uaccess: avoid alignment faults in copy_[from|to]_kernel_nofault
    
    commit 15420269b02a63ed8c1841905d8b8b2403246004 upstream.
    
    The helpers that are used to implement copy_from_kernel_nofault() and
    copy_to_kernel_nofault() cast a void* to a pointer to a wider type,
    which may result in alignment faults on ARM if the compiler decides to
    use double-word or multiple-word load/store instructions.
    
    Only configurations that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
    are affected, given that commit 2423de2e6f4d ("ARM: 9115/1: mm/maccess:
    fix unaligned copy_{from,to}_kernel_nofault") ensures that dst and src
    are sufficiently aligned otherwise.
    
    So use the unaligned accessors for accessing dst and src in cases where
    they may be misaligned.
    
    Cc: <[email protected]> # depends on 2423de2e6f4d
    Fixes: 2df4c9a741a0 ("ARM: 9112/1: uaccess: add __{get,put}_kernel_nofault")
    Reviewed-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2d9ccdb92d29851d20cac76ddf51e5d9e7d9478c
Author: Mohammad Athari Bin Ismail <[email protected]>
Date:   Wed Jan 26 17:47:23 2022 +0800

    net: stmmac: skip only stmmac_ptp_register when resume from suspend
    
    commit 0735e639f129dff455aeb91da291f5c578cc33db upstream.
    
    When resume from suspend, besides skipping PTP registration, it also
    skipping PTP HW initialization. This could cause PTP clock not able to
    operate properly when resume from suspend.
    
    To fix this, only stmmac_ptp_register() is skipped when resume from
    suspend.
    
    Fixes: fe1319291150 ("stmmac: Don't init ptp again when resume from suspend/hibernation")
    Cc: <[email protected]> # 5.15.x
    Signed-off-by: Mohammad Athari Bin Ismail <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 99ecb18ce2e0b563dac567212c87bf9c6d3d43c3
Author: Mohammad Athari Bin Ismail <[email protected]>
Date:   Wed Jan 26 17:47:22 2022 +0800

    net: stmmac: configure PTP clock source prior to PTP initialization
    
    commit 94c82de43e01ef5747a95e4a590880de863fe423 upstream.
    
    For Intel platform, it is required to configure PTP clock source prior PTP
    initialization in MAC. So, need to move ptp_clk_freq_config execution from
    stmmac_ptp_register() to stmmac_init_ptp().
    
    Fixes: 76da35dc99af ("stmmac: intel: Add PSE and PCH PTP clock source selection")
    Cc: <[email protected]> # 5.15.x
    Signed-off-by: Mohammad Athari Bin Ismail <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f4d8610a92d6dc9f12cdbb34f2f28f33093a0c27
Author: Marek Behún <[email protected]>
Date:   Wed Jan 19 17:44:55 2022 +0100

    net: sfp: ignore disabled SFP node
    
    commit 2148927e6ed43a1667baf7c2ae3e0e05a44b51a0 upstream.
    
    Commit ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices
    and sfp cages") added code which finds SFP bus DT node even if the node
    is disabled with status = "disabled". Because of this, when phylink is
    created, it ends with non-null .sfp_bus member, even though the SFP
    module is not probed (because the node is disabled).
    
    We need to ignore disabled SFP bus node.
    
    Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages")
    Signed-off-by: Marek Behún <[email protected]>
    Cc: [email protected] # 2203cbf2c8b5 ("net: sfp: move fwnode parsing into sfp-bus layer")
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6f75f8ecd51f22e4505ace721373d473022a4c5b
Author: Marc Kleine-Budde <[email protected]>
Date:   Fri Jan 14 15:35:01 2022 +0100

    can: m_can: m_can_fifo_{read,write}: don't read or write from/to FIFO if length is 0
    
    commit db72589c49fd260bfc99c7160c079675bc7417af upstream.
    
    In order to optimize FIFO access, especially on m_can cores attached
    to slow busses like SPI, in patch
    
    | e39381770ec9 ("can: m_can: Disable IRQs on FIFO bus errors")
    
    bulk read/write support has been added to the m_can_fifo_{read,write}
    functions.
    
    That change leads to the tcan driver to call
    regmap_bulk_{read,write}() with a length of 0 (for CAN frames with 0
    data length). regmap treats this as an error:
    
    | tcan4x5x spi1.0 tcan4x5x0: FIFO write returned -22
    
    This patch fixes the problem by not calling the
    cdev->ops->{read,write)_fifo() in case of a 0 length read/write.
    
    Fixes: e39381770ec9 ("can: m_can: Disable IRQs on FIFO bus errors")
    Link: https://lore.kernel.org/all/[email protected]
    Cc: [email protected]
    Cc: Matt Kline <[email protected]>
    Cc: Chandrasekar Ramakrishnan <[email protected]>
    Reported-by: Michael Anochin <[email protected]>
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7a8b052a254b5334a3845ea7db0f22576503787d
Author: Filipe Manana <[email protected]>
Date:   Thu Jan 20 17:41:17 2022 +0000

    btrfs: update writeback index when starting defrag
    
    commit 27cdfde181bcacd226c230b2fd831f6f5b8c215f upstream.
    
    When starting a defrag, we should update the writeback index of the
    inode's mapping in case it currently has a value beyond the start of the
    range we are defragging. This can help performance and often result in
    getting less extents after writeback - for e.g., if the current value
    of the writeback index sits somewhere in the middle of a range that
    gets dirty by the defrag, then after writeback we can get two smaller
    extents instead of a single, larger extent.
    
    We used to have this before the refactoring in 5.16, but it was removed
    without any reason to do so. Originally it was added in kernel 3.1, by
    commit 2a0f7f5769992b ("Btrfs: fix recursive auto-defrag"), in order to
    fix a loop with autodefrag resulting in dirtying and writing pages over
    and over, but some testing on current code did not show that happening,
    at least with the test described in that commit.
    
    So add back the behaviour, as at the very least it is a nice to have
    optimization.
    
    Fixes: 7b508037d4cac3 ("btrfs: defrag: use defrag_one_cluster() to implement btrfs_defrag_file()")
    CC: [email protected] # 5.16
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 895da68803b87347a0dec6710f932fa7bd1210ca
Author: Filipe Manana <[email protected]>
Date:   Thu Jan 20 17:11:52 2022 +0000

    btrfs: add back missing dirty page rate limiting to defrag
    
    commit 3c9d31c715948aaff0ee6d322a91a2dec07770bf upstream.
    
    A defrag operation can dirty a lot of pages, specially if operating on
    the entire file or a large file range. Any task dirtying pages should
    periodically call balance_dirty_pages_ratelimited(), as stated in that
    function's comments, otherwise they can leave too many dirty pages in
    the system. This is what we did before the refactoring in 5.16, and
    it should have remained, just like in the buffered write path and
    relocation. So restore that behaviour.
    
    Fixes: 7b508037d4cac3 ("btrfs: defrag: use defrag_one_cluster() to implement btrfs_defrag_file()")
    CC: [email protected] # 5.16
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f56722d60db0661defd2d6fc83a559ee340f3084
Author: Filipe Manana <[email protected]>
Date:   Thu Jan 20 14:27:56 2022 +0000

    btrfs: fix deadlock when reserving space during defrag
    
    commit 0cb5950f3f3b51a4e8657d106f897f2b913e0586 upstream.
    
    When defragging we can end up collecting a range for defrag that has
    already pages under delalloc (dirty), as long as the respective extent
    map for their range is not mapped to a hole, a prealloc extent or
    the extent map is from an old generation.
    
    Most of the time that is harmless from a functional perspective at
    least, however it can result in a deadlock:
    
    1) At defrag_collect_targets() we find an extent map that meets all
       requirements but there's delalloc for the range it covers, and we add
       its range to list of ranges to defrag;
    
    2) The defrag_collect_targets() function is called at defrag_one_range(),
       after it locked a range that overlaps the range of the extent map;
    
    3) At defrag_one_range(), while the range is still locked, we call
       defrag_one_locked_target() for the range associated to the extent
       map we collected at step 1);
    
    4) Then finally at defrag_one_locked_target() we do a call to
       btrfs_delalloc_reserve_space(), which will reserve data and metadata
       space. If the space reservations can not be satisfied right away, the
       flusher might be kicked in and start flushing delalloc and wait for
       the respective ordered extents to complete. If this happens we will
       deadlock, because both flushing delalloc and finishing an ordered
       extent, requires locking the range in the inode's io tree, which was
       already locked at defrag_collect_targets().
    
    So fix this by skipping extent maps for which there's already delalloc.
    
    Fixes: eb793cf857828d ("btrfs: defrag: introduce helper to collect target file extents")
    CC: [email protected] # 5.16
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6f32d917ee16fb597597df0c3f5beb015999738c
Author: Qu Wenruo <[email protected]>
Date:   Tue Jan 18 19:53:52 2022 +0800

    btrfs: defrag: properly update range->start for autodefrag
    
    commit c080b4144b9dd3b7af838a194ffad3204ca15166 upstream.
    
    [BUG]
    After commit 7b508037d4ca ("btrfs: defrag: use defrag_one_cluster() to
    implement btrfs_defrag_file()") autodefrag no longer properly re-defrag
    the file from previously finished location.
    
    [CAUSE]
    The recent refactoring of defrag only focuses on defrag ioctl subpage
    support, doesn't take autodefrag into consideration.
    
    There are two problems involved which prevents autodefrag to restart its
    scan:
    
    - No range.start update
      Previously when one defrag target is found, range->start will be
      updated to indicate where next search should start from.
    
      But now btrfs_defrag_file() doesn't update it anymore, making all
      autodefrag to rescan from file offset 0.
    
      This would also make autodefrag to mark the same range dirty again and
      again, causing extra IO.
    
    - No proper quick exit for defrag_one_cluster()
      Currently if we reached or exceed @max_sectors limit, we just exit
      defrag_one_cluster(), and let next defrag_one_cluster() call to do a
      quick exit.
      This makes @cur increase, thus no way to properly know which range is
      defragged and which range is skipped.
    
    [FIX]
    The fix involves two modifications:
    
    - Update range->start to next cluster start
      This is a little different from the old behavior.
      Previously range->start is updated to the next defrag target.
    
      But in the end, the behavior should still be pretty much the same,
      as now we skip to next defrag target inside btrfs_defrag_file().
    
      Thus if auto-defrag determines to re-scan, then we still do the skip,
      just at a different timing.
    
    - Make defrag_one_cluster() to return >0 to indicate a quick exit
      So that btrfs_defrag_file() can also do a quick exit, without
      increasing @cur to the range end, and re-use @cur to update
      @range->start.
    
    - Add comment for btrfs_defrag_file() to mention the range->start update
      Currently only autodefrag utilize this behavior, as defrag ioctl won't
      set @max_to_defrag parameter, thus unless interrupted it will always
      try to defrag the whole range.
    
    Reported-by: Filipe Manana <[email protected]>
    Fixes: 7b508037d4ca ("btrfs: defrag: use defrag_one_cluster() to implement btrfs_defrag_file()")
    Link: https://lore.kernel.org/linux-btrfs/[email protected]/
    CC: [email protected] # 5.16
    Reviewed-by: Filipe Manana <[email protected]>
    Signed-off-by: Qu Wenruo <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8923f11810889165717501813dc54fb7b3e2dcae
Author: Qu Wenruo <[email protected]>
Date:   Tue Jan 18 15:19:04 2022 +0800

    btrfs: defrag: fix wrong number of defragged sectors
    
    commit 484167da77739a8d0e225008c48e697fd3f781ae upstream.
    
    [BUG]
    There are users using autodefrag mount option reporting obvious increase
    in IO:
    
    > If I compare the write average (in total, I don't have it per process)
    > when taking idle periods on the same machine:
    >     Linux 5.16:
    >         without autodefrag: ~ 10KiB/s
    >         with autodefrag: between 1 and 2MiB/s.
    >
    >     Linux 5.15:
    >         with autodefrag:~ 10KiB/s (around the same as without
    > autodefrag on 5.16)
    
    [CAUSE]
    When autodefrag mount option is enabled, btrfs_defrag_file() will be
    called with @max_sectors = BTRFS_DEFRAG_BATCH (1024) to limit how many
    sectors we can defrag in one try.
    
    And then use the number of sectors defragged to determine if we need to
    re-defrag.
    
    But commit b18c3ab2343d ("btrfs: defrag: introduce helper to defrag one
    cluster") uses wrong unit to increase @sectors_defragged, which should
    be in unit of sector, not byte.
    
    This means, if we have defragged any sector, then @sectors_defragged
    will be >= sectorsize (normally 4096), which is larger than
    BTRFS_DEFRAG_BATCH.
    
    This makes the @max_sectors check in defrag_one_cluster() to underflow,
    rendering the whole @max_sectors check useless.
    
    Thus causing way more IO for autodefrag mount options, as now there is
    no limit on how many sectors can really be defragged.
    
    [FIX]
    Fix the problems by:
    
    - Use sector as unit when increasing @sectors_defragged
    
    - Include @sectors_defragged > @max_sectors case to break the loop
    
    - Add extra comment on the return value of btrfs_defrag_file()
    
    Reported-by: Anthony Ruhier <[email protected]>
    Fixes: b18c3ab2343d ("btrfs: defrag: introduce helper to defrag one cluster")
    Link: https://lore.kernel.org/linux-btrfs/[email protected]/
    CC: [email protected] # 5.16
    Reviewed-by: Filipe Manana <[email protected]>
    Signed-off-by: Qu Wenruo <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1ad0917c8cde6bddc0d3289762350ea4feeaf228
Author: Filipe Manana <[email protected]>
Date:   Tue Jan 18 13:43:31 2022 +0000

    btrfs: allow defrag to be interruptible
    
    commit b767c2fc787e992daeadfff40d61c05f66c82da0 upstream.
    
    During defrag, at btrfs_defrag_file(), we have this loop that iterates
    over a file range in steps no larger than 256K subranges. If the range
    is too long, there's no way to interrupt it. So make the loop check in
    each iteration if there's signal pending, and if there is, break and
    return -AGAIN to userspace.
    
    Before kernel 5.16, we used to allow defrag to be cancelled through a
    signal, but that was lost with commit 7b508037d4cac3 ("btrfs: defrag:
    use defrag_one_cluster() to implement btrfs_defrag_file()").
    
    This change adds back the possibility to cancel a defrag with a signal
    and keeps the same semantics, returning -EAGAIN to user space (and not
    the usually more expected -EINTR).
    
    This is also motivated by a recent bug on 5.16 where defragging a 1 byte
    file resulted in iterating from file range 0 to (u64)-1, as hitting the
    bug triggered a too long loop, basically requiring one to reboot the
    machine, as it was not possible to cancel defrag.
    
    Fixes: 7b508037d4cac3 ("btrfs: defrag: use defrag_one_cluster() to implement btrfs_defrag_file()")
    CC: [email protected] # 5.16
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bac3babdabdc53f8f47b513cff805b3b98c467bb
Author: Filipe Manana <[email protected]>
Date:   Mon Jan 17 16:28:29 2022 +0000

    btrfs: fix too long loop when defragging a 1 byte file
    
    commit 6b34cd8e175bfbf4f3f01b6d19eae18245e1a8cc upstream.
    
    When attempting to defrag a file with a single byte, we can end up in a
    too long loop, which is nearly infinite because at btrfs_defrag_file()
    we end up with the variable last_byte assigned with a value of
    18446744073709551615 (which is (u64)-1). The problem comes from the fact
    we end up doing:
    
        last_byte = round_up(last_byte, fs_info->sectorsize) - 1;
    
    So if last_byte was assigned 0, which is i_size - 1, we underflow and
    end up with the value 18446744073709551615.
    
    This is trivial to reproduce and the following script triggers it:
    
      $ cat test.sh
      #!/bin/bash
    
      DEV=/dev/sdj
      MNT=/mnt/sdj
    
      mkfs.btrfs -f $DEV
      mount $DEV $MNT
    
      echo -n "X" > $MNT/foobar
    
      btrfs filesystem defragment $MNT/foobar
    
      umount $MNT
    
    So fix this by not decrementing last_byte by 1 before doing the sector
    size round up. Also, to make it easier to follow, make the round up right
    after computing last_byte.
    
    Reported-by: Anthony Ruhier <[email protected]>
    Fixes: 7b508037d4cac3 ("btrfs: defrag: use defrag_one_cluster() to implement btrfs_defrag_file()")
    Link: https://lore.kernel.org/linux-btrfs/[email protected]/
    CC: [email protected] # 5.16
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5c968affa804ba98c3c603f37ffea6fba618025e
Author: Brian Gix <[email protected]>
Date:   Wed Nov 24 12:16:28 2021 -0800

    Bluetooth: refactor malicious adv data check
    
    commit 899663be5e75dc0174dc8bda0b5e6826edf0b29a upstream.
    
    Check for out-of-bound read was being performed at the end of while
    num_reports loop, and would fill journal with false positives. Added
    check to beginning of loop processing so that it doesn't get checked
    after ptr has been advanced.
    
    Signed-off-by: Brian Gix <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>
    Cc: syphyr <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
© CVE.report 2022 Twitter Nitter Twitter Viewer |

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

CVE.report and Source URL Uptime Status status.cve.report