commit e23d55af0e1fca9be5c99f0c37d48b289f4d6489
Author: Sasha Levin <sashal@kernel.org>
Date:   Thu Aug 26 08:56:20 2021 -0400

    Linux 4.19.205
    
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 991158d680774ca5010fe6e15aa3a61aebfdf688
Author: Sergey Marinkevich <sergey.marinkevich@eltex-co.ru>
Date:   Sun Mar 29 19:19:14 2020 +0700

    netfilter: nft_exthdr: fix endianness of tcp option cast
    
    [ Upstream commit 2e34328b396a69b73661ba38d47d92b7cf21c2c4 ]
    
    I got a problem on MIPS with Big-Endian is turned on: every time when
    NF trying to change TCP MSS it returns because of new.v16 was greater
    than old.v16. But real MSS was 1460 and my rule was like this:
    
            add rule table chain tcp option maxseg size set 1400
    
    And 1400 is lesser that 1460, not greater.
    
    Later I founded that main causer is cast from u32 to __be16.
    
    Debugging:
    
    In example MSS = 1400(HEX: 0x578). Here is representation of each byte
    like it is in memory by addresses from left to right(e.g. [0x0 0x1 0x2
    0x3]). LE — Little-Endian system, BE — Big-Endian, left column is type.
    
                 LE               BE
            u32: [78 05 00 00]    [00 00 05 78]
    
    As you can see, u32 representation will be casted to u16 from different
    half of 4-byte address range. But actually nf_tables uses registers and
    store data of various size. Actually TCP MSS stored in 2 bytes. But
    registers are still u32 in definition:
    
            struct nft_regs {
                    union {
                            u32                     data[20];
                            struct nft_verdict      verdict;
                    };
            };
    
    So, access like regs->data[priv->sreg] exactly u32. So, according to
    table presents above, per-byte representation of stored TCP MSS in
    register will be:
    
                                 LE               BE
            (u32)regs->data[]:   [78 05 00 00]    [05 78 00 00]
                                                   ^^ ^^
    
    We see that register uses just half of u32 and other 2 bytes may be
    used for some another data. But in nft_exthdr_tcp_set_eval() it casted
    just like u32 -> __be16:
    
            new.v16 = src
    
    But u32 overfill __be16, so it get 2 low bytes. For clarity draw
    one more table(<xx xx> means that bytes will be used for cast).
    
                                 LE                 BE
            u32:                 [<78 05> 00 00]    [00 00 <05 78>]
            (u32)regs->data[]:   [<78 05> 00 00]    [05 78 <00 00>]
    
    As you can see, for Little-Endian nothing changes, but for Big-endian we
    take the wrong half. In my case there is some other data instead of
    zeros, so new MSS was wrongly greater.
    
    For shooting this bug I used solution for ports ranges. Applying of this
    patch does not affect Little-Endian systems.
    
    Signed-off-by: Sergey Marinkevich <sergey.marinkevich@eltex-co.ru>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ce8ad137e3ad0ea20a55fdb8d9cfe01bd79a109
Author: Jeff Layton <jlayton@kernel.org>
Date:   Fri Aug 20 09:29:50 2021 -0400

    fs: warn about impending deprecation of mandatory locks
    
    [ Upstream commit fdd92b64d15bc4aec973caa25899afd782402e68 ]
    
    We've had CONFIG_MANDATORY_FILE_LOCKING since 2015 and a lot of distros
    have disabled it. Warn the stragglers that still use "-o mand" that
    we'll be dropping support for that mount option.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3cab951cf059bd6854c3b796f6df928f0c78224c
