commit 9a2dc0e6c531d595bcdf2c66d0be131679bd02df
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jun 10 13:24:09 2021 +0200

    Linux 4.19.194
    
    Link: https://lore.kernel.org/r/20210608175932.263480586@linuxfoundation.org
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20210609062858.532803536@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Jason Self <jason@bluehome.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed6a024f4888df6fa2b8a3e92dea5f6a63649b84
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue May 18 18:13:42 2021 +0200

    xen-pciback: redo VF placement in the virtual topology
    
    The commit referenced below was incomplete: It merely affected what
    would get written to the vdev-<N> xenstore node. The guest would still
    find the function at the original function number as long as
    __xen_pcibk_get_pci_dev() wouldn't be in sync. The same goes for AER wrt
    __xen_pcibk_get_pcifront_dev().
    
    Undo overriding the function to zero and instead make sure that VFs at
    function zero remain alone in their slot. This has the added benefit of
    improving overall capacity, considering that there's only a total of 32
    slots available right now (PCI segment and bus can both only ever be
    zero at present).
    
    This is upstream commit 4ba50e7c423c29639878c00573288869aa627068.
    
    Fixes: 8a5248fe10b1 ("xen PV passthru: assign SR-IOV virtual functions to
    separate virtual slots")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Link: https://lore.kernel.org/r/8def783b-404c-3452-196d-3f3fd4d72c9e@suse.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5cd7f229609cf328664aedb056a6fd744e0068b
Author: Cheng Jian <cj.chengjian@huawei.com>
Date:   Fri Dec 13 10:45:30 2019 +0800

    sched/fair: Optimize select_idle_cpu
    
    commit 60588bfa223ff675b95f866249f90616613fbe31 upstream.
    
    select_idle_cpu() will scan the LLC domain for idle CPUs,
    it's always expensive. so the next commit :
    
            1ad3aaf3fcd2 ("sched/core: Implement new approach to scale select_idle_cpu()")
    
    introduces a way to limit how many CPUs we scan.
    
    But it consume some CPUs out of 'nr' that are not allowed
    for the task and thus waste our attempts. The function
    always return nr_cpumask_bits, and we can't find a CPU
    which our task is allowed to run.
    
    Cpumask may be too big, similar to select_idle_core(), use
    per_cpu_ptr 'select_idle_mask' to prevent stack overflow.
    
    Fixes: 1ad3aaf3fcd2 ("sched/core: Implement new approach to scale select_idle_cpu()")
    Signed-off-by: Cheng Jian <cj.chengjian@huawei.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
    Link: https://lkml.kernel.org/r/20191213024530.28052-1-cj.chengjian@huawei.com
    Signed-off-by: Yang Wei <yang.wei@linux.alibaba.com>
    Tested-by: Yang Wei <yang.wei@linux.alibaba.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f47c2c06982efbeb8f3aaa418fca1e3cf3b9792c
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Jan 9 00:34:37 2019 +0100

    ACPI: EC: Look for ECDT EC after calling acpi_load_tables()
    
    commit b1c0330823fe842dbb34641f1410f0afa51c29d3 upstream.
    
    Some systems have had functional issues since commit 5a8361f7ecce
    (ACPICA: Integrate package handling with module-level code) that,
    among other things, changed the initial values of the
    acpi_gbl_group_module_level_code and acpi_gbl_parse_table_as_term_list
    global flags in ACPICA which implicitly caused acpi_ec_ecdt_probe() to
    be called before acpi_load_tables() on the vast majority of platforms.
    
    Namely, before commit 5a8361f7ecce, acpi_load_tables() was called from
    acpi_early_init() if acpi_gbl_parse_table_as_term_list was FALSE and
    acpi_gbl_group_module_level_code was TRUE, which almost always was
    the case as FALSE and TRUE were their initial values, respectively.
    The acpi_gbl_parse_table_as_term_list value would be changed to TRUE
    for a couple of platforms in acpi_quirks_dmi_table[], but it remained
    FALSE in the vast majority of cases.
    
    After commit 5a8361f7ecce, the initial values of the two flags have
    been reversed, so in effect acpi_load_tables() has not been called
    from acpi_early_init() any more.  That, in turn, affects
    acpi_ec_ecdt_probe() which is invoked before acpi_load_tables() now
    and it is not possible to evaluate the _REG method for the EC address
    space handler installed by it.  That effectively causes the EC address
    space to be inaccessible to AML on platforms with an ECDT matching the
    EC device definition in the DSDT and functional problems ensue in
    there.
    
    Because the default behavior before commit 5a8361f7ecce was to call
    acpi_ec_ecdt_probe() after acpi_load_tables(), it should be safe to
    do that again.  Moreover, the EC address space handler installed by
    acpi_ec_ecdt_probe() is only needed for AML to be able to access the
    EC address space and the only AML that can run during acpi_load_tables()
    is module-level code which only is allowed to access address spaces
    with default handlers (memory, I/O and PCI config space).
    
    For this reason, move the acpi_ec_ecdt_probe() invocation back to
    acpi_bus_init(), from where it was taken away by commit d737f333b211
    (ACPI: probe ECDT before loading AML tables regardless of module-level
    code flag), and put it after the invocation of acpi_load_tables() to
    restore the original code ordering from before commit 5a8361f7ecce.
    
    Fixes: 5a8361f7ecce ("ACPICA: Integrate package handling with module-level code")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199981
    Reported-by: step-ali <sunmooon15@gmail.com>
    Reported-by: Charles Stanhope <charles.stanhope@gmail.com>
    Tested-by: Charles Stanhope <charles.stanhope@gmail.com>
    Reported-by: Paulo Nascimento <paulo.ulusu@googlemail.com>
    Reported-by: David Purton <dcpurton@marshwiggle.net>
    Reported-by: Adam Harvey <adam@adamharvey.name>
    Reported-by: Zhang Rui <rui.zhang@intel.com>
    Tested-by: Zhang Rui <rui.zhang@intel.com>
    Tested-by: Jean-Marc Lenoir <archlinux@jihemel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Laurențiu Păncescu <lpancescu@gmail.com>
    Cc: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eeb48f5ca3ab66d793a911917712929875385059
Author: Erik Kaneda <erik.kaneda@intel.com>
Date:   Wed Oct 17 15:41:21 2018 -0700

    ACPI: probe ECDT before loading AML tables regardless of module-level code flag
    
    commit d737f333b211361b6e239fc753b84c3be2634aaa upstream.
    
    It was discovered that AML tables were loaded before or after the
    ECDT depending on acpi_gbl_execute_tables_as_methods. According to
    the ACPI spec, the ECDT should be loaded before the namespace is
    populated by loading AML tables (DSDT and SSDT). Since the ECDT
    should be loaded early in the boot process, this change moves the
    ECDT probing to acpi_early_init.
    
    Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Laurențiu Păncescu <lpancescu@gmail.com>
    Cc: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ca5f9f13a3ec1f4cb75a6383a1294e384667ece
Author: Marc Zyngier <maz@kernel.org>
Date:   Fri May 14 09:05:41 2021 +0100

    KVM: arm64: Fix debug register indexing
    
    commit cb853ded1d25e5b026ce115dbcde69e3d7e2e831 upstream.
    
    Commit 03fdfb2690099 ("KVM: arm64: Don't write junk to sysregs on
    reset") flipped the register number to 0 for all the debug registers
    in the sysreg table, hereby indicating that these registers live
    in a separate shadow structure.
    
    However, the author of this patch failed to realise that all the
    accessors are using that particular index instead of the register
    encoding, resulting in all the registers hitting index 0. Not quite
    a valid implementation of the architecture...
    
    Address the issue by fixing all the accessors to use the CRm field
    of the encoding, which contains the debug register index.
    
    Fixes: 03fdfb2690099 ("KVM: arm64: Don't write junk to sysregs on reset")
    Reported-by: Ricardo Koller <ricarkol@google.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 982903d43ecb2a3b2550af0560c0c66482a6d99f
Author: Sean Christopherson <seanjc@google.com>
Date:   Wed Apr 21 19:21:22 2021 -0700

    KVM: SVM: Truncate GPR value for DR and CR accesses in !64-bit mode
    
    commit 0884335a2e653b8a045083aa1d57ce74269ac81d upstream.
    
    Drop bits 63:32 on loads/stores to/from DRs and CRs when the vCPU is not
    in 64-bit mode.  The APM states bits 63:32 are dropped for both DRs and
    CRs:
    
      In 64-bit mode, the operand size is fixed at 64 bits without the need
      for a REX prefix. In non-64-bit mode, the operand size is fixed at 32
      bits and the upper 32 bits of the destination are forced to 0.
    
    Fixes: 7ff76d58a9dc ("KVM: SVM: enhance MOV CR intercept handler")
    Fixes: cae3797a4639 ("KVM: SVM: enhance mov DR intercept handler")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210422022128.3464144-4-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [sudip: manual backport to old file]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b678e02e63e27885b750ab8ccf7c280e34530a0
Author: Anand Jain <anand.jain@oracle.com>
Date:   Fri Apr 30 19:59:51 2021 +0800

    btrfs: fix unmountable seed device after fstrim
    
    commit 5e753a817b2d5991dfe8a801b7b1e8e79a1c5a20 upstream.
    
    The following test case reproduces an issue of wrongly freeing in-use
    blocks on the readonly seed device when fstrim is called on the rw sprout
    device. As shown below.
    
    Create a seed device and add a sprout device to it:
    
      $ mkfs.btrfs -fq -dsingle -msingle /dev/loop0
      $ btrfstune -S 1 /dev/loop0
      $ mount /dev/loop0 /btrfs
      $ btrfs dev add -f /dev/loop1 /btrfs
      BTRFS info (device loop0): relocating block group 290455552 flags system
      BTRFS info (device loop0): relocating block group 1048576 flags system
      BTRFS info (device loop0): disk added /dev/loop1
      $ umount /btrfs
    
    Mount the sprout device and run fstrim:
    
      $ mount /dev/loop1 /btrfs
      $ fstrim /btrfs
      $ umount /btrfs
    
    Now try to mount the seed device, and it fails:
    
      $ mount /dev/loop0 /btrfs
      mount: /btrfs: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
    
    Block 5292032 is missing on the readonly seed device:
    
     $ dmesg -kt | tail
     <snip>
     BTRFS error (device loop0): bad tree block start, want 5292032 have 0
     BTRFS warning (device loop0): couldn't read-tree root
     BTRFS error (device loop0): open_ctree failed
    
    >From the dump-tree of the seed device (taken before the fstrim). Block
    5292032 belonged to the block group starting at 5242880:
    
      $ btrfs inspect dump-tree -e /dev/loop0 | grep -A1 BLOCK_GROUP
      <snip>
      item 3 key (5242880 BLOCK_GROUP_ITEM 8388608) itemoff 16169 itemsize 24
            block group used 114688 chunk_objectid 256 flags METADATA
      <snip>
    
    >From the dump-tree of the sprout device (taken before the fstrim).
    fstrim used block-group 5242880 to find the related free space to free:
    
      $ btrfs inspect dump-tree -e /dev/loop1 | grep -A1 BLOCK_GROUP
      <snip>
      item 1 key (5242880 BLOCK_GROUP_ITEM 8388608) itemoff 16226 itemsize 24
            block group used 32768 chunk_objectid 256 flags METADATA
      <snip>
    
    BPF kernel tracing the fstrim command finds the missing block 5292032
    within the range of the discarded blocks as below:
    
      kprobe:btrfs_discard_extent {
            printf("freeing start %llu end %llu num_bytes %llu:\n",
                    arg1, arg1+arg2, arg2);
      }
    
      freeing start 5259264 end 5406720 num_bytes 147456
      <snip>
    
    Fix this by avoiding the discard command to the readonly seed device.
    
    Reported-by: Chris Murphy <lists@colorremedies.com>
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c31789645b7bdcf6f55969974d55336831652055
Author: Song Liu <songliubraving@fb.com>
Date:   Tue Oct 8 09:59:49 2019 -0700

    perf/core: Fix corner case in perf_rotate_context()
    
    commit 7fa343b7fdc4f351de4e3f28d5c285937dd1f42f upstream.
    
    In perf_rotate_context(), when the first cpu flexible event fail to
    schedule, cpu_rotate is 1, while cpu_event is NULL. Since cpu_event is
    NULL, perf_rotate_context will _NOT_ call cpu_ctx_sched_out(), thus
    cpuctx->ctx.is_active will have EVENT_FLEXIBLE set. Then, the next
    perf_event_sched_in() will skip all cpu flexible events because of the
    EVENT_FLEXIBLE bit.
    
    In the next call of perf_rotate_context(), cpu_rotate stays 1, and
    cpu_event stays NULL, so this process repeats. The end result is, flexible
    events on this cpu will not be scheduled (until another event being added
    to the cpuctx).
    
    Here is an easy repro of this issue. On Intel CPUs, where ref-cycles
    could only use one counter, run one pinned event for ref-cycles, one
    flexible event for ref-cycles, and one flexible event for cycles. The
    flexible ref-cycles is never scheduled, which is expected. However,
    because of this issue, the cycles event is never scheduled either.
    
     $ perf stat -e ref-cycles:D,ref-cycles,cycles -C 5 -I 1000
    
               time             counts unit events
        1.000152973         15,412,480      ref-cycles:D
        1.000152973      <not counted>      ref-cycles     (0.00%)
        1.000152973      <not counted>      cycles         (0.00%)
        2.000486957         18,263,120      ref-cycles:D
        2.000486957      <not counted>      ref-cycles     (0.00%)
        2.000486957      <not counted>      cycles         (0.00%)
    
    To fix this, when the flexible_active list is empty, try rotate the
    first event in the flexible_groups. Also, rename ctx_first_active() to
    ctx_event_to_rotate(), which is more accurate.
    
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: <kernel-team@fb.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sasha Levin <sashal@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: 8d5bce0c37fa ("perf/core: Optimize perf_rotate_context() event scheduling")
    Link: https://lkml.kernel.org/r/20191008165949.920548-1-songliubraving@fb.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b4c9255a1d0d08fa8a2d8bc97302756d0e9e98d
Author: Ian Rogers <irogers@google.com>
Date:   Sat Jun 1 01:27:22 2019 -0700

    perf/cgroups: Don't rotate events for cgroups unnecessarily
    
    commit fd7d55172d1e2e501e6da0a5c1de25f06612dc2e upstream.
    
    Currently perf_rotate_context assumes that if the context's nr_events !=
    nr_active a rotation is necessary for perf event multiplexing. With
    cgroups, nr_events is the total count of events for all cgroups and
    nr_active will not include events in a cgroup other than the current
    task's. This makes rotation appear necessary for cgroups when it is not.
    
    Add a perf_event_context flag that is set when rotation is necessary.
    Clear the flag during sched_out and set it when a flexible sched_in
    fails due to resources.
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Link: https://lkml.kernel.org/r/20190601082722.44543-1-irogers@google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c35461390b486a1f34340e969d333b04a348e599
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Mon Jan 27 04:56:15 2020 -0500

    bnxt_en: Remove the setting of dev_port.
    
    commit 1d86859fdf31a0d50cc82b5d0d6bfb5fe98f6c00 upstream.
    
    The dev_port is meant to distinguish the network ports belonging to
    the same PCI function.  Our devices only have one network port
    associated with each PCI function and so we should not set it for
    correctness.
    
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d80154040c27c5363d04404dcf46d738919f575
Author: Björn Töpel <bjorn@kernel.org>
Date:   Wed Jun 2 11:27:53 2021 +0800

    selftests/bpf: Avoid running unprivileged tests with alignment requirements
    
    commit c77b0589ca29ad1859fe7d7c1ecd63c0632379fa upstream
    
    Some architectures have strict alignment requirements. In that case,
    the BPF verifier detects if a program has unaligned accesses and
    rejects them. A user can pass BPF_F_ANY_ALIGNMENT to a program to
    override this check. That, however, will only work when a privileged
    user loads a program. An unprivileged user loading a program with this
    flag will be rejected prior entering the verifier.
    
    Hence, it does not make sense to load unprivileged programs without
    strict alignment when testing the verifier. This patch avoids exactly
    that.
    
    Signed-off-by: Björn Töpel <bjorn.topel@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Luke Nelson <luke.r.nels@gmail.com>
    Link: https://lore.kernel.org/bpf/20201118071640.83773-3-bjorn.topel@gmail.com
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c4acb93972e9de3c3dfaa60a532a7fa529ac708
Author: Björn Töpel <bjorn@kernel.org>
Date:   Wed Jun 2 11:27:52 2021 +0800

    selftests/bpf: add "any alignment" annotation for some tests
    
    commit e2c6f50e48849298bed694de03cceb537d95cdc4 upstream
    
    RISC-V does, in-general, not have "efficient unaligned access". When
    testing the RISC-V BPF JIT, some selftests failed in the verification
    due to misaligned access. Annotate these tests with the
    F_NEEDS_EFFICIENT_UNALIGNED_ACCESS flag.
    
    Signed-off-by: Björn Töpel <bjorn.topel@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3789f9c3a4f55dff424424fd93c5aad829647dce
Author: David S. Miller <davem@davemloft.net>
Date:   Wed Jun 2 11:27:51 2021 +0800

    bpf: Apply F_NEEDS_EFFICIENT_UNALIGNED_ACCESS to more ACCEPT test cases.
    
    commit 0a68632488aa0129ed530af9ae9e8573f5650812 upstream
    
    If a testcase has alignment problems but is expected to be ACCEPT,
    verify it using F_NEEDS_EFFICIENT_UNALIGNED_ACCESS too.
    
    Maybe in the future if we add some architecture specific code to elide
    the unaligned memory access warnings during the test, we can execute
    these as well.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f22c1cd341cd91296967f143cd7b2068779751a2
Author: David S. Miller <davem@davemloft.net>
Date:   Wed Jun 2 11:27:50 2021 +0800

    bpf: Make more use of 'any' alignment in test_verifier.c
    
    commit 2acc5fd5b8c25df0de7f3c8b8e385f5c6f8202ec upstream
    
    Use F_NEEDS_EFFICIENT_UNALIGNED_ACCESS in more tests where the
    expected result is REJECT.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e7ee04b035a268716c98a1ee22634419f30d25d
Author: David S. Miller <davem@davemloft.net>
Date:   Wed Jun 2 11:27:49 2021 +0800

    bpf: Adjust F_NEEDS_EFFICIENT_UNALIGNED_ACCESS handling in test_verifier.c
    
    commit c7665702d3208b77b8e00f0699b6b88241b04360 upstream
    
    Make it set the flag argument to bpf_verify_program() which will relax
    the alignment restrictions.
    
    Now all such test cases will go properly through the verifier even on
    inefficient unaligned access architectures.
    
    On inefficient unaligned access architectures do not try to run such
    programs, instead mark the test case as passing but annotate the
    result similarly to how it is done now in the presence of this flag.
    
    So, we get complete full coverage for all REJECT test cases, and at
    least verifier level coverage for ACCEPT test cases.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 878470e7f5edb0f8d78f863d25d65e460da3593f
Author: David S. Miller <davem@davemloft.net>
Date:   Wed Jun 2 11:27:48 2021 +0800

    bpf: Add BPF_F_ANY_ALIGNMENT.
    
    commit e9ee9efc0d176512cdce9d27ff8549d7ffa2bfcd upstream
    
    Often we want to write tests cases that check things like bad context
    offset accesses.  And one way to do this is to use an odd offset on,
    for example, a 32-bit load.
    
    This unfortunately triggers the alignment checks first on platforms
    that do not set CONFIG_EFFICIENT_UNALIGNED_ACCESS.  So the test
    case see the alignment failure rather than what it was testing for.
    
    It is often not completely possible to respect the original intention
    of the test, or even test the same exact thing, while solving the
    alignment issue.
    
    Another option could have been to check the alignment after the
    context and other validations are performed by the verifier, but
    that is a non-trivial change to the verifier.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6c9e3b46c3a4c78799ac550176856e7ff5e313c
Author: Joe Stringer <joe@wand.net.nz>
Date:   Wed Jun 2 11:27:47 2021 +0800

    selftests/bpf: Generalize dummy program types
    
    commit 0c586079f852187d19fea60c9a4981ad29e22ba8 upstream
    
    Don't hardcode the dummy program types to SOCKET_FILTER type, as this
    prevents testing bpf_tail_call in conjunction with other program types.
    Instead, use the program type specified in the test case.
    
    Signed-off-by: Joe Stringer <joe@wand.net.nz>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac0985c8a2d8f829e7f6dfcdd543f32dd29747b7
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Wed Jun 2 11:27:46 2021 +0800

    bpf: test make sure to run unpriv test cases in test_verifier
    
    commit 832c6f2c29ec519b766923937f4f93fb1008b47d upstream
    
    Right now unprivileged tests are never executed as a BPF test run,
    only loaded. Allow for running them as well so that we can check
    the outcome and probe for regressions.
    
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b5c4b0669e0a63c9e5345c42ff6329a9001c207
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Wed Jun 2 11:27:45 2021 +0800

    bpf: fix test suite to enable all unpriv program types
    
    commit 36641ad61db5ce9befd5eb0071abb36eaff16cfc upstream
    
    Given BPF_PROG_TYPE_CGROUP_SKB program types are also valid in an
    unprivileged setting, lets not omit these tests and potentially
    have issues fall through the cracks. Make this more obvious by
    adding a small test_as_unpriv() helper.
    
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7de60c2d5a2a66ef2c5d76952a5a3a9a4ea4d436
Author: Mina Almasry <almasrymina@google.com>
Date:   Fri Jun 4 20:01:36 2021 -0700

    mm, hugetlb: fix simple resv_huge_pages underflow on UFFDIO_COPY
    
    [ Upstream commit d84cf06e3dd8c5c5b547b5d8931015fc536678e5 ]
    
    The userfaultfd hugetlb tests cause a resv_huge_pages underflow.  This
    happens when hugetlb_mcopy_atomic_pte() is called with !is_continue on
    an index for which we already have a page in the cache.  When this
    happens, we allocate a second page, double consuming the reservation,
    and then fail to insert the page into the cache and return -EEXIST.
    
    To fix this, we first check if there is a page in the cache which
    already consumed the reservation, and return -EEXIST immediately if so.
    
    There is still a rare condition where we fail to copy the page contents
    AND race with a call for hugetlb_no_page() for this index and again we
    will underflow resv_huge_pages.  That is fixed in a more complicated
    patch not targeted for -stable.
    
    Test:
    
      Hacked the code locally such that resv_huge_pages underflows produce a
      warning, then:
    
      ./tools/testing/selftests/vm/userfaultfd hugetlb_shared 10
            2 /tmp/kokonut_test/huge/userfaultfd_test && echo test success
      ./tools/testing/selftests/vm/userfaultfd hugetlb 10
            2 /tmp/kokonut_test/huge/userfaultfd_test && echo test success
    
    Both tests succeed and produce no warnings.  After the test runs number
    of free/resv hugepages is correct.
    
    [mike.kravetz@oracle.com: changelog fixes]
    
    Link: https://lkml.kernel.org/r/20210528004649.85298-1-almasrymina@google.com
    Fixes: 8fb5debc5fcd ("userfaultfd: hugetlbfs: add hugetlb_mcopy_atomic_pte for userfaultfd support")
    Signed-off-by: Mina Almasry <almasrymina@google.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Axel Rasmussen <axelrasmussen@google.com>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5cfa81562174e585ecc40bf8766835abd058572
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed May 19 13:13:15 2021 -0400

    btrfs: fixup error handling in fixup_inode_link_counts
    
    commit 011b28acf940eb61c000059dd9e2cfcbf52ed96b upstream.
    
    This function has the following pattern
    
            while (1) {
                    ret = whatever();
                    if (ret)
                            goto out;
            }
            ret = 0
    out:
            return ret;
    
    However several places in this while loop we simply break; when there's
    a problem, thus clearing the return value, and in one case we do a
    return -EIO, and leak the memory for the path.
    
    Fix this by re-arranging the loop to deal with ret == 1 coming from
    btrfs_search_slot, and then simply delete the
    
            ret = 0;
    out:
    
    bit so everybody can break if there is an error, which will allow for
    proper error handling to occur.
    
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit adaafc32d8b0d896c71348775eee3d0fbe743052
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed May 19 10:52:46 2021 -0400

    btrfs: return errors from btrfs_del_csums in cleanup_ref_head
    
    commit 856bd270dc4db209c779ce1e9555c7641ffbc88e upstream.
    
    We are unconditionally returning 0 in cleanup_ref_head, despite the fact
    that btrfs_del_csums could fail.  We need to return the error so the
    transaction gets aborted properly, fix this by returning ret from
    btrfs_del_csums in cleanup_ref_head.
    
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    CC: stable@vger.kernel.org # 4.19+
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8299bb94fae9393c922251ff90508f0a8b058ff4
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed May 19 10:52:45 2021 -0400

    btrfs: fix error handling in btrfs_del_csums
    
    commit b86652be7c83f70bf406bed18ecf55adb9bfb91b upstream.
    
    Error injection stress would sometimes fail with checksums on disk that
    did not have a corresponding extent.  This occurred because the pattern
    in btrfs_del_csums was
    
            while (1) {
                    ret = btrfs_search_slot();
                    if (ret < 0)
                            break;
            }
            ret = 0;
    out:
            btrfs_free_path(path);
            return ret;
    
    If we got an error from btrfs_search_slot we'd clear the error because
    we were breaking instead of goto out.  Instead of using goto out, simply
    handle the cases where we may leave a random value in ret, and get rid
    of the
    
            ret = 0;
    out:
    
    pattern and simply allow break to have the proper error reporting.  With
    this fix we properly abort the transaction and do not commit thinking we
    successfully deleted the csum.
    
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 543a6f5284b4cc0591e5497d1912300378043561
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed May 19 09:38:27 2021 -0400

    btrfs: mark ordered extent and inode with error if we fail to finish
    
    commit d61bec08b904cf171835db98168f82bc338e92e4 upstream.
    
    While doing error injection testing I saw that sometimes we'd get an
    abort that wouldn't stop the current transaction commit from completing.
    This abort was coming from finish ordered IO, but at this point in the
    transaction commit we should have gotten an error and stopped.
    
    It turns out the abort came from finish ordered io while trying to write
    out the free space cache.  It occurred to me that any failure inside of
    finish_ordered_io isn't actually raised to the person doing the writing,
    so we could have any number of failures in this path and think the
    ordered extent completed successfully and the inode was fine.
    
    Fix this by marking the ordered extent with BTRFS_ORDERED_IOERR, and
    marking the mapping of the inode with mapping_set_error, so any callers
    that simply call fdatawait will also get the error.
    
    With this we're seeing the IO error on the free space inode when we fail
    to do the finish_ordered_io.
    
    CC: stable@vger.kernel.org # 4.19+
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e25cb1b22f81239ae3332e14a1d0cff7014bccd
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue May 25 13:08:41 2021 +0200

    x86/apic: Mark _all_ legacy interrupts when IO/APIC is missing
    
    commit 7d65f9e80646c595e8c853640a9d0768a33e204c upstream.
    
    PIC interrupts do not support affinity setting and they can end up on
    any online CPU. Therefore, it's required to mark the associated vectors
    as system-wide reserved. Otherwise, the corresponding irq descriptors
    are copied to the secondary CPUs but the vectors are not marked as
    assigned or reserved. This works correctly for the IO/APIC case.
    
    When the IO/APIC is disabled via config, kernel command line or lack of
    enumeration then all legacy interrupts are routed through the PIC, but
    nothing marks them as system-wide reserved vectors.
    
    As a consequence, a subsequent allocation on a secondary CPU can result in
    allocating one of these vectors, which triggers the BUG() in
    apic_update_vector() because the interrupt descriptor slot is not empty.
    
    Imran tried to work around that by marking those interrupts as allocated
    when a CPU comes online. But that's wrong in case that the IO/APIC is
    available and one of the legacy interrupts, e.g. IRQ0, has been switched to
    PIC mode because then marking them as allocated will fail as they are
    already marked as system vectors.
    
    Stay consistent and update the legacy vectors after attempting IO/APIC
    initialization and mark them as system vectors in case that no IO/APIC is
    available.
    
    Fixes: 69cde0004a4b ("x86/vector: Use matrix allocator for vector assignment")
    Reported-by: Imran Khan <imran.f.khan@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20210519233928.2157496-1-imran.f.khan@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93e4ac2a9979a9a4ecc158409ed9c3044dc0ae1f
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Mon May 31 09:21:38 2021 +0200

    nfc: fix NULL ptr dereference in llcp_sock_getname() after failed connect
    
    commit 4ac06a1e013cf5fdd963317ffd3b968560f33bba upstream.
    
    It's possible to trigger NULL pointer dereference by local unprivileged
    user, when calling getsockname() after failed bind() (e.g. the bind
    fails because LLCP_SAP_MAX used as SAP):
    
      BUG: kernel NULL pointer dereference, address: 0000000000000000
      CPU: 1 PID: 426 Comm: llcp_sock_getna Not tainted 5.13.0-rc2-next-20210521+ #9
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1 04/01/2014
      Call Trace:
       llcp_sock_getname+0xb1/0xe0
       __sys_getpeername+0x95/0xc0
       ? lockdep_hardirqs_on_prepare+0xd5/0x180
       ? syscall_enter_from_user_mode+0x1c/0x40
       __x64_sys_getpeername+0x11/0x20
       do_syscall_64+0x36/0x70
       entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    This can be reproduced with Syzkaller C repro (bind followed by
    getpeername):
    https://syzkaller.appspot.com/x/repro.c?x=14def446e00000
    
    Cc: <stable@vger.kernel.org>
    Fixes: d646960f7986 ("NFC: Initial LLCP support")
    Reported-by: syzbot+80fb126e7f7d8b1a5914@syzkaller.appspotmail.com
    Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Link: https://lore.kernel.org/r/20210531072138.5219-1-krzysztof.kozlowski@canonical.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cec4e857ffaa8c447f51cd8ab4e72350077b6770
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Fri Jun 4 20:01:42 2021 -0700

    ocfs2: fix data corruption by fallocate
    
    commit 6bba4471f0cc1296fe3c2089b9e52442d3074b2e upstream.
    
    When fallocate punches holes out of inode size, if original isize is in
    the middle of last cluster, then the part from isize to the end of the
    cluster will be zeroed with buffer write, at that time isize is not yet
    updated to match the new size, if writeback is kicked in, it will invoke
    ocfs2_writepage()->block_write_full_page() where the pages out of inode
    size will be dropped.  That will cause file corruption.  Fix this by
    zero out eof blocks when extending the inode size.
    
    Running the following command with qemu-image 4.2.1 can get a corrupted
    coverted image file easily.
    
        qemu-img convert -p -t none -T none -f qcow2 $qcow_image \
                 -O qcow2 -o compat=1.1 $qcow_image.conv
    
    The usage of fallocate in qemu is like this, it first punches holes out
    of inode size, then extend the inode size.
    
        fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0
        fallocate(11, 0, 2276196352, 65536) = 0
    
    v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html
    v2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/
    
    Link: https://lkml.kernel.org/r/20210528210648.9124-1-junxiao.bi@oracle.com
    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d106f05432e60f9f62d456ef017687f5c73cb414
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Fri Jun 4 20:01:14 2021 -0700

    pid: take a reference when initializing `cad_pid`
    
    commit 0711f0d7050b9e07c44bc159bbc64ac0a1022c7f upstream.
    
    During boot, kernel_init_freeable() initializes `cad_pid` to the init
    task's struct pid.  Later on, we may change `cad_pid` via a sysctl, and
    when this happens proc_do_cad_pid() will increment the refcount on the
    new pid via get_pid(), and will decrement the refcount on the old pid
    via put_pid().  As we never called get_pid() when we initialized
    `cad_pid`, we decrement a reference we never incremented, can therefore
    free the init task's struct pid early.  As there can be dangling
    references to the struct pid, we can later encounter a use-after-free
    (e.g.  when delivering signals).
    
    This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to
    have been around since the conversion of `cad_pid` to struct pid in
    commit 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") from the
    pre-KASAN stone age of v2.6.19.
    
    Fix this by getting a reference to the init task's struct pid when we
    assign it to `cad_pid`.
    
    Full KASAN splat below.
    
       ==================================================================
       BUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline]
       BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509
       Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273
    
       CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1
       Hardware name: linux,dummy-virt (DT)
       Call trace:
        ns_of_pid include/linux/pid.h:153 [inline]
        task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509
        do_notify_parent+0x308/0xe60 kernel/signal.c:1950
        exit_notify kernel/exit.c:682 [inline]
        do_exit+0x2334/0x2bd0 kernel/exit.c:845
        do_group_exit+0x108/0x2c8 kernel/exit.c:922
        get_signal+0x4e4/0x2a88 kernel/signal.c:2781
        do_signal arch/arm64/kernel/signal.c:882 [inline]
        do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936
        work_pending+0xc/0x2dc
    
       Allocated by task 0:
        slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516
        slab_alloc_node mm/slub.c:2907 [inline]
        slab_alloc mm/slub.c:2915 [inline]
        kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920
        alloc_pid+0xdc/0xc00 kernel/pid.c:180
        copy_process+0x2794/0x5e18 kernel/fork.c:2129
        kernel_clone+0x194/0x13c8 kernel/fork.c:2500
        kernel_thread+0xd4/0x110 kernel/fork.c:2552
        rest_init+0x44/0x4a0 init/main.c:687
        arch_call_rest_init+0x1c/0x28
        start_kernel+0x520/0x554 init/main.c:1064
        0x0
    
       Freed by task 270:
        slab_free_hook mm/slub.c:1562 [inline]
        slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600
        slab_free mm/slub.c:3161 [inline]
        kmem_cache_free+0x224/0x8e0 mm/slub.c:3177
        put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114
        put_pid+0x30/0x48 kernel/pid.c:109
        proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401
        proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591
        proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617
        call_write_iter include/linux/fs.h:1977 [inline]
        new_sync_write+0x3ac/0x510 fs/read_write.c:518
        vfs_write fs/read_write.c:605 [inline]
        vfs_write+0x9c4/0x1018 fs/read_write.c:585
        ksys_write+0x124/0x240 fs/read_write.c:658
        __do_sys_write fs/read_write.c:670 [inline]
        __se_sys_write fs/read_write.c:667 [inline]
        __arm64_sys_write+0x78/0xb0 fs/read_write.c:667
        __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
        invoke_syscall arch/arm64/kernel/syscall.c:49 [inline]
        el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129
        do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168
        el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416
        el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432
        el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701
    
       The buggy address belongs to the object at ffff23794dda0000
        which belongs to the cache pid of size 224
       The buggy address is located 4 bytes inside of
        224-byte region [ffff23794dda0000, ffff23794dda00e0)
       The buggy address belongs to the page:
       page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4dda0
       head:(____ptrval____) order:1 compound_mapcount:0
       flags: 0x3fffc0000010200(slab|head)
       raw: 03fffc0000010200 dead000000000100 dead000000000122 ffff23794d40d080
       raw: 0000000000000000 0000000000190019 00000001ffffffff 0000000000000000
       page dumped because: kasan: bad access detected
    
       Memory state around the buggy address:
        ffff23794dd9ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffff23794dd9ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       >ffff23794dda0000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                          ^
        ffff23794dda0080: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
        ffff23794dda0100: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
       ==================================================================
    
    Link: https://lkml.kernel.org/r/20210524172230.38715-1-mark.rutland@arm.com
    Fixes: 9ec52099e4b8678a ("[PATCH] replace cad_pid by a struct pid")
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
    Cc: Cedric Le Goater <clg@fr.ibm.com>
    Cc: Christian Brauner <christian@brauner.io>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Kees Cook <keescook@chromium.org
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2132a28807cf8eda722f96628b3ab7709a236bb8
Author: Phil Elwell <phil@raspberrypi.com>
Date:   Tue Jun 8 13:00:49 2021 +0100

    usb: dwc2: Fix build in periphal-only mode
    
    In branches to which 24d209dba5a3 ("usb: dwc2: Fix hibernation between
    host and device modes.") has been back-ported, the bus_suspended member
    of struct dwc2_hsotg is only present in builds that support host-mode.
    To avoid having to pull in several more non-Fix commits in order to
    get it to compile, wrap the usage of the member in a macro conditional.
    
    Fixes: 24d209dba5a3 ("usb: dwc2: Fix hibernation between host and device modes.")
    Signed-off-by: Phil Elwell <phil@raspberrypi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 569496aa3776eea1ff0d49d0174ac1b7e861e107
Author: Ye Bin <yebin10@huawei.com>
Date:   Thu May 6 22:10:42 2021 +0800

    ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed
    
    commit 082cd4ec240b8734a82a89ffb890216ac98fec68 upstream.
    
    We got follow bug_on when run fsstress with injecting IO fault:
    [130747.323114] kernel BUG at fs/ext4/extents_status.c:762!
    [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP
    ......
    [130747.334329] Call trace:
    [130747.334553]  ext4_es_cache_extent+0x150/0x168 [ext4]
    [130747.334975]  ext4_cache_extents+0x64/0xe8 [ext4]
    [130747.335368]  ext4_find_extent+0x300/0x330 [ext4]
    [130747.335759]  ext4_ext_map_blocks+0x74/0x1178 [ext4]
    [130747.336179]  ext4_map_blocks+0x2f4/0x5f0 [ext4]
    [130747.336567]  ext4_mpage_readpages+0x4a8/0x7a8 [ext4]
    [130747.336995]  ext4_readpage+0x54/0x100 [ext4]
    [130747.337359]  generic_file_buffered_read+0x410/0xae8
    [130747.337767]  generic_file_read_iter+0x114/0x190
    [130747.338152]  ext4_file_read_iter+0x5c/0x140 [ext4]
    [130747.338556]  __vfs_read+0x11c/0x188
    [130747.338851]  vfs_read+0x94/0x150
    [130747.339110]  ksys_read+0x74/0xf0
    
    This patch's modification is according to Jan Kara's suggestion in:
    https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/
    "I see. Now I understand your patch. Honestly, seeing how fragile is trying
    to fix extent tree after split has failed in the middle, I would probably
    go even further and make sure we fix the tree properly in case of ENOSPC
    and EDQUOT (those are easily user triggerable).  Anything else indicates a
    HW problem or fs corruption so I'd rather leave the extent tree as is and
    don't try to fix it (which also means we will not create overlapping
    extents)."
    
    Cc: stable@kernel.org
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20210506141042.3298679-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1294a5d725e8d19d661c8065959128da0ab7ef52
Author: Carlos M <carlos.marr.pz@gmail.com>
Date:   Mon May 31 22:20:26 2021 +0200

    ALSA: hda: Fix for mute key LED for HP Pavilion 15-CK0xx
    
    commit 901be145a46eb79879367d853194346a549e623d upstream.
    
    For the HP Pavilion 15-CK0xx, with audio subsystem ID 0x103c:0x841c,
    adding a line in patch_realtek.c to apply the ALC269_FIXUP_HP_MUTE_LED_MIC3
    fix activates the mute key LED.
    
    Signed-off-by: Carlos M <carlos.marr.pz@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210531202026.35427-1-carlos.marr.pz@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db6e9d1cc260e3d333221d05b74029793742d5dc
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jun 2 13:38:23 2021 +0200

    ALSA: timer: Fix master timer notification
    
    commit 9c1fe96bded935369f8340c2ac2e9e189f697d5d upstream.
    
    snd_timer_notify1() calls the notification to each slave for a master
    event, but it passes a wrong event number.  It should be +10 offset,
    corresponding to SNDRV_TIMER_EVENT_MXXX, but it's incorrectly with
    +100 offset.  Casually this was spotted by UBSAN check via syzkaller.
    
    Reported-by: syzbot+d102fa5b35335a7e544e@syzkaller.appspotmail.com
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/000000000000e5560e05c3bd1d63@google.com
    Link: https://lore.kernel.org/r/20210602113823.23777-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb7bb81ac98d806ee47fc0ab3849db22df27471f
Author: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Date:   Mon Mar 8 18:42:03 2021 +0100

    HID: multitouch: require Finger field to mark Win8 reports as MT
    
    commit a2353e3b26012ff43bcdf81d37a3eaddd7ecdbf3 upstream.
    
    This effectively changes collection_is_mt from
      contact ID in report->field
    to
      (device is Win8 => collection is finger) && contact ID in report->field
    
    Some devices erroneously report Pen for fingers, and Win8 stylus-on-touchscreen
    devices report contact ID, but mark the accompanying touchscreen device's
    collection correctly
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
    Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ea0ab48e755d8f29fe89eb235fb86176fdb597f
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Jun 3 19:39:35 2021 +0300

    net: caif: fix memory leak in cfusbl_device_notify
    
    commit 7f5d86669fa4d485523ddb1d212e0a2d90bd62bb upstream.
    
    In case of caif_enroll_dev() fail, allocated
    link_support won't be assigned to the corresponding
    structure. So simply free allocated pointer in case
    of error.
    
    Fixes: 7ad65bf68d70 ("caif: Add support for CAIF over CDC NCM USB interface")
    Cc: stable@vger.kernel.org
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3be863c11cab725add9fef4237ed4e232c3fc3bb
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Jun 3 19:39:11 2021 +0300

    net: caif: fix memory leak in caif_device_notify
    
    commit b53558a950a89824938e9811eddfc8efcd94e1bb upstream.
    
    In case of caif_enroll_dev() fail, allocated
    link_support won't be assigned to the corresponding
    structure. So simply free allocated pointer in case
    of error
    
    Fixes: 7c18d2205ea7 ("caif: Restructure how link caif link layer enroll")
    Cc: stable@vger.kernel.org
    Reported-and-tested-by: syzbot+7ec324747ce876a29db6@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 758f725c392ec073f9f1cfbe34323ca1372afbf8
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Jun 3 19:38:51 2021 +0300

    net: caif: add proper error handling
    
    commit a2805dca5107d5603f4bbc027e81e20d93476e96 upstream.
    
    caif_enroll_dev() can fail in some cases. Ingnoring
    these cases can lead to memory leak due to not assigning
    link_support pointer to anywhere.
    
    Fixes: 7c18d2205ea7 ("caif: Restructure how link caif link layer enroll")
    Cc: stable@vger.kernel.org
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef1461e1198e7ede8cea9b6cb437d5dbd17b5ac7
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Jun 3 19:38:12 2021 +0300

    net: caif: added cfserl_release function
    
    commit bce130e7f392ddde8cfcb09927808ebd5f9c8669 upstream.
    
    Added cfserl_release() function.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b9e9c2ed0f1910b5201c5d37b355b60201df415
Author: Lin Ma <linma@zju.edu.cn>
Date:   Sun May 30 21:37:43 2021 +0800

    Bluetooth: use correct lock to prevent UAF of hdev object
    
    commit e305509e678b3a4af2b3cfd410f409f7cdaabb52 upstream.
    
    The hci_sock_dev_event() function will cleanup the hdev object for
    sockets even if this object may still be in used within the
    hci_sock_bound_ioctl() function, result in UAF vulnerability.
    
    This patch replace the BH context lock to serialize these affairs
    and prevent the race condition.
    
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64700748e8a7af4883538c72ada57999d9a78e92
Author: Lin Ma <linma@zju.edu.cn>
Date:   Tue May 25 14:39:02 2021 +0200

    Bluetooth: fix the erroneous flush_work() order
    
    commit 6a137caec23aeb9e036cdfd8a46dd8a366460e5d upstream.
    
    In the cleanup routine for failed initialization of HCI device,
    the flush_work(&hdev->rx_work) need to be finished before the
    flush_work(&hdev->cmd_work). Otherwise, the hci_rx_work() can
    possibly invoke new cmd_work and cause a bug, like double free,
    in late processings.
    
    This was assigned CVE-2021-3564.
    
    This patch reorder the flush_work() to fix this bug.
    
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: linux-bluetooth@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Signed-off-by: Hao Xiong <mart1n@zju.edu.cn>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a13a42c573a496a05b528ddbe6ea32083f44e9f1
Author: Hoang Le <hoang.h.le@dektech.com.au>
Date:   Thu Apr 1 09:30:48 2021 +0700

    tipc: fix unique bearer names sanity check
    
    [ Upstream commit f20a46c3044c3f75232b3d0e2d09af9b25efaf45 ]
    
    When enabling a bearer by name, we don't sanity check its name with
    higher slot in bearer list. This may have the effect that the name
    of an already enabled bearer bypasses the check.
    
    To fix the above issue, we just perform an extra checking with all
    existing bearers.
    
    Fixes: cb30a63384bc9 ("tipc: refactor function tipc_enable_bearer()")
    Cc: stable@vger.kernel.org
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 65281d6aeca781b024a3cc83df6b55b987877ae8
Author: Hoang Le <hoang.h.le@dektech.com.au>
Date:   Thu Mar 25 08:56:41 2021 +0700

    tipc: add extack messages for bearer/media failure
    
    [ Upstream commit b83e214b2e04204f1fc674574362061492c37245 ]
    
    Add extack error messages for -EINVAL errors when enabling bearer,
    getting/setting properties for a media/bearer
    
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9144f434bebd1eab8af91e2de17d30599a5e6525
Author: Magnus Karlsson <magnus.karlsson@intel.com>
Date:   Mon May 10 11:38:53 2021 +0200

    ixgbevf: add correct exception tracing for XDP
    
    [ Upstream commit faae81420d162551b6ef2d804aafc00f4cd68e0e ]
    
    Add missing exception tracing to XDP when a number of different
    errors can occur. The support was only partial. Several errors
    where not logged which would confuse the user quite a lot not
    knowing where and why the packets disappeared.
    
    Fixes: 21092e9ce8b1 ("ixgbevf: Add support for XDP_TX action")
    Reported-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
    Tested-by: Vishakha Jambekar <vishakha.jambekar@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60d59c52235201446c01b131460399b041cfc221
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Wed May 19 14:16:14 2021 +0000

    ieee802154: fix error return code in ieee802154_llsec_getparams()
    
    [ Upstream commit 373e864cf52403b0974c2f23ca8faf9104234555 ]
    
    Fix to return negative error code -ENOBUFS from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 3e9c156e2c21 ("ieee802154: add netlink interfaces for llsec")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Link: https://lore.kernel.org/r/20210519141614.3040055-1-weiyongjun1@huawei.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 813a23e0f130c6c4f1aaf84ad0c72b5b1234a409
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 8 14:25:17 2021 +0800

    ieee802154: fix error return code in ieee802154_add_iface()
    
    [ Upstream commit 79c6b8ed30e54b401c873dbad2511f2a1c525fd5 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: be51da0f3e34 ("ieee802154: Stop using NLA_PUT*().")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Link: https://lore.kernel.org/r/20210508062517.2574-1-thunder.leizhen@huawei.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8aed10cd9497933ebe3fc0afe8d8ddc1af8b0d48
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri May 28 13:45:16 2021 +0200

    netfilter: nfnetlink_cthelper: hit EBUSY on updates if size mismatches
    
    [ Upstream commit 8971ee8b087750a23f3cd4dc55bff2d0303fd267 ]
    
    The private helper data size cannot be updated. However, updates that
    contain NFCTH_PRIV_DATA_LEN might bogusly hit EBUSY even if the size is
    the same.
    
    Fixes: 12f7a505331e ("netfilter: add user-space connection tracking helper infrastructure")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 85e8c3b43f47a009b0ef924924d5fc35de054d54
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri May 14 15:58:50 2021 +0200

    HID: i2c-hid: fix format string mismatch
    
    [ Upstream commit dc5f9f55502e13ba05731d5046a14620aa2ff456 ]
    
    clang doesn't like printing a 32-bit integer using %hX format string:
    
    drivers/hid/i2c-hid/i2c-hid-core.c:994:18: error: format specifies type 'unsigned short' but the argument has type '__u32' (aka 'unsigned int') [-Werror,-Wformat]
                     client->name, hid->vendor, hid->product);
                                   ^~~~~~~~~~~
    drivers/hid/i2c-hid/i2c-hid-core.c:994:31: error: format specifies type 'unsigned short' but the argument has type '__u32' (aka 'unsigned int') [-Werror,-Wformat]
                     client->name, hid->vendor, hid->product);
                                                ^~~~~~~~~~~~
    
    Use an explicit cast to truncate it to the low 16 bits instead.
    
    Fixes: 9ee3e06610fd ("HID: i2c-hid: override HID descriptors for certain devices")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 173da500cfcef27f315dd3d1d1e8a6d5b146b227
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 8 10:47:37 2021 +0800

    HID: pidff: fix error return code in hid_pidff_init()
    
    [ Upstream commit 3dd653c077efda8152f4dd395359617d577a54cd ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 224ee88fe395 ("Input: add force feedback driver for PID devices")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6895ac910b73f7f886bb292c0a87d6e4d6eb6801
Author: Julian Anastasov <ja@ssi.bg>
Date:   Mon May 24 22:54:57 2021 +0300

    ipvs: ignore IP_VS_SVC_F_HASHED flag when adding service
    
    [ Upstream commit 56e4ee82e850026d71223262c07df7d6af3bd872 ]
    
    syzbot reported memory leak [1] when adding service with
    HASHED flag. We should ignore this flag both from sockopt
    and netlink provided data, otherwise the service is not
    hashed and not visible while releasing resources.
    
    [1]
    BUG: memory leak
    unreferenced object 0xffff888115227800 (size 512):
      comm "syz-executor263", pid 8658, jiffies 4294951882 (age 12.560s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff83977188>] kmalloc include/linux/slab.h:556 [inline]
        [<ffffffff83977188>] kzalloc include/linux/slab.h:686 [inline]
        [<ffffffff83977188>] ip_vs_add_service+0x598/0x7c0 net/netfilter/ipvs/ip_vs_ctl.c:1343
        [<ffffffff8397d770>] do_ip_vs_set_ctl+0x810/0xa40 net/netfilter/ipvs/ip_vs_ctl.c:2570
        [<ffffffff838449a8>] nf_setsockopt+0x68/0xa0 net/netfilter/nf_sockopt.c:101
        [<ffffffff839ae4e9>] ip_setsockopt+0x259/0x1ff0 net/ipv4/ip_sockglue.c:1435
        [<ffffffff839fa03c>] raw_setsockopt+0x18c/0x1b0 net/ipv4/raw.c:857
        [<ffffffff83691f20>] __sys_setsockopt+0x1b0/0x360 net/socket.c:2117
        [<ffffffff836920f2>] __do_sys_setsockopt net/socket.c:2128 [inline]
        [<ffffffff836920f2>] __se_sys_setsockopt net/socket.c:2125 [inline]
        [<ffffffff836920f2>] __x64_sys_setsockopt+0x22/0x30 net/socket.c:2125
        [<ffffffff84350efa>] do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
        [<ffffffff84400068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Reported-and-tested-by: syzbot+e562383183e4b1766930@syzkaller.appspotmail.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Reviewed-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2bd07ebcb949b17a431aacd0e99fa4558c4a5600
Author: Max Gurtovoy <mgurtovoy@nvidia.com>
Date:   Tue May 18 22:21:31 2021 +0300

    vfio/platform: fix module_put call in error flow
    
    [ Upstream commit dc51ff91cf2d1e9a2d941da483602f71d4a51472 ]
    
    The ->parent_module is the one that use in try_module_get. It should
    also be the one the we use in module_put during vfio_platform_open().
    
    Fixes: 32a2d71c4e80 ("vfio: platform: introduce vfio-platform-base module")
    Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
    Message-Id: <20210518192133.59195-1-mgurtovoy@nvidia.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f12bd9caafedebd8e468cc3ec1dcee1920d7a9d2
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Thu May 20 13:36:41 2021 +0000

    samples: vfio-mdev: fix error handing in mdpy_fb_probe()
    
    [ Upstream commit 752774ce7793a1f8baa55aae31f3b4caac49cbe4 ]
    
    Fix to return a negative error code from the framebuffer_alloc() error
    handling case instead of 0, also release regions in some error handing
    cases.
    
    Fixes: cacade1946a4 ("sample: vfio mdev display - guest driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Message-Id: <20210520133641.1421378-1-weiyongjun1@huawei.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b2ca3ee36e4e40d98c01b41a5819243197d4609
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat May 15 12:08:56 2021 -0700

    vfio/pci: zap_vma_ptes() needs MMU
    
    [ Upstream commit 2a55ca37350171d9b43d561528f23d4130097255 ]
    
    zap_vma_ptes() is only available when CONFIG_MMU is set/enabled.
    Without CONFIG_MMU, vfio_pci.o has build errors, so make
    VFIO_PCI depend on MMU.
    
    riscv64-linux-ld: drivers/vfio/pci/vfio_pci.o: in function `vfio_pci_mmap_open':
    vfio_pci.c:(.text+0x1ec): undefined reference to `zap_vma_ptes'
    riscv64-linux-ld: drivers/vfio/pci/vfio_pci.o: in function `.L0 ':
    vfio_pci.c:(.text+0x165c): undefined reference to `zap_vma_ptes'
    
    Fixes: 11c4cd07ba11 ("vfio-pci: Fault mmaps to enable vma tracking")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Alex Williamson <alex.williamson@redhat.com>
    Cc: Cornelia Huck <cohuck@redhat.com>
    Cc: kvm@vger.kernel.org
    Cc: Jason Gunthorpe <jgg@nvidia.com>
    Cc: Eric Auger <eric.auger@redhat.com>
    Message-Id: <20210515190856.2130-1-rdunlap@infradead.org>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c953aee0d8a162d249dedaa47111e95dde0461cd
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 15 10:04:58 2021 +0800

    vfio/pci: Fix error return code in vfio_ecap_init()
    
    [ Upstream commit d1ce2c79156d3baf0830990ab06d296477b93c26 ]
    
    The error code returned from vfio_ext_cap_len() is stored in 'len', not
    in 'ret'.
    
    Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
    Message-Id: <20210515020458.6771-1-thunder.leizhen@huawei.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd47a33e11fdd6c9d31570500e6ecc369ba1f08e
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Wed Apr 21 21:46:36 2021 +0200

    efi: cper: fix snprintf() use in cper_dimm_err_location()
    
    [ Upstream commit 942859d969de7f6f7f2659a79237a758b42782da ]
    
    snprintf() should be given the full buffer size, not one less. And it
    guarantees nul-termination, so doing it manually afterwards is
    pointless.
    
    It's even potentially harmful (though probably not in practice because
    CPER_REC_LEN is 256), due to the "return how much would have been
    written had the buffer been big enough" semantics. I.e., if the bank
    and/or device strings are long enough that the "DIMM location ..."
    output gets truncated, writing to msg[n] is a buffer overflow.
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Fixes: 3760cd20402d4 ("CPER: Adjust code flow of some functions")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5fdb418b14e41b33880b949db64b18f1f448916b
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Fri Apr 30 16:22:51 2021 +0200

    efi: Allow EFI_MEMORY_XP and EFI_MEMORY_RO both to be cleared
    
    [ Upstream commit 45add3cc99feaaf57d4b6f01d52d532c16a1caee ]
    
    UEFI spec 2.9, p.108, table 4-1 lists the scenario that both attributes
    are cleared with the description "No memory access protection is
    possible for Entry". So we can have valid entries where both attributes
    are cleared, so remove the check.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Fixes: 10f0d2f577053 ("efi: Implement generic support for the Memory Attributes table")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e9cd487b04f6715c4f14ddd81c5740be852aff2
Author: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Date:   Thu Jun 3 09:28:52 2021 -0700

    nl80211: validate key indexes for cfg80211_registered_device
    
    commit 2d9463083ce92636a1bdd3e30d1236e3e95d859e upstream
    
    syzbot discovered a bug in which an OOB access was being made because
    an unsuitable key_idx value was wrongly considered to be acceptable
    while deleting a key in nl80211_del_key().
    
    Since we don't know the cipher at the time of deletion, if
    cfg80211_validate_key_settings() were to be called directly in
    nl80211_del_key(), even valid keys would be wrongly determined invalid,
    and deletion wouldn't occur correctly.
    For this reason, a new function - cfg80211_valid_key_idx(), has been
    created, to determine if the key_idx value provided is valid or not.
    cfg80211_valid_key_idx() is directly called in 2 places -
    nl80211_del_key(), and cfg80211_validate_key_settings().
    
    Reported-by: syzbot+49d4cab497c2142ee170@syzkaller.appspotmail.com
    Tested-by: syzbot+49d4cab497c2142ee170@syzkaller.appspotmail.com
    Suggested-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
    Link: https://lore.kernel.org/r/20201204215825.129879-1-anant.thazhemadam@gmail.com
    Cc: stable@vger.kernel.org
    [also disallow IGTK key IDs if no IGTK cipher is supported]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Zubin Mithra <zsm@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f9186ee7a306d7f974e759b084245155e5e709a
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Sat Jan 11 15:47:36 2020 -0600

    ALSA: usb: update old-style static const declaration
    
    [ Upstream commit ff40e0d41af19e36b43693fcb9241b4a6795bb44 ]
    
    GCC reports the following warning with W=1
    
    sound/usb/mixer_quirks.c: In function ‘snd_microii_controls_create’:
    sound/usb/mixer_quirks.c:1694:2: warning: ‘static’ is not at beginning
    of declaration [-Wold-style-declaration]
     1694 |  const static usb_mixer_elem_resume_func_t resume_funcs[] = {
          |  ^~~~~
    
    Move static to the beginning of declaration
    
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20200111214736.3002-3-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24ea2de9c342a09dc7c87cc428c09176af5ee063
Author: Grant Grundler <grundler@chromium.org>
Date:   Tue Jan 19 17:12:08 2021 -0800

    net: usb: cdc_ncm: don't spew notifications
    
    [ Upstream commit de658a195ee23ca6aaffe197d1d2ea040beea0a2 ]
    
    RTL8156 sends notifications about every 32ms.
    Only display/log notifications when something changes.
    
    This issue has been reported by others:
            https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1832472
            https://lkml.org/lkml/2020/8/27/1083
    
    ...
    [785962.779840] usb 1-1: new high-speed USB device number 5 using xhci_hcd
    [785962.929944] usb 1-1: New USB device found, idVendor=0bda, idProduct=8156, bcdDevice=30.00
    [785962.929949] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
    [785962.929952] usb 1-1: Product: USB 10/100/1G/2.5G LAN
    [785962.929954] usb 1-1: Manufacturer: Realtek
    [785962.929956] usb 1-1: SerialNumber: 000000001
    [785962.991755] usbcore: registered new interface driver cdc_ether
    [785963.017068] cdc_ncm 1-1:2.0: MAC-Address: 00:24:27:88:08:15
    [785963.017072] cdc_ncm 1-1:2.0: setting rx_max = 16384
    [785963.017169] cdc_ncm 1-1:2.0: setting tx_max = 16384
    [785963.017682] cdc_ncm 1-1:2.0 usb0: register 'cdc_ncm' at usb-0000:00:14.0-1, CDC NCM, 00:24:27:88:08:15
    [785963.019211] usbcore: registered new interface driver cdc_ncm
    [785963.023856] usbcore: registered new interface driver cdc_wdm
    [785963.025461] usbcore: registered new interface driver cdc_mbim
    [785963.038824] cdc_ncm 1-1:2.0 enx002427880815: renamed from usb0
    [785963.089586] cdc_ncm 1-1:2.0 enx002427880815: network connection: disconnected
    [785963.121673] cdc_ncm 1-1:2.0 enx002427880815: network connection: disconnected
    [785963.153682] cdc_ncm 1-1:2.0 enx002427880815: network connection: disconnected
    ...
    
    This is about 2KB per second and will overwrite all contents of a 1MB
    dmesg buffer in under 10 minutes rendering them useless for debugging
    many kernel problems.
    
    This is also an extra 180 MB/day in /var/logs (or 1GB per week) rendering
    the majority of those logs useless too.
    
    When the link is up (expected state), spew amount is >2x higher:
    ...
    [786139.600992] cdc_ncm 2-1:2.0 enx002427880815: network connection: connected
    [786139.632997] cdc_ncm 2-1:2.0 enx002427880815: 2500 mbit/s downlink 2500 mbit/s uplink
    [786139.665097] cdc_ncm 2-1:2.0 enx002427880815: network connection: connected
    [786139.697100] cdc_ncm 2-1:2.0 enx002427880815: 2500 mbit/s downlink 2500 mbit/s uplink
    [786139.729094] cdc_ncm 2-1:2.0 enx002427880815: network connection: connected
    [786139.761108] cdc_ncm 2-1:2.0 enx002427880815: 2500 mbit/s downlink 2500 mbit/s uplink
    ...
    
    Chrome OS cannot support RTL8156 until this is fixed.
    
    Signed-off-by: Grant Grundler <grundler@chromium.org>
    Reviewed-by: Hayes Wang <hayeswang@realtek.com>
    Link: https://lore.kernel.org/r/20210120011208.3768105-1-grundler@chromium.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>