Author: Jeff Layton <jlayton@kernel.org>
Date:   Thu Aug 15 15:21:17 2019 -0400

    locks: print a warning when mount fails due to lack of "mand" support
    
    [ Upstream commit df2474a22c42ce419b67067c52d71da06c385501 ]
    
    Since 9e8925b67a ("locks: Allow disabling mandatory locking at compile
    time"), attempts to mount filesystems with "-o mand" will fail.
    Unfortunately, there is no other indiciation of the reason for the
    failure.
    
    Change how the function is defined for better readability. When
    CONFIG_MANDATORY_FILE_LOCKING is disabled, printk a warning when
    someone attempts to mount with -o mand.
    
    Also, add a blurb to the mandatory-locking.txt file to explain about
    the "mand" option, and the behavior one should expect when it is
    disabled.
    
    Reported-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c764cf4c8f93485e38048c91d5c935a3f817f6e2
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Aug 19 17:29:45 2021 +0200

    ASoC: intel: atom: Fix breakage for PCM buffer address setup
    
    [ Upstream commit 65ca89c2b12cca0d473f3dd54267568ad3af55cc ]
    
    The commit 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM
    buffer address") changed the reference of PCM buffer address to
    substream->runtime->dma_addr as the buffer address may change
    dynamically.  However, I forgot that the dma_addr field is still not
    set up for the CONTINUOUS buffer type (that this driver uses) yet in
    5.14 and earlier kernels, and it resulted in garbage I/O.  The problem
    will be fixed in 5.15, but we need to address it quickly for now.
    
    The fix is to deduce the address again from the DMA pointer with
    virt_to_phys(), but from the right one, substream->runtime->dma_area.
    
    Fixes: 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM buffer address")
    Reported-and-tested-by: Hans de Goede <hdegoede@redhat.com>
    Cc: <stable@vger.kernel.org>
    Acked-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/2048c6aa-2187-46bd-6772-36a4fb3c5aeb@redhat.com
    Link: https://lore.kernel.org/r/20210819152945.8510-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aad377827b65f466f0416172e2bddc9959e181c9
Author: Marcin Bachry <hegel666@gmail.com>
Date:   Wed Jul 21 22:58:58 2021 -0400

    PCI: Increase D3 delay for AMD Renoir/Cezanne XHCI
    
    [ Upstream commit e0bff43220925b7e527f9d3bc9f5c624177c959e ]
    
    The Renoir XHCI controller apparently doesn't resume reliably with the
    standard D3hot-to-D0 delay.  Increase it to 20ms.
    
    [Alex: I talked to the AMD USB hardware team and the AMD Windows team and
    they are not aware of any HW errata or specific issues.  The HW works fine
    in Windows.  I was told Windows uses a rather generous default delay of
    100ms for PCI state transitions.]
    
    Link: https://lore.kernel.org/r/20210722025858.220064-1-alexander.deucher@amd.com
    Signed-off-by: Marcin Bachry <hegel666@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Prike Liang <prike.liang@amd.com>
    Cc: Shyam Sundar S K <shyam-sundar.s-k@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9732f81ed648a6afe76e1f605a8c8048a0cbc28a
Author: NeilBrown <neilb@suse.de>
Date:   Fri Aug 6 14:26:24 2021 +1000

    btrfs: prevent rename2 from exchanging a subvol with a directory from different parents
    
    [ Upstream commit 3f79f6f6247c83f448c8026c3ee16d4636ef8d4f ]
    
    Cross-rename lacks a check when that would prevent exchanging a
    directory and subvolume from different parent subvolume. This causes
    data inconsistencies and is caught before commit by tree-checker,
    turning the filesystem to read-only.
    
    Calling the renameat2 with RENAME_EXCHANGE flags like
    
      renameat2(AT_FDCWD, namesrc, AT_FDCWD, namedest, (1 << 1))
    
    on two paths:
    
      namesrc = dir1/subvol1/dir2
     namedest = subvol2/subvol3
    
    will cause key order problem with following write time tree-checker
    report:
    
      [1194842.307890] BTRFS critical (device loop1): corrupt leaf: root=5 block=27574272 slot=10 ino=258, invalid previous key objectid, have 257 expect 258
      [1194842.322221] BTRFS info (device loop1): leaf 27574272 gen 8 total ptrs 11 free space 15444 owner 5
      [1194842.331562] BTRFS info (device loop1): refs 2 lock_owner 0 current 26561
      [1194842.338772]        item 0 key (256 1 0) itemoff 16123 itemsize 160
      [1194842.338793]                inode generation 3 size 16 mode 40755
      [1194842.338801]        item 1 key (256 12 256) itemoff 16111 itemsize 12
      [1194842.338809]        item 2 key (256 84 2248503653) itemoff 16077 itemsize 34
      [1194842.338817]                dir oid 258 type 2
      [1194842.338823]        item 3 key (256 84 2363071922) itemoff 16043 itemsize 34
      [1194842.338830]                dir oid 257 type 2
      [1194842.338836]        item 4 key (256 96 2) itemoff 16009 itemsize 34
      [1194842.338843]        item 5 key (256 96 3) itemoff 15975 itemsize 34
      [1194842.338852]        item 6 key (257 1 0) itemoff 15815 itemsize 160
      [1194842.338863]                inode generation 6 size 8 mode 40755
      [1194842.338869]        item 7 key (257 12 256) itemoff 15801 itemsize 14
      [1194842.338876]        item 8 key (257 84 2505409169) itemoff 15767 itemsize 34
      [1194842.338883]                dir oid 256 type 2
      [1194842.338888]        item 9 key (257 96 2) itemoff 15733 itemsize 34
      [1194842.338895]        item 10 key (258 12 256) itemoff 15719 itemsize 14
      [1194842.339163] BTRFS error (device loop1): block=27574272 write time tree block corruption detected
      [1194842.339245] ------------[ cut here ]------------
      [1194842.443422] WARNING: CPU: 6 PID: 26561 at fs/btrfs/disk-io.c:449 csum_one_extent_buffer+0xed/0x100 [btrfs]
      [1194842.511863] CPU: 6 PID: 26561 Comm: kworker/u17:2 Not tainted 5.14.0-rc3-git+ #793
      [1194842.511870] Hardware name: empty empty/S3993, BIOS PAQEX0-3 02/24/2008
      [1194842.511876] Workqueue: btrfs-worker-high btrfs_work_helper [btrfs]
      [1194842.511976] RIP: 0010:csum_one_extent_buffer+0xed/0x100 [btrfs]
      [1194842.512068] RSP: 0018:ffffa2c284d77da0 EFLAGS: 00010282
      [1194842.512074] RAX: 0000000000000000 RBX: 0000000000001000 RCX: ffff928867bd9978
      [1194842.512078] RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff928867bd9970
      [1194842.512081] RBP: ffff92876b958000 R08: 0000000000000001 R09: 00000000000c0003
      [1194842.512085] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
      [1194842.512088] R13: ffff92875f989f98 R14: 0000000000000000 R15: 0000000000000000
      [1194842.512092] FS:  0000000000000000(0000) GS:ffff928867a00000(0000) knlGS:0000000000000000
      [1194842.512095] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [1194842.512099] CR2: 000055f5384da1f0 CR3: 0000000102fe4000 CR4: 00000000000006e0
      [1194842.512103] Call Trace:
      [1194842.512128]  ? run_one_async_free+0x10/0x10 [btrfs]
      [1194842.631729]  btree_csum_one_bio+0x1ac/0x1d0 [btrfs]
      [1194842.631837]  run_one_async_start+0x18/0x30 [btrfs]
      [1194842.631938]  btrfs_work_helper+0xd5/0x1d0 [btrfs]
      [1194842.647482]  process_one_work+0x262/0x5e0
      [1194842.647520]  worker_thread+0x4c/0x320
      [1194842.655935]  ? process_one_work+0x5e0/0x5e0
      [1194842.655946]  kthread+0x135/0x160
      [1194842.655953]  ? set_kthread_struct+0x40/0x40
      [1194842.655965]  ret_from_fork+0x1f/0x30
      [1194842.672465] irq event stamp: 1729
      [1194842.672469] hardirqs last  enabled at (1735): [<ffffffffbd1104f5>] console_trylock_spinning+0x185/0x1a0
      [1194842.672477] hardirqs last disabled at (1740): [<ffffffffbd1104cc>] console_trylock_spinning+0x15c/0x1a0
      [1194842.672482] softirqs last  enabled at (1666): [<ffffffffbdc002e1>] __do_softirq+0x2e1/0x50a
      [1194842.672491] softirqs last disabled at (1651): [<ffffffffbd08aab7>] __irq_exit_rcu+0xa7/0xd0
    
    The corrupted data will not be written, and filesystem can be unmounted
    and mounted again (all changes since the last commit will be lost).
    
    Add the missing check for new_ino so that all non-subvolumes must reside
    under the same parent subvolume. There's an exception allowing to
    exchange two subvolumes from any parents as the directory representing a
    subvolume is only a logical link and does not have any other structures
    related to the parent subvolume, unlike files, directories etc, that
    are always in the inode namespace of the parent subvolume.
    
    Fixes: cdd1fedf8261 ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT")
    CC: stable@vger.kernel.org # 4.7+
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f4f2872d6641d7744081711034ee96c4b5ca206c
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Tue Aug 10 18:03:19 2021 +0800

    ipack: tpci200: fix memory leak in the tpci200_register
    
    [ Upstream commit 50f05bd114a46a74726e432bf81079d3f13a55b7 ]
    
    The error handling code in tpci200_register does not free interface_regs
    allocated by ioremap and the current version of error handling code is
    problematic.
    
    Fix this by refactoring the error handling code and free interface_regs
    when necessary.
    
    Fixes: 43986798fd50 ("ipack: add error handling for ioremap_nocache")
    Cc: stable@vger.kernel.org
    Reported-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Link: https://lore.kernel.org/r/20210810100323.3938492-2-mudongliangabcd@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19c09f4cc96790f365f2384e12e04c81d1c00be0
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Tue Aug 10 18:03:18 2021 +0800

    ipack: tpci200: fix many double free issues in tpci200_pci_probe
    
    [ Upstream commit 57a1681095f912239c7fb4d66683ab0425973838 ]
    
    The function tpci200_register called by tpci200_install and
    tpci200_unregister called by tpci200_uninstall are in pair. However,
    tpci200_unregister has some cleanup operations not in the
    tpci200_register. So the error handling code of tpci200_pci_probe has
    many different double free issues.
    
    Fix this problem by moving those cleanup operations out of
    tpci200_unregister, into tpci200_pci_remove and reverting
    the previous commit 9272e5d0028d ("ipack/carriers/tpci200:
    Fix a double free in tpci200_pci_probe").
    
    Fixes: 9272e5d0028d ("ipack/carriers/tpci200: Fix a double free in tpci200_pci_probe")
    Cc: stable@vger.kernel.org
    Reported-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Link: https://lore.kernel.org/r/20210810100323.3938492-1-mudongliangabcd@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 299400448c7889dd4293f2e2d34e8276ceae40da
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Mon Aug 9 09:24:28 2021 +0100

    slimbus: ngd: reset dma setup during runtime pm
    
    [ Upstream commit d77772538f00b7265deace6e77e555ee18365ad0 ]
    
    During suspend/resume NGD remote instance is power cycled along
    with remotely controlled bam dma engine.
    So Reset the dma configuration during this suspend resume path
    so that we are not dealing with any stale dma setup.
    
    Without this transactions timeout after first suspend resume path.
    
    Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20210809082428.11236-5-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac8d2c61359c3aca1f3f1c46f2fd3aca4fd4497e
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Mon Aug 9 09:24:26 2021 +0100

    slimbus: messaging: check for valid transaction id
    
    [ Upstream commit a263c1ff6abe0e66712f40d595bbddc7a35907f8 ]
    
    In some usecases transaction ids are dynamically allocated inside
    the controller driver after sending the messages which have generic
    acknowledge responses. So check for this before refcounting pm_runtime.
    
    Without this we would end up imbalancing runtime pm count by
    doing pm_runtime_put() in both slim_do_transfer() and slim_msg_response()
    for a single  pm_runtime_get() in slim_do_transfer()
    
    Fixes: d3062a210930 ("slimbus: messaging: add slim_alloc/free_txn_tid()")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20210809082428.11236-3-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea99a7fae21b554d50880d3392122ffce14615ef
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Mon Aug 9 09:24:25 2021 +0100

    slimbus: messaging: start transaction ids from 1 instead of zero
    
    [ Upstream commit 9659281ce78de0f15a4aa124da8f7450b1399c09 ]
    
    As tid is unsigned its hard to figure out if the tid is valid or
    invalid. So Start the transaction ids from 1 instead of zero
    so that we could differentiate between a valid tid and invalid tids
    
    This is useful in cases where controller would add a tid for controller
    specific transfers.
    
    Fixes: d3062a210930 ("slimbus: messaging: add slim_alloc/free_txn_tid()")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20210809082428.11236-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d349b0a69edc4f7f09c543abd098ab3c7fe31c3
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Sun Aug 8 00:30:11 2021 -0400

    tracing / histogram: Fix NULL pointer dereference on strcmp() on NULL event name
    
    [ Upstream commit 5acce0bff2a0420ce87d4591daeb867f47d552c2 ]
    
    The following commands:
    
     # echo 'read_max u64 size;' > synthetic_events
     # echo 'hist:keys=common_pid:count=count:onmax($count).trace(read_max,count)' > events/syscalls/sys_enter_read/trigger
    
    Causes:
    
     BUG: kernel NULL pointer dereference, address: 0000000000000000
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 0 P4D 0
     Oops: 0000 [#1] PREEMPT SMP
     CPU: 4 PID: 1763 Comm: bash Not tainted 5.14.0-rc2-test+ #155
     Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01
    v03.03 07/14/2016
     RIP: 0010:strcmp+0xc/0x20
     Code: 75 f7 31 c0 0f b6 0c 06 88 0c 02 48 83 c0 01 84 c9 75 f1 4c 89 c0
    c3 0f 1f 80 00 00 00 00 31 c0 eb 08 48 83 c0 01 84 d2 74 0f <0f> b6 14 07
    3a 14 06 74 ef 19 c0 83 c8 01 c3 31 c0 c3 66 90 48 89
     RSP: 0018:ffffb5fdc0963ca8 EFLAGS: 00010246
     RAX: 0000000000000000 RBX: ffffffffb3a4e040 RCX: 0000000000000000
     RDX: 0000000000000000 RSI: ffff9714c0d0b640 RDI: 0000000000000000
     RBP: 0000000000000000 R08: 00000022986b7cde R09: ffffffffb3a4dff8
     R10: 0000000000000000 R11: 0000000000000000 R12: ffff9714c50603c8
     R13: 0000000000000000 R14: ffff97143fdf9e48 R15: ffff9714c01a2210
     FS:  00007f1fa6785740(0000) GS:ffff9714da400000(0000)
    knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000000 CR3: 000000002d863004 CR4: 00000000001706e0
     Call Trace:
      __find_event_file+0x4e/0x80
      action_create+0x6b7/0xeb0
      ? kstrdup+0x44/0x60
      event_hist_trigger_func+0x1a07/0x2130
      trigger_process_regex+0xbd/0x110
      event_trigger_write+0x71/0xd0
      vfs_write+0xe9/0x310
      ksys_write+0x68/0xe0
      do_syscall_64+0x3b/0x90
      entry_SYSCALL_64_after_hwframe+0x44/0xae
     RIP: 0033:0x7f1fa6879e87
    
    The problem was the "trace(read_max,count)" where the "count" should be
    "$count" as "onmax()" only handles variables (although it really should be
    able to figure out that "count" is a field of sys_enter_read). But there's
    a path that does not find the variable and ends up passing a NULL for the
    event, which ends up getting passed to "strcmp()".
    
    Add a check for NULL to return and error on the command with:
    
     # cat error_log
      hist:syscalls:sys_enter_read: error: Couldn't create or find variable
      Command: hist:keys=common_pid:count=count:onmax($count).trace(read_max,count)
                                    ^
    Link: https://lkml.kernel.org/r/20210808003011.4037f8d0@oasis.local.home
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: stable@vger.kernel.org
    Fixes: 50450603ec9cb tracing: Add 'onmax' hist trigger action support
    Reviewed-by: Tom Zanussi <zanussi@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6675b20518adcb71361585c041a641b5ad6e86d7
Author: Jaroslav Kysela <perex@perex.cz>
Date:   Wed Aug 11 18:14:41 2021 +0200

    ALSA: hda - fix the 'Capture Switch' value change notifications
    
    [ Upstream commit a2befe9380dd04ee76c871568deca00eedf89134 ]
    
    The original code in the cap_put_caller() function does not
    handle correctly the positive values returned from the passed
    function for multiple iterations. It means that the change
    notifications may be lost.
    
    Fixes: 352f7f914ebb ("ALSA: hda - Merge Realtek parser code to generic parser")
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213851
    Cc: <stable@kernel.org>
    Signed-off-by: Jaroslav Kysela <perex@perex.cz>
    Link: https://lore.kernel.org/r/20210811161441.1325250-1-perex@perex.cz
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e0eb0f65e681cad35644c7e8dd7ee526c075b9c7
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Wed Jun 30 12:22:32 2021 +0200

    mmc: dw_mmc: Fix hang on data CRC error
    
    [ Upstream commit 25f8203b4be1937c4939bb98623e67dcfd7da4d1 ]
    
    When a Data CRC interrupt is received, the driver disables the DMA, then
    sends the stop/abort command and then waits for Data Transfer Over.
    
    However, sometimes, when a data CRC error is received in the middle of a
    multi-block write transfer, the Data Transfer Over interrupt is never
    received, and the driver hangs and never completes the request.
    
    The driver sets the BMOD.SWR bit (SDMMC_IDMAC_SWRESET) when stopping the
    DMA, but according to the manual CMD.STOP_ABORT_CMD should be programmed
    "before assertion of SWR".  Do these operations in the recommended
    order.  With this change the Data Transfer Over is always received
    correctly in my tests.
    
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210630102232.16011-1-vincent.whitchurch@axis.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fed44f82ffa8443f4ddc5c269f1ab8f388fe9382
Author: Saravana Kannan <saravanak@google.com>
Date:   Tue Aug 17 20:38:03 2021 -0700

    net: mdio-mux: Handle -EPROBE_DEFER correctly
    
    [ Upstream commit 7bd0cef5dac685f09ef8b0b2a7748ff42d284dc7 ]
    
    When registering mdiobus children, if we get an -EPROBE_DEFER, we shouldn't
    ignore it and continue registering the rest of the mdiobus children. This
    would permanently prevent the deferring child mdiobus from working instead
    of reattempting it in the future. So, if a child mdiobus needs to be
    reattempted in the future, defer the entire mdio-mux initialization.
    
    This fixes the issue where PHYs sitting under the mdio-mux aren't
    initialized correctly if the PHY's interrupt controller is not yet ready
    when the mdio-mux is being probed. Additional context in the link below.
    
    Fixes: 0ca2997d1452 ("netdev/of/phy: Add MDIO bus multiplexer support.")
    Link: https://lore.kernel.org/lkml/CAGETcx95kHrv8wA-O+-JtfH7H9biJEGJtijuPVN0V5dUKUAB3A@mail.gmail.com/#t
    Signed-off-by: Saravana Kannan <saravanak@google.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Kevin Hilman <khilman@baylibre.com>
    Tested-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f87a13eb37f813aa1bfeb047052204e8ec2a325
Author: Saravana Kannan <saravanak@google.com>
Date:   Tue Aug 17 20:38:02 2021 -0700

    net: mdio-mux: Don't ignore memory allocation errors
    
    [ Upstream commit 99d81e942474cc7677d12f673f42a7ea699e2589 ]
    
    If we are seeing memory allocation errors, don't try to continue
    registering child mdiobus devices. It's unlikely they'll succeed.
    
    Fixes: 342fa1964439 ("mdio: mux: make child bus walking more permissive and errors more verbose")
    Signed-off-by: Saravana Kannan <saravanak@google.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Kevin Hilman <khilman@baylibre.com>
    Tested-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 260ad8a2daea03e79ced317e670eb907260e2b08
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Mon Aug 16 21:14:04 2021 +0800

    net: qlcnic: add missed unlock in qlcnic_83xx_flash_read32
    
    [ Upstream commit 0a298d133893c72c96e2156ed7cb0f0c4a306a3e ]
    
    qlcnic_83xx_unlock_flash() is called on all paths after we call
    qlcnic_83xx_lock_flash(), except for one error path on failure
    of QLCRD32(), which may cause a deadlock. This bug is suggested
    by a static analysis tool, please advise.
    
    Fixes: 81d0aeb0a4fff ("qlcnic: flash template based firmware reset recovery")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Link: https://lore.kernel.org/r/20210816131405.24024-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1458ae977ae03d3fdf8573fe4dad034c5afb6d53
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Aug 13 20:33:27 2021 +0300

    ptp_pch: Restore dependency on PCI
    
    [ Upstream commit 55c8fca1dae1fb0d11deaa21b65a647dedb1bc50 ]
    
    During the swap dependency on PCH_GBE to selection PTP_1588_CLOCK_PCH
    incidentally dropped the implicit dependency on the PCI. Restore it.
    
    Fixes: 18d359ceb044 ("pch_gbe, ptp_pch: Fix the dependency direction between these drivers")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e370cc081a78ee23528311ca58fd98a06768ec7
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Fri Aug 13 18:14:33 2021 +0300

    net: 6pack: fix slab-out-of-bounds in decode_data
    
    [ Upstream commit 19d1532a187669ce86d5a2696eb7275310070793 ]
    
    Syzbot reported slab-out-of bounds write in decode_data().
    The problem was in missing validation checks.
    
    Syzbot's reproducer generated malicious input, which caused
    decode_data() to be called a lot in sixpack_decode(). Since
    rx_count_cooked is only 400 bytes and noone reported before,
    that 400 bytes is not enough, let's just check if input is malicious
    and complain about buffer overrun.
    
    Fail log:
    ==================================================================
    BUG: KASAN: slab-out-of-bounds in drivers/net/hamradio/6pack.c:843
    Write of size 1 at addr ffff888087c5544e by task kworker/u4:0/7
    
    CPU: 0 PID: 7 Comm: kworker/u4:0 Not tainted 5.6.0-rc3-syzkaller #0
    ...
    Workqueue: events_unbound flush_to_ldisc
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x197/0x210 lib/dump_stack.c:118
     print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
     __kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506
     kasan_report+0x12/0x20 mm/kasan/common.c:641
     __asan_report_store1_noabort+0x17/0x20 mm/kasan/generic_report.c:137
     decode_data.part.0+0x23b/0x270 drivers/net/hamradio/6pack.c:843
     decode_data drivers/net/hamradio/6pack.c:965 [inline]
     sixpack_decode drivers/net/hamradio/6pack.c:968 [inline]
    
    Reported-and-tested-by: syzbot+fc8cd9a673d4577fb2e4@syzkaller.appspotmail.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b80bc6fba1cb9bc036a633a05994ff87fa9c868e
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu Aug 12 14:42:40 2021 -0700

    bnxt: disable napi before canceling DIM
    
    [ Upstream commit 01cca6b9330ac7460de44eeeb3a0607f8aae69ff ]
    
    napi schedules DIM, napi has to be disabled first,
    then DIM canceled.
    
    Noticed while reading the code.
    
    Fixes: 0bc0b97fca73 ("bnxt_en: cleanup DIM work on device shutdown")
    Fixes: 6a8788f25625 ("bnxt_en: add support for software dynamic interrupt moderation")
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa0a75c4f0a577b13589d0a8f799c547082c827d
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu Aug 12 14:42:39 2021 -0700

    bnxt: don't lock the tx queue from napi poll
    
    [ Upstream commit 3c603136c9f82833813af77185618de5af67676c ]
    
    We can't take the tx lock from the napi poll routine, because
    netpoll can poll napi at any moment, including with the tx lock
    already held.
    
    The tx lock is protecting against two paths - the disable
    path, and (as Michael points out) the NETDEV_TX_BUSY case
    which may occur if NAPI completions race with start_xmit
    and both decide to re-enable the queue.
    
    For the disable/ifdown path use synchronize_net() to make sure
    closing the device does not race we restarting the queues.
    Annotate accesses to dev_state against data races.
    
    For the NAPI cleanup vs start_xmit path - appropriate barriers
    are already in place in the main spot where Tx queue is stopped
    but we need to do the same careful dance in the TX_BUSY case.
    
    Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7cfaec657d4124e4a3d8372849de416da784515d
Author: Xie Yongji <xieyongji@bytedance.com>
Date:   Wed Jul 28 21:07:56 2021 +0800

    vhost: Fix the calculation in vhost_overflow()
    
    [ Upstream commit f7ad318ea0ad58ebe0e595e59aed270bb643b29b ]
    
    This fixes the incorrect calculation for integer overflow
    when the last address of iova range is 0xffffffff.
    
    Fixes: ec33d031a14b ("vhost: detect 32 bit integer wrap around")
    Reported-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Link: https://lore.kernel.org/r/20210728130756.97-2-xieyongji@bytedance.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53764b451221a7e0445be69de02b84a0ba2d1a42
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Aug 8 16:04:40 2021 -0700

    dccp: add do-while-0 stubs for dccp_pr_debug macros
    
    [ Upstream commit 86aab09a4870bb8346c9579864588c3d7f555299 ]
    
    GCC complains about empty macros in an 'if' statement, so convert
    them to 'do {} while (0)' macros.
    
    Fixes these build warnings:
    
    net/dccp/output.c: In function 'dccp_xmit_packet':
    ../net/dccp/output.c:283:71: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
      283 |                 dccp_pr_debug("transmit_skb() returned err=%d\n", err);
    net/dccp/ackvec.c: In function 'dccp_ackvec_update_old':
    ../net/dccp/ackvec.c:163:80: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
      163 |                                               (unsigned long long)seqno, state);
    
    Fixes: dc841e30eaea ("dccp: Extend CCID packet dequeueing interface")
    Fixes: 380240864451 ("dccp ccid-2: Update code for the Ack Vector input/registration routine")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: dccp@vger.kernel.org
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16a4777a05bc8fbcc90f4a10e3f79723bfe81579
Author: Marek Behún <kabel@kernel.org>
Date:   Thu Jul 1 00:56:01 2021 +0200

    cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant
    
    [ Upstream commit 484f2b7c61b9ae58cc00c5127bcbcd9177af8dfe ]
    
    The 1.2 GHz variant of the Armada 3720 SOC is unstable with DVFS: when
    the SOC boots, the WTMI firmware sets clocks and AVS values that work
    correctly with 1.2 GHz CPU frequency, but random crashes occur once
    cpufreq driver starts scaling.
    
    We do not know currently what is the reason:
    - it may be that the voltage value for L0 for 1.2 GHz variant provided
      by the vendor in the OTP is simply incorrect when scaling is used,
    - it may be that some delay is needed somewhere,
    - it may be something else.
    
    The most sane solution now seems to be to simply forbid the cpufreq
    driver on 1.2 GHz variant.
    
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx")
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e2d55bcebe068b29392650643054b6267352d6c
Author: Ole Bjørn Midtbø <omidtbo@cisco.com>
Date:   Sat Oct 17 13:15:44 2020 +0200

    Bluetooth: hidp: use correct wait queue when removing ctrl_wait
    
    [ Upstream commit cca342d98bef68151a80b024f7bf5f388d1fbdea ]
    
    A different wait queue was used when removing ctrl_wait than when adding
    it. This effectively made the remove operation without locking compared
    to other operations on the wait queue ctrl_wait was part of. This caused
    issues like below where dead000000000100 is LIST_POISON1 and
    dead000000000200 is LIST_POISON2.
    
     list_add corruption. next->prev should be prev (ffffffc1b0a33a08), \
            but was dead000000000200. (next=ffffffc03ac77de0).
     ------------[ cut here ]------------
     CPU: 3 PID: 2138 Comm: bluetoothd Tainted: G           O    4.4.238+ #9
     ...
     ---[ end trace 0adc2158f0646eac ]---
     Call trace:
     [<ffffffc000443f78>] __list_add+0x38/0xb0
     [<ffffffc0000f0d04>] add_wait_queue+0x4c/0x68
     [<ffffffc00020eecc>] __pollwait+0xec/0x100
     [<ffffffc000d1556c>] bt_sock_poll+0x74/0x200
     [<ffffffc000bdb8a8>] sock_poll+0x110/0x128
     [<ffffffc000210378>] do_sys_poll+0x220/0x480
     [<ffffffc0002106f0>] SyS_poll+0x80/0x138
     [<ffffffc00008510c>] __sys_trace_return+0x0/0x4
    
     Unable to handle kernel paging request at virtual address dead000000000100
     ...
     CPU: 4 PID: 5387 Comm: kworker/u15:3 Tainted: G        W  O    4.4.238+ #9
     ...
     Call trace:
      [<ffffffc0000f079c>] __wake_up_common+0x7c/0xa8
      [<ffffffc0000f0818>] __wake_up+0x50/0x70
      [<ffffffc000be11b0>] sock_def_wakeup+0x58/0x60
      [<ffffffc000de5e10>] l2cap_sock_teardown_cb+0x200/0x224
      [<ffffffc000d3f2ac>] l2cap_chan_del+0xa4/0x298
      [<ffffffc000d45ea0>] l2cap_conn_del+0x118/0x198
      [<ffffffc000d45f8c>] l2cap_disconn_cfm+0x6c/0x78
      [<ffffffc000d29934>] hci_event_packet+0x564/0x2e30
      [<ffffffc000d19b0c>] hci_rx_work+0x10c/0x360
      [<ffffffc0000c2218>] process_one_work+0x268/0x460
      [<ffffffc0000c2678>] worker_thread+0x268/0x480
      [<ffffffc0000c94e0>] kthread+0x118/0x128
      [<ffffffc000085070>] ret_from_fork+0x10/0x20
      ---[ end trace 0adc2158f0646ead ]---
    
    Signed-off-by: Ole Bjørn Midtbø <omidtbo@cisco.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit edf5cef7be1aeae349a16b09857674f71759ce59
Author: Ivan T. Ivanov <iivanov@suse.de>
Date:   Wed Aug 4 11:13:39 2021 +0300

    net: usb: lan78xx: don't modify phy_device state concurrently
    
    [ Upstream commit 6b67d4d63edece1033972214704c04f36c5be89a ]
    
    Currently phy_device state could be left in inconsistent state shown
    by following alert message[1]. This is because phy_read_status could
    be called concurrently from lan78xx_delayedwork, phy_state_machine and
    __ethtool_get_link. Fix this by making sure that phy_device state is
    updated atomically.
    
    [1] lan78xx 1-1.1.1:1.0 eth0: No phy led trigger registered for speed(-1)
    
    Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e9659ee1e3378ce25b223ccb20ce981e9945035
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Sat Jun 26 02:01:03 2021 +0200

    ARM: dts: nomadik: Fix up interrupt controller node names
    
    [ Upstream commit 47091f473b364c98207c4def197a0ae386fc9af1 ]
    
    Once the new schema interrupt-controller/arm,vic.yaml is added, we get
    the below warnings:
    
            arch/arm/boot/dts/ste-nomadik-nhk15.dt.yaml:
            intc@10140000: $nodename:0: 'intc@10140000' does not match
            '^interrupt-controller(@[0-9a-f,]+)*$'
    
    Fix the node names for the interrupt controller to conform
    to the standard node name interrupt-controller@..
    
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20210617210825.3064367-2-sudeep.holla@arm.com
    Link: https://lore.kernel.org/r/20210626000103.830184-1-linus.walleij@linaro.org'
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 460add3104945704bfd2b92441b48a30b2ee9f1e
Author: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Date:   Mon Jul 26 17:24:02 2021 +0530

    scsi: core: Avoid printing an error if target_alloc() returns -ENXIO
    
    [ Upstream commit 70edd2e6f652f67d854981fd67f9ad0f1deaea92 ]
    
    Avoid printing a 'target allocation failed' error if the driver
    target_alloc() callback function returns -ENXIO. This return value
    indicates that the corresponding H:C:T:L entry is empty.
    
    Removing this error reduces the scan time if the user issues SCAN_WILD_CARD
    scan operation through sysfs parameter on a host with a lot of empty
    H:C:T:L entries.
    
    Avoiding the printk on -ENXIO matches the behavior of the other callback
    functions during scanning.
    
    Link: https://lore.kernel.org/r/20210726115402.1936-1-sreekanth.reddy@broadcom.com
    Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e25e7495d72649cb50b42865356bfe272b3a2a6d
Author: Ye Bin <yebin10@huawei.com>
Date:   Wed Jan 13 14:31:03 2021 +0800

    scsi: scsi_dh_rdac: Avoid crash during rdac_bus_attach()
    
    [ Upstream commit bc546c0c9abb3bb2fb46866b3d1e6ade9695a5f6 ]
    
    The following BUG_ON() was observed during RDAC scan:
    
    [595952.944297] kernel BUG at drivers/scsi/device_handler/scsi_dh_rdac.c:427!
    [595952.951143] Internal error: Oops - BUG: 0 [#1] SMP
    ......
    [595953.251065] Call trace:
    [595953.259054]  check_ownership+0xb0/0x118
    [595953.269794]  rdac_bus_attach+0x1f0/0x4b0
    [595953.273787]  scsi_dh_handler_attach+0x3c/0xe8
    [595953.278211]  scsi_dh_add_device+0xc4/0xe8
    [595953.282291]  scsi_sysfs_add_sdev+0x8c/0x2a8
    [595953.286544]  scsi_probe_and_add_lun+0x9fc/0xd00
    [595953.291142]  __scsi_scan_target+0x598/0x630
    [595953.295395]  scsi_scan_target+0x120/0x130
    [595953.299481]  fc_user_scan+0x1a0/0x1c0 [scsi_transport_fc]
    [595953.304944]  store_scan+0xb0/0x108
    [595953.308420]  dev_attr_store+0x44/0x60
    [595953.312160]  sysfs_kf_write+0x58/0x80
    [595953.315893]  kernfs_fop_write+0xe8/0x1f0
    [595953.319888]  __vfs_write+0x60/0x190
    [595953.323448]  vfs_write+0xac/0x1c0
    [595953.326836]  ksys_write+0x74/0xf0
    [595953.330221]  __arm64_sys_write+0x24/0x30
    
    Code is in check_ownership:
    
            list_for_each_entry_rcu(tmp, &h->ctlr->dh_list, node) {
                    /* h->sdev should always be valid */
                    BUG_ON(!tmp->sdev);
                    tmp->sdev->access_state = access_state;
            }
    
            rdac_bus_attach
                    initialize_controller
                            list_add_rcu(&h->node, &h->ctlr->dh_list);
                            h->sdev = sdev;
    
            rdac_bus_detach
                    list_del_rcu(&h->node);
                    h->sdev = NULL;
    
    Fix the race between rdac_bus_attach() and rdac_bus_detach() where h->sdev
    is NULL when processing the RDAC attach.
    
    Link: https://lore.kernel.org/r/20210113063103.2698953-1-yebin10@huawei.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 119f2748df9d956d19cc39d40dc07b1d265474ab
Author: Harshvardhan Jha <harshvardhan.jha@oracle.com>
Date:   Thu Jul 8 13:16:42 2021 +0530

    scsi: megaraid_mm: Fix end of loop tests for list_for_each_entry()
    
    [ Upstream commit 77541f78eadfe9fdb018a7b8b69f0f2af2cf4b82 ]
    
    The list_for_each_entry() iterator, "adapter" in this code, can never be
    NULL.  If we exit the loop without finding the correct adapter then
    "adapter" points invalid memory that is an offset from the list head.  This
    will eventually lead to memory corruption and presumably a kernel crash.
    
    Link: https://lore.kernel.org/r/20210708074642.23599-1-harshvardhan.jha@oracle.com
    Acked-by: Sumit Saxena <sumit.saxena@broadcom.com>
    Signed-off-by: Harshvardhan Jha <harshvardhan.jha@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c863d9535d0b444467c74aa7f52ca16ab91ee5ca
Author: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Date:   Sat Jul 17 22:00:21 2021 +0300

    dmaengine: of-dma: router_xlate to return -EPROBE_DEFER if controller is not yet available
    
    [ Upstream commit eda97cb095f2958bbad55684a6ca3e7d7af0176a ]
    
    If the router_xlate can not find the controller in the available DMA
    devices then it should return with -EPORBE_DEFER in a same way as the
    of_dma_request_slave_channel() does.
    
    The issue can be reproduced if the event router is registered before the
    DMA controller itself and a driver would request for a channel before the
    controller is registered.
    In of_dma_request_slave_channel():
    1. of_dma_find_controller() would find the dma_router
    2. ofdma->of_dma_xlate() would fail and returned NULL
    3. -ENODEV is returned as error code
    
    with this patch we would return in this case the correct -EPROBE_DEFER and
    the client can try to request the channel later.
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Link: https://lore.kernel.org/r/20210717190021.21897-1-peter.ujfalusi@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32e6ea21d636c0ca1604635b832148d20da79a66
Author: Dave Gerlach <d-gerlach@ti.com>
Date:   Fri Jul 16 09:07:30 2021 -0700

    ARM: dts: am43x-epos-evm: Reduce i2c0 bus speed for tps65218
    
    [ Upstream commit 20a6b3fd8e2e2c063b25fbf2ee74d86b898e5087 ]
    
    Based on the latest timing specifications for the TPS65218 from the data
    sheet, http://www.ti.com/lit/ds/symlink/tps65218.pdf, document SLDS206
    from November 2014, we must change the i2c bus speed to better fit within
    the minimum high SCL time required for proper i2c transfer.
    
    When running at 400khz, measurements show that SCL spends
    0.8125 uS/1.666 uS high/low which violates the requirement for minimum
    high period of SCL provided in datasheet Table 7.6 which is 1 uS.
    Switching to 100khz gives us 5 uS/5 uS high/low which both fall above
    the minimum given values for 100 khz, 4.0 uS/4.7 uS high/low.
    
    Without this patch occasionally a voltage set operation from the kernel
    will appear to have worked but the actual voltage reflected on the PMIC
    will not have updated, causing problems especially with cpufreq that may
    update to a higher OPP without actually raising the voltage on DCDC2,
    leading to a hang.
    
    Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a29364ca2742201d60ae5affea066f73ef9b14d
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Jul 6 20:45:21 2021 +0800

    dmaengine: usb-dmac: Fix PM reference leak in usb_dmac_probe()
    
    [ Upstream commit 1da569fa7ec8cb0591c74aa3050d4ea1397778b4 ]
    
    pm_runtime_get_sync will increment pm usage counter even it failed.
    Forgetting to putting operation will result in reference leak here.
    Fix it by moving the error_pm label above the pm_runtime_put() in
    the error path.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20210706124521.1371901-1-yukuai3@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b1868d2cc4b5da584c7143c93a32b437d5cb08d
Author: Adrian Larumbe <adrian.martinezlarumbe@imgtec.com>
Date:   Wed Jul 7 00:43:38 2021 +0100

    dmaengine: xilinx_dma: Fix read-after-free bug when terminating transfers
    
    [ Upstream commit 7dd2dd4ff9f3abda601f22b9d01441a0869d20d7 ]
    
    When user calls dmaengine_terminate_sync, the driver will clean up any
    remaining descriptors for all the pending or active transfers that had
    previously been submitted. However, this might happen whilst the tasklet is
    invoking the DMA callback for the last finished transfer, so by the time it
    returns and takes over the channel's spinlock, the list of completed
    descriptors it was traversing is no longer valid. This leads to a
    read-after-free situation.
    
    Fix it by signalling whether a user-triggered termination has happened by
    means of a boolean variable.
    
    Signed-off-by: Adrian Larumbe <adrian.martinezlarumbe@imgtec.com>
    Link: https://lore.kernel.org/r/20210706234338.7696-3-adrian.martinezlarumbe@imgtec.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08c613a2cb06c68ef4e7733e052af067b21e5dbb
Author: Jouni Malinen <jouni@codeaurora.org>
Date:   Mon Dec 14 19:21:18 2020 +0200

    ath9k: Postpone key cache entry deletion for TXQ frames reference it
    
    commit ca2848022c12789685d3fab3227df02b863f9696 upstream.
    
    Do not delete a key cache entry that is still being referenced by
    pending frames in TXQs. This avoids reuse of the key cache entry while a
    frame might still be transmitted using it.
    
    To avoid having to do any additional operations during the main TX path
    operations, track pending key cache entries in a new bitmap and check
    whether any pending entries can be deleted before every new key
    add/remove operation. Also clear any remaining entries when stopping the
    interface.
    
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201214172118.18100-6-jouni@codeaurora.org
    Cc: Pali Rohár <pali@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c5a966edd3c6eec4a9bdf698c1f27712d1781f0
Author: Jouni Malinen <jouni@codeaurora.org>
Date:   Mon Dec 14 19:21:17 2020 +0200

    ath: Modify ath_key_delete() to not need full key entry
    
    commit 144cd24dbc36650a51f7fe3bf1424a1432f1f480 upstream.
    
    tkip_keymap can be used internally to avoid the reference to key->cipher
    and with this, only the key index value itself is needed. This allows
    ath_key_delete() call to be postponed to be handled after the upper
    layer STA and key entry have already been removed. This is needed to
    make ath9k key cache management safer.
    
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201214172118.18100-5-jouni@codeaurora.org
    Cc: Pali Rohár <pali@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb924bfcecc90ca63ca76b5a10f192bd0e1bb35d
Author: Jouni Malinen <jouni@codeaurora.org>
Date:   Mon Dec 14 19:21:16 2020 +0200

    ath: Export ath_hw_keysetmac()
    
    commit d2d3e36498dd8e0c83ea99861fac5cf9e8671226 upstream.
    
    ath9k is going to use this for safer management of key cache entries.
    
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201214172118.18100-4-jouni@codeaurora.org
    Cc: Pali Rohár <pali@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2fd9d34210f34cd0ff5b33fa94e9fcc2a513cea
Author: Jouni Malinen <jouni@codeaurora.org>
Date:   Mon Dec 14 19:21:15 2020 +0200

    ath9k: Clear key cache explicitly on disabling hardware
    
    commit 73488cb2fa3bb1ef9f6cf0d757f76958bd4deaca upstream.
    
    Now that ath/key.c may not be explicitly clearing keys from the key
    cache, clear all key cache entries when disabling hardware to make sure
    no keys are left behind beyond this point.
    
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201214172118.18100-3-jouni@codeaurora.org
    Cc: Pali Rohár <pali@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd5815f023b89c9a28325d8a2a5f0779b57b7190
Author: Jouni Malinen <jouni@codeaurora.org>
Date:   Mon Dec 14 19:21:14 2020 +0200

    ath: Use safer key clearing with key cache entries
    
    commit 56c5485c9e444c2e85e11694b6c44f1338fc20fd upstream.
    
    It is possible for there to be pending frames in TXQs with a reference
    to the key cache entry that is being deleted. If such a key cache entry
    is cleared, those pending frame in TXQ might get transmitted without
    proper encryption. It is safer to leave the previously used key into the
    key cache in such cases. Instead, only clear the MAC address to prevent
    RX processing from using this key cache entry.
    
    This is needed in particularly in AP mode where the TXQs cannot be
    flushed on station disconnection. This change alone may not be able to
    address all cases where the key cache entry might get reused for other
    purposes immediately (the key cache entry should be released for reuse
    only once the TXQs do not have any remaining references to them), but
    this makes it less likely to get unprotected frames and the more
    complete changes may end up being significantly more complex.
    
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20201214172118.18100-2-jouni@codeaurora.org
    Cc: Pali Rohár <pali@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e829367f47218de04587c2df3c4cb5ef87e35648
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Jun 18 16:18:25 2021 +0200

    x86/fpu: Make init_fpstate correct with optimized XSAVE
    
    commit f9dfb5e390fab2df9f7944bb91e7705aba14cd26 upstream.
    
    The XSAVE init code initializes all enabled and supported components with
    XRSTOR(S) to init state. Then it XSAVEs the state of the components back
    into init_fpstate which is used in several places to fill in the init state
    of components.
    
    This works correctly with XSAVE, but not with XSAVEOPT and XSAVES because
    those use the init optimization and skip writing state of components which
    are in init state. So init_fpstate.xsave still contains all zeroes after
    this operation.
    
    There are two ways to solve that:
    
       1) Use XSAVE unconditionally, but that requires to reshuffle the buffer when
          XSAVES is enabled because XSAVES uses compacted format.
    
       2) Save the components which are known to have a non-zero init state by other
          means.
    
    Looking deeper, #2 is the right thing to do because all components the
    kernel supports have all-zeroes init state except the legacy features (FP,
    SSE). Those cannot be hard coded because the states are not identical on all
    CPUs, but they can be saved with FXSAVE which avoids all conditionals.
    
    Use FXSAVE to save the legacy FP/SSE components in init_fpstate along with
    a BUILD_BUG_ON() which reminds developers to validate that a newly added
    component has all zeroes init state. As a bonus remove the now unused
    copy_xregs_to_kernel_booting() crutch.
    
    The XSAVE and reshuffle method can still be implemented in the unlikely
    case that components are added which have a non-zero init state and no
    other means to save them. For now, FXSAVE is just simple and good enough.
    
      [ bp: Fix a typo or two in the text. ]
    
    Fixes: 6bad06b76892 ("x86, xsave: Use xsaveopt in context-switch path when supported")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20210618143444.587311343@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42f4312c0e8a225b5f1e3ed029509ef514f2157a
Author: Maxim Levitsky <mlevitsk@redhat.com>
Date:   Mon Aug 16 16:02:30 2021 +0200

    KVM: nSVM: avoid picking up unsupported bits from L2 in int_ctl (CVE-2021-3653)
    
    [ upstream commit 0f923e07124df069ba68d8bb12324398f4b6b709 ]
    
    * Invert the mask of bits that we pick from L2 in
      nested_vmcb02_prepare_control
    
    * Invert and explicitly use VIRQ related bits bitmask in svm_clear_vintr
    
    This fixes a security issue that allowed a malicious L1 to run L2 with
    AVIC enabled, which allowed the L2 to exploit the uninitialized and enabled
    AVIC to read/write the host physical memory at some offsets.
    
    Fixes: 3d6368ef580a ("KVM: SVM: Add VMRUN handler")
    Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 119d547cbf7c055ba8100309ad71910478092f24
Author: Maxim Levitsky <mlevitsk@redhat.com>
Date:   Mon Aug 16 16:02:37 2021 +0200

    KVM: nSVM: always intercept VMLOAD/VMSAVE when nested (CVE-2021-3656)
    
    [ upstream commit c7dfa4009965a9b2d7b329ee970eb8da0d32f0bc ]
    
    If L1 disables VMLOAD/VMSAVE intercepts, and doesn't enable
    Virtual VMLOAD/VMSAVE (currently not supported for the nested hypervisor),
    then VMLOAD/VMSAVE must operate on the L1 physical memory, which is only
    possible by making L0 intercept these instructions.
    
    Failure to do so allowed the nested guest to run VMLOAD/VMSAVE unintercepted,
    and thus read/write portions of the host physical memory.
    
    Fixes: 89c8a4984fc9 ("KVM: SVM: Enable Virtual VMLOAD VMSAVE feature")
    
    Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 11cad2a46103388a46f31ab69b3e0e152a08df9c
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Mar 26 15:09:42 2020 +0200

    mac80211: drop data frames without key on encrypted links
    
    commit a0761a301746ec2d92d7fcb82af69c0a6a4339aa upstream.
    
    If we know that we have an encrypted link (based on having had
    a key configured for TX in the past) then drop all data frames
    in the key selection handler if there's no key anymore.
    
    This fixes an issue with mac80211 internal TXQs - there we can
    buffer frames for an encrypted link, but then if the key is no
    longer there when they're dequeued, the frames are sent without
    encryption. This happens if a station is disconnected while the
    frames are still on the TXQ.
    
    Detecting that a link should be encrypted based on a first key
    having been configured for TX is fine as there are no use cases
    for a connection going from with encryption to no encryption.
    With extended key IDs, however, there is a case of having a key
    configured for only decryption, so we can't just trigger this
    behaviour on a key being configured.
    
    Cc: stable@vger.kernel.org
    Reported-by: Jouni Malinen <j@w1.fi>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Link: https://lore.kernel.org/r/iwlwifi.20200326150855.6865c7f28a14.I9fb1d911b064262d33e33dfba730cdeef83926ca@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [pali: Backported to 4.19 and older versions]
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a9449e9568808930e7d4d83c33e320329113a67
Author: Saeed Mirzamohammadi <saeed.mirzamohammadi@oracle.com>
Date:   Mon Aug 16 19:39:32 2021 +0800

    iommu/vt-d: Fix agaw for a supported 48 bit guest address width
    
    [ Upstream commit 327d5b2fee91c404a3956c324193892cf2cc9528 ]
    
    The IOMMU driver calculates the guest addressability for a DMA request
    based on the value of the mgaw reported from the IOMMU. However, this
    is a fused value and as mentioned in the spec, the guest width
    should be calculated based on the minimum of supported adjusted guest
    address width (SAGAW) and MGAW.
    
    This is from specification:
    "Guest addressability for a given DMA request is limited to the
    minimum of the value reported through this field and the adjusted
    guest address width of the corresponding page-table structure.
    (Adjusted guest address widths supported by hardware are reported
    through the SAGAW field)."
    
    This causes domain initialization to fail and following
    errors appear for EHCI PCI driver:
    
    [    2.486393] ehci-pci 0000:01:00.4: EHCI Host Controller
    [    2.486624] ehci-pci 0000:01:00.4: new USB bus registered, assigned bus
    number 1
    [    2.489127] ehci-pci 0000:01:00.4: DMAR: Allocating domain failed
    [    2.489350] ehci-pci 0000:01:00.4: DMAR: 32bit DMA uses non-identity
    mapping
    [    2.489359] ehci-pci 0000:01:00.4: can't setup: -12
    [    2.489531] ehci-pci 0000:01:00.4: USB bus 1 deregistered
    [    2.490023] ehci-pci 0000:01:00.4: init 0000:01:00.4 fail, -12
    [    2.490358] ehci-pci: probe of 0000:01:00.4 failed with error -12
    
    This issue happens when the value of the sagaw corresponds to a
    48-bit agaw. This fix updates the calculation of the agaw based on
    the minimum of IOMMU's sagaw value and MGAW.
    
    This issue happens on the code path of getting a private domain for a
    device. A private domain was needed when the domain of an iommu group
    couldn't meet the requirement of a device. The IOMMU core has been
    evolved to eliminate the need for private domain, hence this code path
    has alreay been removed from the upstream since commit 327d5b2fee91c
    ("iommu/vt-d: Allow 32bit devices to uses DMA domain"). Instead of back
    porting all patches that are required for removing the private domain,
    this simply fixes it in the affected stable kernel between v4.16 and v5.7.
    
    [baolu: The orignal patch could be found here
     https://lore.kernel.org/linux-iommu/20210412202736.70765-1-saeed.mirzamohammadi@oracle.com/.
     I added commit message according to Greg's comments at
     https://lore.kernel.org/linux-iommu/YHZ%2FT9x7Xjf1r6fI@kroah.com/.]
    
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Ashok Raj <ashok.raj@intel.com>
    Cc: stable@vger.kernel.org #v4.16+
    Signed-off-by: Saeed Mirzamohammadi <saeed.mirzamohammadi@oracle.com>
    Tested-by: Camille Lu <camille.lu@hpe.com>
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c47f8a185747dbf90728174b1a375c0542ca2bae
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Fri Jul 30 19:31:08 2021 -0700

    vmlinux.lds.h: Handle clang's module.{c,d}tor sections
    
    commit 848378812e40152abe9b9baf58ce2004f76fb988 upstream.
    
    A recent change in LLVM causes module_{c,d}tor sections to appear when
    CONFIG_K{A,C}SAN are enabled, which results in orphan section warnings
    because these are not handled anywhere:
    
    ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_ctor) is being placed in '.text.asan.module_ctor'
    ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_dtor) is being placed in '.text.asan.module_dtor'
    ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.tsan.module_ctor) is being placed in '.text.tsan.module_ctor'
    
    Fangrui explains: "the function asan.module_ctor has the SHF_GNU_RETAIN
    flag, so it is in a separate section even with -fno-function-sections
    (default)".
    
    Place them in the TEXT_TEXT section so that these technologies continue
    to work with the newer compiler versions. All of the KASAN and KCSAN
    KUnit tests continue to pass after this change.
    
    Cc: stable@vger.kernel.org
    Link: https://github.com/ClangBuiltLinux/linux/issues/1432
    Link: https://github.com/llvm/llvm-project/commit/7b789562244ee941b7bf2cefeb3fc08a59a01865
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Fangrui Song <maskray@google.com>
    Acked-by: Marco Elver <elver@google.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20210731023107.1932981-1-nathan@kernel.org
    [nc: Resolve conflict due to lack of cf68fffb66d60]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 153cc7c9dfefe646c8b2a74eb925b6620b915154
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 29 23:51:43 2021 +0200

    PCI/MSI: Enforce MSI[X] entry updates to be visible
    
    commit b9255a7cb51754e8d2645b65dd31805e282b4f3e upstream.
    
    Nothing enforces the posted writes to be visible when the function
    returns. Flush them even if the flush might be redundant when the entry is
    masked already as the unmask will flush as well. This is either setup or a
    rare affinity change event so the extra flush is not the end of the world.
    
    While this is more a theoretical issue especially the logic in the X86
    specific msi_set_affinity() function relies on the assumption that the
    update has reached the hardware when the function returns.
    
    Again, as this never has been enforced the Fixes tag refers to a commit in:
       git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
    
    Fixes: f036d4ea5fa7 ("[PATCH] ia32 Message Signalled Interrupt support")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210729222542.515188147@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b590b85fc91979a97cbb4ab1bcf888aa245cd5e3
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 29 23:51:42 2021 +0200

    PCI/MSI: Enforce that MSI-X table entry is masked for update
    
    commit da181dc974ad667579baece33c2c8d2d1e4558d5 upstream.
    
    The specification (PCIe r5.0, sec 6.1.4.5) states:
    
        For MSI-X, a function is permitted to cache Address and Data values
        from unmasked MSI-X Table entries. However, anytime software unmasks a
        currently masked MSI-X Table entry either by clearing its Mask bit or
        by clearing the Function Mask bit, the function must update any Address
        or Data values that it cached from that entry. If software changes the
        Address or Data value of an entry while the entry is unmasked, the
        result is undefined.
    
    The Linux kernel's MSI-X support never enforced that the entry is masked
    before the entry is modified hence the Fixes tag refers to a commit in:
          git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
    
    Enforce the entry to be masked across the update.
    
    There is no point in enforcing this to be handled at all possible call
    sites as this is just pointless code duplication and the common update
    function is the obvious place to enforce this.
    
    Fixes: f036d4ea5fa7 ("[PATCH] ia32 Message Signalled Interrupt support")
    Reported-by: Kevin Tian <kevin.tian@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210729222542.462096385@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b570884c868c12e3184627ce4b4a167e9d6f018
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 29 23:51:41 2021 +0200

    PCI/MSI: Mask all unused MSI-X entries
    
    commit 7d5ec3d3612396dc6d4b76366d20ab9fc06f399f upstream.
    
    When MSI-X is enabled the ordering of calls is:
    
      msix_map_region();
      msix_setup_entries();
      pci_msi_setup_msi_irqs();
      msix_program_entries();
    
    This has a few interesting issues:
    
     1) msix_setup_entries() allocates the MSI descriptors and initializes them
        except for the msi_desc:masked member which is left zero initialized.
    
     2) pci_msi_setup_msi_irqs() allocates the interrupt descriptors and sets
        up the MSI interrupts which ends up in pci_write_msi_msg() unless the
        interrupt chip provides its own irq_write_msi_msg() function.
    
     3) msix_program_entries() does not do what the name suggests. It solely
        updates the entries array (if not NULL) and initializes the masked
        member for each MSI descriptor by reading the hardware state and then
        masks the entry.
    
    Obviously this has some issues:
    
     1) The uninitialized masked member of msi_desc prevents the enforcement
        of masking the entry in pci_write_msi_msg() depending on the cached
        masked bit. Aside of that half initialized data is a NONO in general
    
     2) msix_program_entries() only ensures that the actually allocated entries
        are masked. This is wrong as experimentation with crash testing and
        crash kernel kexec has shown.
    
        This limited testing unearthed that when the production kernel had more
        entries in use and unmasked when it crashed and the crash kernel
        allocated a smaller amount of entries, then a full scan of all entries
        found unmasked entries which were in use in the production kernel.
    
        This is obviously a device or emulation issue as the device reset
        should mask all MSI-X table entries, but obviously that's just part
        of the paper specification.
    
    Cure this by:
    
     1) Masking all table entries in hardware
     2) Initializing msi_desc::masked in msix_setup_entries()
     3) Removing the mask dance in msix_program_entries()
     4) Renaming msix_program_entries() to msix_update_entries() to
        reflect the purpose of that function.
    
    As the masking of unused entries has never been done the Fixes tag refers
    to a commit in:
       git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
    
    Fixes: f036d4ea5fa7 ("[PATCH] ia32 Message Signalled Interrupt support")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210729222542.403833459@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c9534778d4cc2bd01e20d4dcffc55df0962aa12
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 29 23:51:47 2021 +0200

    PCI/MSI: Protect msi_desc::masked for multi-MSI
    
    commit 77e89afc25f30abd56e76a809ee2884d7c1b63ce upstream.
    
    Multi-MSI uses a single MSI descriptor and there is a single mask register
    when the device supports per vector masking. To avoid reading back the mask
    register the value is cached in the MSI descriptor and updates are done by
    clearing and setting bits in the cache and writing it to the device.
    
    But nothing protects msi_desc::masked and the mask register from being
    modified concurrently on two different CPUs for two different Linux
    interrupts which belong to the same multi-MSI descriptor.
    
    Add a lock to struct device and protect any operation on the mask and the
    mask register with it.
    
    This makes the update of msi_desc::masked unconditional, but there is no
    place which requires a modification of the hardware register without
    updating the masked cache.
    
    msi_mask_irq() is now an empty wrapper which will be cleaned up in follow
    up changes.
    
    The problem goes way back to the initial support of multi-MSI, but picking
    the commit which introduced the mask cache is a valid cut off point
    (2.6.30).
    
    Fixes: f2440d9acbe8 ("PCI MSI: Refactor interrupt masking code")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210729222542.726833414@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b36c30a9335db941423c05b49a8266a84a82f95
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 29 23:51:46 2021 +0200

    PCI/MSI: Use msi_mask_irq() in pci_msi_shutdown()
    
    commit d28d4ad2a1aef27458b3383725bb179beb8d015c upstream.
    
    No point in using the raw write function from shutdown. Preparatory change
    to introduce proper serialization for the msi_desc::masked cache.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210729222542.674391354@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5b223cd04706589e5e6840e2ab7c4f879323ed9
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 29 23:51:45 2021 +0200

    PCI/MSI: Correct misleading comments
    
    commit 689e6b5351573c38ccf92a0dd8b3e2c2241e4aff upstream.
    
    The comments about preserving the cached state in pci_msi[x]_shutdown() are
    misleading as the MSI descriptors are freed right after those functions
    return. So there is nothing to restore. Preparatory change.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210729222542.621609423@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22f4a36d086d74f7abe9c4eaf65204048cd84f9c
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 29 23:51:44 2021 +0200

    PCI/MSI: Do not set invalid bits in MSI mask
    
    commit 361fd37397f77578735907341579397d5bed0a2d upstream.
    
    msi_mask_irq() takes a mask and a flags argument. The mask argument is used
    to mask out bits from the cached mask and the flags argument to set bits.
    
    Some places invoke it with a flags argument which sets bits which are not
    used by the device, i.e. when the device supports up to 8 vectors a full
    unmask in some places sets the mask to 0xFFFFFF00. While devices probably
    do not care, it's still bad practice.
    
    Fixes: 7ba1930db02f ("PCI MSI: Unmask MSI if setup failed")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210729222542.568173099@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6aea847496c8c9a37a5df795c4fe42a0e5fcccc5
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 29 23:51:40 2021 +0200

    PCI/MSI: Enable and mask MSI-X early
    
    commit 438553958ba19296663c6d6583d208dfb6792830 upstream.
    
    The ordering of MSI-X enable in hardware is dysfunctional:
    
     1) MSI-X is disabled in the control register
     2) Various setup functions
     3) pci_msi_setup_msi_irqs() is invoked which ends up accessing
        the MSI-X table entries
     4) MSI-X is enabled and masked in the control register with the
        comment that enabling is required for some hardware to access
        the MSI-X table
    
    Step #4 obviously contradicts #3. The history of this is an issue with the
    NIU hardware. When #4 was introduced the table access actually happened in
    msix_program_entries() which was invoked after enabling and masking MSI-X.
    
    This was changed in commit d71d6432e105 ("PCI/MSI: Kill redundant call of
    irq_set_msi_desc() for MSI-X interrupts") which removed the table write
    from msix_program_entries().
    
    Interestingly enough nobody noticed and either NIU still works or it did
    not get any testing with a kernel 3.19 or later.
    
    Nevertheless this is inconsistent and there is no reason why MSI-X can't be
    enabled and masked in the control register early on, i.e. move step #4
    above to step #1. This preserves the NIU workaround and has no side effects
    on other hardware.
    
    Fixes: d71d6432e105 ("PCI/MSI: Kill redundant call of irq_set_msi_desc() for MSI-X interrupts")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Ashok Raj <ashok.raj@intel.com>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210729222542.344136412@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 504a4c1057151a1f1332fb3ce940134db8d6b885
Author: Bixuan Cui <cuibixuan@huawei.com>
Date:   Tue May 18 11:31:17 2021 +0800

    genirq/msi: Ensure deactivation on teardown
    
    commit dbbc93576e03fbe24b365fab0e901eb442237a8a upstream.
    
    msi_domain_alloc_irqs() invokes irq_domain_activate_irq(), but
    msi_domain_free_irqs() does not enforce deactivation before tearing down
    the interrupts.
    
    This happens when PCI/MSI interrupts are set up and never used before being
    torn down again, e.g. in error handling pathes. The only place which cleans
    that up is the error handling path in msi_domain_alloc_irqs().
    
    Move the cleanup from msi_domain_alloc_irqs() into msi_domain_free_irqs()
    to cure that.
    
    Fixes: f3b0946d629c ("genirq/msi: Make sure PCI MSIs are activated early")
    Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210518033117.78104-1-cuibixuan@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc656023d1691167b347804f06fc09e168aa9b99
Author: Babu Moger <Babu.Moger@amd.com>
Date:   Mon Aug 2 14:38:58 2021 -0500

    x86/resctrl: Fix default monitoring groups reporting
    
    commit 064855a69003c24bd6b473b367d364e418c57625 upstream.
    
    Creating a new sub monitoring group in the root /sys/fs/resctrl leads to
    getting the "Unavailable" value for mbm_total_bytes and mbm_local_bytes
    on the entire filesystem.
    
    Steps to reproduce:
    
      1. mount -t resctrl resctrl /sys/fs/resctrl/
    
      2. cd /sys/fs/resctrl/
    
      3. cat mon_data/mon_L3_00/mbm_total_bytes
         23189832
    
      4. Create sub monitor group:
      mkdir mon_groups/test1
    
      5. cat mon_data/mon_L3_00/mbm_total_bytes
         Unavailable
    
    When a new monitoring group is created, a new RMID is assigned to the
    new group. But the RMID is not active yet. When the events are read on
    the new RMID, it is expected to report the status as "Unavailable".
    
    When the user reads the events on the default monitoring group with
    multiple subgroups, the events on all subgroups are consolidated
    together. Currently, if any of the RMID reads report as "Unavailable",
    then everything will be reported as "Unavailable".
    
    Fix the issue by discarding the "Unavailable" reads and reporting all
    the successful RMID reads. This is not a problem on Intel systems as
    Intel reports 0 on Inactive RMIDs.
    
    Fixes: d89b7379015f ("x86/intel_rdt/cqm: Add mon_data")
    Reported-by: Paweł Szulik <pawel.szulik@intel.com>
    Signed-off-by: Babu Moger <Babu.Moger@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Reinette Chatre <reinette.chatre@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=213311
    Link: https://lkml.kernel.org/r/162793309296.9224.15871659871696482080.stgit@bmoger-ubuntu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 697658a61db4f3aa213d76336ccf30e66e6c44ca
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 29 23:51:49 2021 +0200

    x86/ioapic: Force affinity setup before startup
    
    commit 0c0e37dc11671384e53ba6ede53a4d91162a2cc5 upstream.
    
    The IO/APIC cannot handle interrupt affinity changes safely after startup
    other than from an interrupt handler. The startup sequence in the generic
    interrupt code violates that assumption.
    
    Mark the irq chip with the new IRQCHIP_AFFINITY_PRE_STARTUP flag so that
    the default interrupt setting happens before the interrupt is started up
    for the first time.
    
    Fixes: 18404756765c ("genirq: Expose default irq affinity mask (take 3)")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210729222542.832143400@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 354b210062b1e50ef284f97590011c2231316eaa
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 29 23:51:50 2021 +0200

    x86/msi: Force affinity setup before startup
    
    commit ff363f480e5997051dd1de949121ffda3b753741 upstream.
    
    The X86 MSI mechanism cannot handle interrupt affinity changes safely after
    startup other than from an interrupt handler, unless interrupt remapping is
    enabled. The startup sequence in the generic interrupt code violates that
    assumption.
    
    Mark the irq chips with the new IRQCHIP_AFFINITY_PRE_STARTUP flag so that
    the default interrupt setting happens before the interrupt is started up
    for the first time.
    
    While the interrupt remapping MSI chip does not require this, there is no
    point in treating it differently as this might spare an interrupt to a CPU
    which is not in the default affinity mask.
    
    For the non-remapping case go to the direct write path when the interrupt
    is not yet started similar to the not yet activated case.
    
    Fixes: 18404756765c ("genirq: Expose default irq affinity mask (take 3)")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210729222542.886722080@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cab824f67d7e8f68288d615929dec02607e473ad
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 29 23:51:48 2021 +0200

    genirq: Provide IRQCHIP_AFFINITY_PRE_STARTUP
    
    commit 826da771291fc25a428e871f9e7fb465e390f852 upstream.
    
    X86 IO/APIC and MSI interrupts (when used without interrupts remapping)
    require that the affinity setup on startup is done before the interrupt is
    enabled for the first time as the non-remapped operation mode cannot safely
    migrate enabled interrupts from arbitrary contexts. Provide a new irq chip
    flag which allows affected hardware to request this.
    
    This has to be opt-in because there have been reports in the past that some
    interrupt chips cannot handle affinity setting before startup.
    
    Fixes: 18404756765c ("genirq: Expose default irq affinity mask (take 3)")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210729222542.779791738@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b926fdfca71898027ee05aeaea9b9209fdc1f9f
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri Jul 30 17:01:46 2021 -0700

    x86/tools: Fix objdump version check again
    
    [ Upstream commit 839ad22f755132838f406751439363c07272ad87 ]
    
    Skip (omit) any version string info that is parenthesized.
    
    Warning: objdump version 15) is older than 2.19
    Warning: Skipping posttest.
    
    where 'objdump -v' says:
    GNU objdump (GNU Binutils; SUSE Linux Enterprise 15) 2.35.1.20201123-7.18
    
    Fixes: 8bee738bb1979 ("x86: Fix objdump version check in chkobjdump.awk for different formats.")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
    Link: https://lore.kernel.org/r/20210731000146.2720-1-rdunlap@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 04283ebd7622d72ce860d70e2e0ebb5fab0b55de
Author: Pu Lehui <pulehui@huawei.com>
Date:   Mon Aug 9 10:36:58 2021 +0800

    powerpc/kprobes: Fix kprobe Oops happens in booke
    
    [ Upstream commit 43e8f76006592cb1573a959aa287c45421066f9c ]
    
    When using kprobe on powerpc booke series processor, Oops happens
    as show bellow:
    
    / # echo "p:myprobe do_nanosleep" > /sys/kernel/debug/tracing/kprobe_events
    / # echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable
    / # sleep 1
    [   50.076730] Oops: Exception in kernel mode, sig: 5 [#1]
    [   50.077017] BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500
    [   50.077221] Modules linked in:
    [   50.077462] CPU: 0 PID: 77 Comm: sleep Not tainted 5.14.0-rc4-00022-g251a1524293d #21
    [   50.077887] NIP:  c0b9c4e0 LR: c00ebecc CTR: 00000000
    [   50.078067] REGS: c3883de0 TRAP: 0700   Not tainted (5.14.0-rc4-00022-g251a1524293d)
    [   50.078349] MSR:  00029000 <CE,EE,ME>  CR: 24000228  XER: 20000000
    [   50.078675]
    [   50.078675] GPR00: c00ebdf0 c3883e90 c313e300 c3883ea0 00000001 00000000 c3883ecc 00000001
    [   50.078675] GPR08: c100598c c00ea250 00000004 00000000 24000222 102490c2 bff4180c 101e60d4
    [   50.078675] GPR16: 00000000 102454ac 00000040 10240000 10241100 102410f8 10240000 00500000
    [   50.078675] GPR24: 00000002 00000000 c3883ea0 00000001 00000000 0000c350 3b9b8d50 00000000
    [   50.080151] NIP [c0b9c4e0] do_nanosleep+0x0/0x190
    [   50.080352] LR [c00ebecc] hrtimer_nanosleep+0x14c/0x1e0
    [   50.080638] Call Trace:
    [   50.080801] [c3883e90] [c00ebdf0] hrtimer_nanosleep+0x70/0x1e0 (unreliable)
    [   50.081110] [c3883f00] [c00ec004] sys_nanosleep_time32+0xa4/0x110
    [   50.081336] [c3883f40] [c001509c] ret_from_syscall+0x0/0x28
    [   50.081541] --- interrupt: c00 at 0x100a4d08
    [   50.081749] NIP:  100a4d08 LR: 101b5234 CTR: 00000003
    [   50.081931] REGS: c3883f50 TRAP: 0c00   Not tainted (5.14.0-rc4-00022-g251a1524293d)
    [   50.082183] MSR:  0002f902 <CE,EE,PR,FP,ME>  CR: 24000222  XER: 00000000
    [   50.082457]
    [   50.082457] GPR00: 000000a2 bf980040 1024b4d0 bf980084 bf980084 64000000 00555345 fefefeff
    [   50.082457] GPR08: 7f7f7f7f 101e0000 00000069 00000003 28000422 102490c2 bff4180c 101e60d4
    [   50.082457] GPR16: 00000000 102454ac 00000040 10240000 10241100 102410f8 10240000 00500000
    [   50.082457] GPR24: 00000002 bf9803f4 10240000 00000000 00000000 100039e0 00000000 102444e8
    [   50.083789] NIP [100a4d08] 0x100a4d08
    [   50.083917] LR [101b5234] 0x101b5234
    [   50.084042] --- interrupt: c00
    [   50.084238] Instruction dump:
    [   50.084483] 4bfffc40 60000000 60000000 60000000 9421fff0 39400402 914200c0 38210010
    [   50.084841] 4bfffc20 00000000 00000000 00000000 <7fe00008> 7c0802a6 7c892378 93c10048
    [   50.085487] ---[ end trace f6fffe98e2fa8f3e ]---
    [   50.085678]
    Trace/breakpoint trap
    
    There is no real mode for booke arch and the MMU translation is
    always on. The corresponding MSR_IS/MSR_DS bit in booke is used
    to switch the address space, but not for real mode judgment.
    
    Fixes: 21f8b2fa3ca5 ("powerpc/kprobes: Ignore traps that happened in real mode")
    Signed-off-by: Pu Lehui <pulehui@huawei.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210809023658.218915-1-pulehui@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a6013d42d256da2caeaa8fc0f050ac125d63e8d4
Author: Longpeng(Mike) <longpeng2@huawei.com>
Date:   Thu Aug 12 13:30:56 2021 +0800

    vsock/virtio: avoid potential deadlock when vsock device remove
    
    [ Upstream commit 49b0b6ffe20c5344f4173f3436298782a08da4f2 ]
    
    There's a potential deadlock case when remove the vsock device or
    process the RESET event:
    
      vsock_for_each_connected_socket:
          spin_lock_bh(&vsock_table_lock) ----------- (1)
          ...
              virtio_vsock_reset_sock:
                  lock_sock(sk) --------------------- (2)
          ...
          spin_unlock_bh(&vsock_table_lock)
    
    lock_sock() may do initiative schedule when the 'sk' is owned by
    other thread at the same time, we would receivce a warning message
    that "scheduling while atomic".
    
    Even worse, if the next task (selected by the scheduler) try to
    release a 'sk', it need to request vsock_table_lock and the deadlock
    occur, cause the system into softlockup state.
      Call trace:
       queued_spin_lock_slowpath
       vsock_remove_bound
       vsock_remove_sock
       virtio_transport_release
       __vsock_release
       vsock_release
       __sock_release
       sock_close
       __fput
       ____fput
    
    So we should not require sk_lock in this case, just like the behavior
    in vhost_vsock or vmci.
    
    Fixes: 0ea9e1d3a9e3 ("VSOCK: Introduce virtio_transport.ko")
    Cc: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Link: https://lore.kernel.org/r/20210812053056.1699-1-longpeng2@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 387635925cd0c4549d94815b9873a8b2a0c7e348
Author: Maximilian Heyne <mheyne@amazon.de>
Date:   Thu Aug 12 13:09:27 2021 +0000

    xen/events: Fix race in set_evtchn_to_irq
    
    [ Upstream commit 88ca2521bd5b4e8b83743c01a2d4cb09325b51e9 ]
    
    There is a TOCTOU issue in set_evtchn_to_irq. Rows in the evtchn_to_irq
    mapping are lazily allocated in this function. The check whether the row
    is already present and the row initialization is not synchronized. Two
    threads can at the same time allocate a new row for evtchn_to_irq and
    add the irq mapping to the their newly allocated row. One thread will
    overwrite what the other has set for evtchn_to_irq[row] and therefore
    the irq mapping is lost. This will trigger a BUG_ON later in
    bind_evtchn_to_cpu:
    
      INFO: pci 0000:1a:15.4: [1d0f:8061] type 00 class 0x010802
      INFO: nvme 0000:1a:12.1: enabling device (0000 -> 0002)
      INFO: nvme nvme77: 1/0/0 default/read/poll queues
      CRIT: kernel BUG at drivers/xen/events/events_base.c:427!
      WARN: invalid opcode: 0000 [#1] SMP NOPTI
      WARN: Workqueue: nvme-reset-wq nvme_reset_work [nvme]
      WARN: RIP: e030:bind_evtchn_to_cpu+0xc2/0xd0
      WARN: Call Trace:
      WARN:  set_affinity_irq+0x121/0x150
      WARN:  irq_do_set_affinity+0x37/0xe0
      WARN:  irq_setup_affinity+0xf6/0x170
      WARN:  irq_startup+0x64/0xe0
      WARN:  __setup_irq+0x69e/0x740
      WARN:  ? request_threaded_irq+0xad/0x160
      WARN:  request_threaded_irq+0xf5/0x160
      WARN:  ? nvme_timeout+0x2f0/0x2f0 [nvme]
      WARN:  pci_request_irq+0xa9/0xf0
      WARN:  ? pci_alloc_irq_vectors_affinity+0xbb/0x130
      WARN:  queue_request_irq+0x4c/0x70 [nvme]
      WARN:  nvme_reset_work+0x82d/0x1550 [nvme]
      WARN:  ? check_preempt_wakeup+0x14f/0x230
      WARN:  ? check_preempt_curr+0x29/0x80
      WARN:  ? nvme_irq_check+0x30/0x30 [nvme]
      WARN:  process_one_work+0x18e/0x3c0
      WARN:  worker_thread+0x30/0x3a0
      WARN:  ? process_one_work+0x3c0/0x3c0
      WARN:  kthread+0x113/0x130
      WARN:  ? kthread_park+0x90/0x90
      WARN:  ret_from_fork+0x3a/0x50
    
    This patch sets evtchn_to_irq rows via a cmpxchg operation so that they
    will be set only once. The row is now cleared before writing it to
    evtchn_to_irq in order to not create a race once the row is visible for
    other threads.
    
    While at it, do not require the page to be zeroed, because it will be
    overwritten with -1's in clear_evtchn_to_irq_row anyway.
    
    Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
    Fixes: d0b075ffeede ("xen/events: Refactor evtchn_to_irq array to be dynamically allocated")
    Link: https://lore.kernel.org/r/20210812130930.127134-1-mheyne@amazon.de
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec75ebd1645e3ca57c0d6bf8482c0ad775491703
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Aug 11 12:57:15 2021 -0700

    net: igmp: increase size of mr_ifc_count
    
    [ Upstream commit b69dd5b3780a7298bd893816a09da751bc0636f7 ]
    
    Some arches support cmpxchg() on 4-byte and 8-byte only.
    Increase mr_ifc_count width to 32bit to fix this problem.
    
    Fixes: 4a2b285e7e10 ("net: igmp: fix data-race in igmp_ifc_timer_expire()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20210811195715.3684218-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32b6627fec712fb75fbed272517c74814c00ccfc
Author: Neal Cardwell <ncardwell@google.com>
Date:   Tue Aug 10 22:40:56 2021 -0400

    tcp_bbr: fix u32 wrap bug in round logic if bbr_init() called after 2B packets
    
    [ Upstream commit 6de035fec045f8ae5ee5f3a02373a18b939e91fb ]
    
    Currently if BBR congestion control is initialized after more than 2B
    packets have been delivered, depending on the phase of the
    tp->delivered counter the tracking of BBR round trips can get stuck.
    
    The bug arises because if tp->delivered is between 2^31 and 2^32 at
    the time the BBR congestion control module is initialized, then the
    initialization of bbr->next_rtt_delivered to 0 will cause the logic to
    believe that the end of the round trip is still billions of packets in
    the future. More specifically, the following check will fail
    repeatedly:
    
      !before(rs->prior_delivered, bbr->next_rtt_delivered)
    
    and thus the connection will take up to 2B packets delivered before
    that check will pass and the connection will set:
    
      bbr->round_start = 1;
    
    This could cause many mechanisms in BBR to fail to trigger, for
    example bbr_check_full_bw_reached() would likely never exit STARTUP.
    
    This bug is 5 years old and has not been observed, and as a practical
    matter this would likely rarely trigger, since it would require
    transferring at least 2B packets, or likely more than 3 terabytes of
    data, before switching congestion control algorithms to BBR.
    
    This patch is a stable candidate for kernels as far back as v4.9,
    when tcp_bbr.c was added.
    
    Fixes: 0f8782ea1497 ("tcp_bbr: add BBR congestion control")
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Reviewed-by: Yuchung Cheng <ycheng@google.com>
    Reviewed-by: Kevin Yang <yyd@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20210811024056.235161-1-ncardwell@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f41237f60cb0202827432706c33faba3adadbfb5
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Aug 9 21:20:23 2021 +0800

    net: bridge: fix memleak in br_add_if()
    
    [ Upstream commit 519133debcc19f5c834e7e28480b60bdc234fe02 ]
    
    I got a memleak report:
    
    BUG: memory leak
    unreferenced object 0x607ee521a658 (size 240):
    comm "syz-executor.0", pid 955, jiffies 4294780569 (age 16.449s)
    hex dump (first 32 bytes, cpu 1):
    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:
    [<00000000d830ea5a>] br_multicast_add_port+0x1c2/0x300 net/bridge/br_multicast.c:1693
    [<00000000274d9a71>] new_nbp net/bridge/br_if.c:435 [inline]
    [<00000000274d9a71>] br_add_if+0x670/0x1740 net/bridge/br_if.c:611
    [<0000000012ce888e>] do_set_master net/core/rtnetlink.c:2513 [inline]
    [<0000000012ce888e>] do_set_master+0x1aa/0x210 net/core/rtnetlink.c:2487
    [<0000000099d1cafc>] __rtnl_newlink+0x1095/0x13e0 net/core/rtnetlink.c:3457
    [<00000000a01facc0>] rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3488
    [<00000000acc9186c>] rtnetlink_rcv_msg+0x369/0xa10 net/core/rtnetlink.c:5550
    [<00000000d4aabb9c>] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504
    [<00000000bc2e12a3>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
    [<00000000bc2e12a3>] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340
    [<00000000e4dc2d0e>] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929
    [<000000000d22c8b3>] sock_sendmsg_nosec net/socket.c:654 [inline]
    [<000000000d22c8b3>] sock_sendmsg+0x139/0x170 net/socket.c:674
    [<00000000e281417a>] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350
    [<00000000237aa2ab>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404
    [<000000004f2dc381>] __sys_sendmsg+0xd3/0x190 net/socket.c:2433
    [<0000000005feca6c>] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47
    [<000000007304477d>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    On error path of br_add_if(), p->mcast_stats allocated in
    new_nbp() need be freed, or it will be leaked.
    
    Fixes: 1080ab95e3c7 ("net: bridge: add support for IGMP/MLD stats and export them via netlink")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
    Link: https://lore.kernel.org/r/20210809132023.978546-1-yangyingliang@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 782e2706b091d157cde92bb6e97734120036cf32
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Aug 10 14:19:54 2021 +0300

    net: dsa: lan9303: fix broken backpressure in .port_fdb_dump
    
    [ Upstream commit ada2fee185d8145afb89056558bb59545b9dbdd0 ]
    
    rtnl_fdb_dump() has logic to split a dump of PF_BRIDGE neighbors into
    multiple netlink skbs if the buffer provided by user space is too small
    (one buffer will typically handle a few hundred FDB entries).
    
    When the current buffer becomes full, nlmsg_put() in
    dsa_slave_port_fdb_do_dump() returns -EMSGSIZE and DSA saves the index
    of the last dumped FDB entry, returns to rtnl_fdb_dump() up to that
    point, and then the dump resumes on the same port with a new skb, and
    FDB entries up to the saved index are simply skipped.
    
    Since dsa_slave_port_fdb_do_dump() is pointed to by the "cb" passed to
    drivers, then drivers must check for the -EMSGSIZE error code returned
    by it. Otherwise, when a netlink skb becomes full, DSA will no longer
    save newly dumped FDB entries to it, but the driver will continue
    dumping. So FDB entries will be missing from the dump.
    
    Fix the broken backpressure by propagating the "cb" return code and
    allow rtnl_fdb_dump() to restart the FDB dump with a new skb.
    
    Fixes: ab335349b852 ("net: dsa: lan9303: Add port_fast_age and port_fdb_dump methods")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb5db3106036f4e21a63c0c6b08db4b4f18f157c
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Aug 10 02:45:47 2021 -0700

    net: igmp: fix data-race in igmp_ifc_timer_expire()
    
    [ Upstream commit 4a2b285e7e103d4d6c6ed3e5052a0ff74a5d7f15 ]
    
    Fix the data-race reported by syzbot [1]
    Issue here is that igmp_ifc_timer_expire() can update in_dev->mr_ifc_count
    while another change just occured from another context.
    
    in_dev->mr_ifc_count is only 8bit wide, so the race had little
    consequences.
    
    [1]
    BUG: KCSAN: data-race in igmp_ifc_event / igmp_ifc_timer_expire
    
    write to 0xffff8881051e3062 of 1 bytes by task 12547 on cpu 0:
     igmp_ifc_event+0x1d5/0x290 net/ipv4/igmp.c:821
     igmp_group_added+0x462/0x490 net/ipv4/igmp.c:1356
     ____ip_mc_inc_group+0x3ff/0x500 net/ipv4/igmp.c:1461
     __ip_mc_join_group+0x24d/0x2c0 net/ipv4/igmp.c:2199
     ip_mc_join_group_ssm+0x20/0x30 net/ipv4/igmp.c:2218
     do_ip_setsockopt net/ipv4/ip_sockglue.c:1285 [inline]
     ip_setsockopt+0x1827/0x2a80 net/ipv4/ip_sockglue.c:1423
     tcp_setsockopt+0x8c/0xa0 net/ipv4/tcp.c:3657
     sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3362
     __sys_setsockopt+0x18f/0x200 net/socket.c:2159
     __do_sys_setsockopt net/socket.c:2170 [inline]
     __se_sys_setsockopt net/socket.c:2167 [inline]
     __x64_sys_setsockopt+0x62/0x70 net/socket.c:2167
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    read to 0xffff8881051e3062 of 1 bytes by interrupt on cpu 1:
     igmp_ifc_timer_expire+0x706/0xa30 net/ipv4/igmp.c:808
     call_timer_fn+0x2e/0x1d0 kernel/time/timer.c:1419
     expire_timers+0x135/0x250 kernel/time/timer.c:1464
     __run_timers+0x358/0x420 kernel/time/timer.c:1732
     run_timer_softirq+0x19/0x30 kernel/time/timer.c:1745
     __do_softirq+0x12c/0x26e kernel/softirq.c:558
     invoke_softirq kernel/softirq.c:432 [inline]
     __irq_exit_rcu+0x9a/0xb0 kernel/softirq.c:636
     sysvec_apic_timer_interrupt+0x69/0x80 arch/x86/kernel/apic/apic.c:1100
     asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638
     console_unlock+0x8e8/0xb30 kernel/printk/printk.c:2646
     vprintk_emit+0x125/0x3d0 kernel/printk/printk.c:2174
     vprintk_default+0x22/0x30 kernel/printk/printk.c:2185
     vprintk+0x15a/0x170 kernel/printk/printk_safe.c:392
     printk+0x62/0x87 kernel/printk/printk.c:2216
     selinux_netlink_send+0x399/0x400 security/selinux/hooks.c:6041
     security_netlink_send+0x42/0x90 security/security.c:2070
     netlink_sendmsg+0x59e/0x7c0 net/netlink/af_netlink.c:1919
     sock_sendmsg_nosec net/socket.c:703 [inline]
     sock_sendmsg net/socket.c:723 [inline]
     ____sys_sendmsg+0x360/0x4d0 net/socket.c:2392
     ___sys_sendmsg net/socket.c:2446 [inline]
     __sys_sendmsg+0x1ed/0x270 net/socket.c:2475
     __do_sys_sendmsg net/socket.c:2484 [inline]
     __se_sys_sendmsg net/socket.c:2482 [inline]
     __x64_sys_sendmsg+0x42/0x50 net/socket.c:2482
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    value changed: 0x01 -> 0x02
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 12539 Comm: syz-executor.1 Not tainted 5.14.0-rc4-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 <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7da72e2db1b36c3138aff542622123c030344254
Author: Takeshi Misawa <jeliantsurux@gmail.com>
Date:   Thu Aug 5 16:54:14 2021 +0900

    net: Fix memory leak in ieee802154_raw_deliver
    
    [ Upstream commit 1090340f7ee53e824fd4eef66a4855d548110c5b ]
    
    If IEEE-802.15.4-RAW is closed before receive skb, skb is leaked.
    Fix this, by freeing sk_receive_queue in sk->sk_destruct().
    
    syzbot report:
    BUG: memory leak
    unreferenced object 0xffff88810f644600 (size 232):
      comm "softirq", pid 0, jiffies 4294967032 (age 81.270s)
      hex dump (first 32 bytes):
        10 7d 4b 12 81 88 ff ff 10 7d 4b 12 81 88 ff ff  .}K......}K.....
        00 00 00 00 00 00 00 00 40 7c 4b 12 81 88 ff ff  ........@|K.....
      backtrace:
        [<ffffffff83651d4a>] skb_clone+0xaa/0x2b0 net/core/skbuff.c:1496
        [<ffffffff83fe1b80>] ieee802154_raw_deliver net/ieee802154/socket.c:369 [inline]
        [<ffffffff83fe1b80>] ieee802154_rcv+0x100/0x340 net/ieee802154/socket.c:1070
        [<ffffffff8367cc7a>] __netif_receive_skb_one_core+0x6a/0xa0 net/core/dev.c:5384
        [<ffffffff8367cd07>] __netif_receive_skb+0x27/0xa0 net/core/dev.c:5498
        [<ffffffff8367cdd9>] netif_receive_skb_internal net/core/dev.c:5603 [inline]
        [<ffffffff8367cdd9>] netif_receive_skb+0x59/0x260 net/core/dev.c:5662
        [<ffffffff83fe6302>] ieee802154_deliver_skb net/mac802154/rx.c:29 [inline]
        [<ffffffff83fe6302>] ieee802154_subif_frame net/mac802154/rx.c:102 [inline]
        [<ffffffff83fe6302>] __ieee802154_rx_handle_packet net/mac802154/rx.c:212 [inline]
        [<ffffffff83fe6302>] ieee802154_rx+0x612/0x620 net/mac802154/rx.c:284
        [<ffffffff83fe59a6>] ieee802154_tasklet_handler+0x86/0xa0 net/mac802154/main.c:35
        [<ffffffff81232aab>] tasklet_action_common.constprop.0+0x5b/0x100 kernel/softirq.c:557
        [<ffffffff846000bf>] __do_softirq+0xbf/0x2ab kernel/softirq.c:345
        [<ffffffff81232f4c>] do_softirq kernel/softirq.c:248 [inline]
        [<ffffffff81232f4c>] do_softirq+0x5c/0x80 kernel/softirq.c:235
        [<ffffffff81232fc1>] __local_bh_enable_ip+0x51/0x60 kernel/softirq.c:198
        [<ffffffff8367a9a4>] local_bh_enable include/linux/bottom_half.h:32 [inline]
        [<ffffffff8367a9a4>] rcu_read_unlock_bh include/linux/rcupdate.h:745 [inline]
        [<ffffffff8367a9a4>] __dev_queue_xmit+0x7f4/0xf60 net/core/dev.c:4221
        [<ffffffff83fe2db4>] raw_sendmsg+0x1f4/0x2b0 net/ieee802154/socket.c:295
        [<ffffffff8363af16>] sock_sendmsg_nosec net/socket.c:654 [inline]
        [<ffffffff8363af16>] sock_sendmsg+0x56/0x80 net/socket.c:674
        [<ffffffff8363deec>] __sys_sendto+0x15c/0x200 net/socket.c:1977
        [<ffffffff8363dfb6>] __do_sys_sendto net/socket.c:1989 [inline]
        [<ffffffff8363dfb6>] __se_sys_sendto net/socket.c:1985 [inline]
        [<ffffffff8363dfb6>] __x64_sys_sendto+0x26/0x30 net/socket.c:1985
    
    Fixes: 9ec767160357 ("net: add IEEE 802.15.4 socket family implementation")
    Reported-and-tested-by: syzbot+1f68113fa907bf0695a8@syzkaller.appspotmail.com
    Signed-off-by: Takeshi Misawa <jeliantsurux@gmail.com>
    Acked-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210805075414.GA15796@DESKTOP
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5518a26ef281ac4f38736723c26a502335ca6a97
Author: Roi Dayan <roid@nvidia.com>
Date:   Sun Aug 8 09:52:42 2021 +0300

    psample: Add a fwd declaration for skbuff
    
    [ Upstream commit beb7f2de5728b0bd2140a652fa51f6ad85d159f7 ]
    
    Without this there is a warning if source files include psample.h
    before skbuff.h or doesn't include it at all.
    
    Fixes: 6ae0a6286171 ("net: Introduce psample, a new genetlink channel for packet sampling")
    Signed-off-by: Roi Dayan <roid@nvidia.com>
    Link: https://lore.kernel.org/r/20210808065242.1522535-1-roid@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0bc8d39791e65d2812746b6a07df4e1d482b7e08
Author: Pali Rohár <pali@kernel.org>
Date:   Sat Aug 7 15:27:03 2021 +0200

    ppp: Fix generating ifname when empty IFLA_IFNAME is specified
    
    [ Upstream commit 2459dcb96bcba94c08d6861f8a050185ff301672 ]
    
    IFLA_IFNAME is nul-term string which means that IFLA_IFNAME buffer can be
    larger than length of string which contains.
    
    Function __rtnl_newlink() generates new own ifname if either IFLA_IFNAME
    was not specified at all or userspace passed empty nul-term string.
    
    It is expected that if userspace does not specify ifname for new ppp netdev
    then kernel generates one in format "ppp<id>" where id matches to the ppp
    unit id which can be later obtained by PPPIOCGUNIT ioctl.
    
    And it works in this way if IFLA_IFNAME is not specified at all. But it
    does not work when IFLA_IFNAME is specified with empty string.
    
    So fix this logic also for empty IFLA_IFNAME in ppp_nl_newlink() function
    and correctly generates ifname based on ppp unit identifier if userspace
    did not provided preferred ifname.
    
    Without this patch when IFLA_IFNAME was specified with empty string then
    kernel created a new ppp interface in format "ppp<id>" but id did not
    match ppp unit id returned by PPPIOCGUNIT ioctl. In this case id was some
    number generated by __rtnl_newlink() function.
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Fixes: bb8082f69138 ("ppp: build ifname using unit identifier for rtnl based devices")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f08a3b83463c66509b8a1034e5c416cfade1a5cd
Author: DENG Qingfang <dqfext@gmail.com>
Date:   Fri Aug 6 12:05:27 2021 +0800

    net: dsa: mt7530: add the missing RxUnicast MIB counter
    
    [ Upstream commit aff51c5da3208bd164381e1488998667269c6cf4 ]
    
    Add the missing RxUnicast counter.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Signed-off-by: DENG Qingfang <dqfext@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39edeccf57fef8f2ca62c649ace1fb138a965d98
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Thu Aug 5 17:11:05 2021 +0100

    ASoC: cs42l42: Fix LRCLK frame start edge
    
    [ Upstream commit 0c2f2ad4f16a58879463d0979a54293f8f296d6f ]
    
    An I2S frame starts on the falling edge of LRCLK so ASP_STP must
    be 0.
    
    At the same time, move other format settings in the same register
    from cs42l42_pll_config() to cs42l42_set_dai_fmt() where you'd
    expect to find them, and merge into a single write.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec")
    Link: https://lore.kernel.org/r/20210805161111.10410-2-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f0e1374e192da77884c7fb485a52b0dd9985289
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Tue Aug 3 17:08:34 2021 +0100

    ASoC: cs42l42: Remove duplicate control for WNF filter frequency
    
    [ Upstream commit 8b353bbeae20e2214c9d9d88bcb2fda4ba145d83 ]
    
    The driver was defining two ALSA controls that both change the same
    register field for the wind noise filter corner frequency. The filter
    response has two corners, at different frequencies, and the duplicate
    controls most likely were an attempt to be able to set the value using
    either of the frequencies.
    
    However, having two controls changing the same field can be problematic
    and it is unnecessary. Both frequencies are related to each other so
    setting one implies exactly what the other would be.
    
    Removing a control affects user-side code, but there is currently no
    known use of the removed control so it would be best to remove it now
    before it becomes a problem.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec")
    Link: https://lore.kernel.org/r/20210803160834.9005-2-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a203103eef3532a72927a3d7931c1de51c246d1
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Tue Aug 3 17:08:33 2021 +0100

    ASoC: cs42l42: Fix inversion of ADC Notch Switch control
    
    [ Upstream commit 30615bd21b4cc3c3bb5ae8bd70e2a915cc5f75c7 ]
    
    The underlying register field has inverted sense (0 = enabled) so
    the control definition must be marked as inverted.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec")
    Link: https://lore.kernel.org/r/20210803160834.9005-1-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b19d07068b25e1ee38dd6b59004392d85a899074
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Thu Jul 29 18:09:28 2021 +0100

    ASoC: cs42l42: Don't allow SND_SOC_DAIFMT_LEFT_J
    
    [ Upstream commit 64324bac750b84ca54711fb7d332132fcdb87293 ]
    
    The driver has no support for left-justified protocol so it should
    not have been allowing this to be passed to cs42l42_set_dai_fmt().
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec")
    Link: https://lore.kernel.org/r/20210729170929.6589-2-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 49f49cd9a389a7b7637bba26050cf2a1440a0a13
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Thu Jul 29 18:09:27 2021 +0100

    ASoC: cs42l42: Correct definition of ADC Volume control
    
    [ Upstream commit ee86f680ff4c9b406d49d4e22ddf10805b8a2137 ]
    
    The ADC volume is a signed 8-bit number with range -97 to +12,
    with -97 being mute. Use a SOC_SINGLE_S8_TLV() to define this
    and fix the DECLARE_TLV_DB_SCALE() to have the correct start and
    mute flag.
    
    Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec")
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20210729170929.6589-1-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 202e294bdf7d01476d18bd95b0019d5b447ec820
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Wed Jul 7 23:56:32 2021 +0800

    ieee802154: hwsim: fix GPF in hwsim_new_edge_nl
    
    [ Upstream commit 889d0e7dc68314a273627d89cbb60c09e1cc1c25 ]
    
    Both MAC802154_HWSIM_ATTR_RADIO_ID and MAC802154_HWSIM_ATTR_RADIO_EDGE
    must be present to fix GPF.
    
    Fixes: f25da51fdc38 ("ieee802154: hwsim: add replacement for fakelb")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Acked-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210707155633.1486603-1-mudongliangabcd@gmail.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5442be288efc063f6c21e71c57000e82753a2451
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Mon Jul 5 21:13:20 2021 +0800

    ieee802154: hwsim: fix GPF in hwsim_set_edge_lqi
    
    [ Upstream commit e9faf53c5a5d01f6f2a09ae28ec63a3bbd6f64fd ]
    
    Both MAC802154_HWSIM_ATTR_RADIO_ID and MAC802154_HWSIM_ATTR_RADIO_EDGE,
    MAC802154_HWSIM_EDGE_ATTR_ENDPOINT_ID and MAC802154_HWSIM_EDGE_ATTR_LQI
    must be present to fix GPF.
    
    Fixes: f25da51fdc38 ("ieee802154: hwsim: add replacement for fakelb")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Acked-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210705131321.217111-1-mudongliangabcd@gmail.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c39e22fd3f7ce3af64140f560ea63b0c986a46db
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Aug 11 11:53:37 2021 -0700

    ACPI: NFIT: Fix support for virtual SPA ranges
    
    commit b93dfa6bda4d4e88e5386490f2b277a26958f9d3 upstream.
    
    Fix the NFIT parsing code to treat a 0 index in a SPA Range Structure as
    a special case and not match Region Mapping Structures that use 0 to
    indicate that they are not mapped. Without this fix some platform BIOS
    descriptions of "virtual disk" ranges do not result in the pmem driver
    attaching to the range.
    
    Details:
    In addition to typical persistent memory ranges, the ACPI NFIT may also
    convey "virtual" ranges. These ranges are indicated by a UUID in the SPA
    Range Structure of UUID_VOLATILE_VIRTUAL_DISK, UUID_VOLATILE_VIRTUAL_CD,
    UUID_PERSISTENT_VIRTUAL_DISK, or UUID_PERSISTENT_VIRTUAL_CD. The
    critical difference between virtual ranges and UUID_PERSISTENT_MEMORY,
    is that virtual do not support associations with Region Mapping
    Structures.  For this reason the "index" value of virtual SPA Range
    Structures is allowed to be 0. If a platform BIOS decides to represent
    NVDIMMs with disconnected "Region Mapping Structures" (range-index ==
    0), the kernel may falsely associate them with standalone ranges where
    the "SPA Range Structure Index" is also zero. When this happens the
    driver may falsely require labels where "virtual disks" are expected to
    be label-less. I.e. "label-less" is where the namespace-range ==
    region-range and the pmem driver attaches with no user action to create
    a namespace.
    
    Cc: Jacek Zloch <jacek.zloch@intel.com>
    Cc: Lukasz Sobieraj <lukasz.sobieraj@intel.com>
    Cc: "Lee, Chun-Yi" <jlee@suse.com>
    Cc: <stable@vger.kernel.org>
    Fixes: c2f32acdf848 ("acpi, nfit: treat virtual ramdisk SPA as pmem region")
    Reported-by: Krzysztof Rusocki <krzysztof.rusocki@intel.com>
    Reported-by: Damian Bassa <damian.bassa@intel.com>
    Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
    Link: https://lore.kernel.org/r/162870796589.2521182.1240403310175570220.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 888ae2b85c6d0f03306f6ba82f656bde513b92cf
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jul 29 16:35:32 2021 +0200

    i2c: dev: zero out array used for i2c reads from userspace
    
    commit 86ff25ed6cd8240d18df58930bd8848b19fce308 upstream.
    
    If an i2c driver happens to not provide the full amount of data that a
    user asks for, it is possible that some uninitialized data could be sent
    to userspace.  While all in-kernel drivers look to be safe, just be sure
    by initializing the buffer to zero before it is passed to the i2c driver
    so that any future drivers will not have this issue.
    
    Also properly copy the amount of data recvieved to the userspace buffer,
    as pointed out by Dan Carpenter.
    
    Reported-by: Eric Dumazet <edumazet@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9703440e681c6696a7aa07767a565ca6195acc0b
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jul 28 13:23:50 2021 +0200

    ASoC: intel: atom: Fix reference to PCM buffer address
    
    commit 2e6b836312a477d647a7920b56810a5a25f6c856 upstream.
    
    PCM buffers might be allocated dynamically when the buffer
    preallocation failed or a larger buffer is requested, and it's not
    guaranteed that substream->dma_buffer points to the actually used
    buffer.  The address should be retrieved from runtime->dma_addr,
    instead of substream->dma_buffer (and shouldn't use virt_to_phys).
    
    Also, remove the line overriding runtime->dma_area superfluously,
    which was already set up at the PCM buffer allocation.
    
    Cc: Cezary Rojewski <cezary.rojewski@intel.com>
    Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20210728112353.6675-3-tiwai@suse.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2870da9189ddcdb1fa27c23556d8349f1d39d327
Author: Colin Ian King <colin.king@canonical.com>
Date:   Fri Jul 30 08:16:51 2021 +0100

    iio: adc: Fix incorrect exit of for-loop
    
    commit 5afc1540f13804a31bb704b763308e17688369c5 upstream.
    
    Currently the for-loop that scans for the optimial adc_period iterates
    through all the possible adc_period levels because the exit logic in
    the loop is inverted. I believe the comparison should be swapped and
    the continue replaced with a break to exit the loop at the correct
    point.
    
    Addresses-Coverity: ("Continue has no effect")
    Fixes: e08e19c331fb ("iio:adc: add iio driver for Palmas (twl6035/7) gpadc")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Link: https://lore.kernel.org/r/20210730071651.17394-1-colin.king@canonical.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13ca1daf27fd7d314114022e78ce2b7f87b84f24
Author: Chris Lesiak <chris.lesiak@licor.com>
Date:   Mon Jun 14 09:18:20 2021 -0500

    iio: humidity: hdc100x: Add margin to the conversion time
    
    commit 84edec86f449adea9ee0b4912a79ab8d9d65abb7 upstream.
    
    The datasheets have the following note for the conversion time
    specification: "This parameter is specified by design and/or
    characterization and it is not tested in production."
    
    Parts have been seen that require more time to do 14-bit conversions for
    the relative humidity channel.  The result is ENXIO due to the address
    phase of a transfer not getting an ACK.
    
    Delay an additional 1 ms per conversion to allow for additional margin.
    
    Fixes: 4839367d99e3 ("iio: humidity: add HDC100x support")
    Signed-off-by: Chris Lesiak <chris.lesiak@licor.com>
    Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
    Link: https://lore.kernel.org/r/20210614141820.2034827-1-chris.lesiak@licor.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>