commit 2ae73796985b582b79711dfed2941d190b571fb5
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Feb 22 12:56:00 2023 +0100

    Linux 5.10.169
    
    Link: https://lore.kernel.org/r/20230220133549.360169435@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e95381034519a8c5a3150f7b03f4664b1da651b2
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Fri Jan 27 10:40:14 2023 +0000

    nvmem: core: fix return value
    
    commit 0c4862b1c1465e473bc961a02765490578bf5c20 upstream.
    
    Dan Carpenter points out that the return code was not set in commit
    60c8b4aebd8e ("nvmem: core: fix cleanup after dev_set_name()"), but
    this is not the only issue - we also need to zero wp_gpio to prevent
    gpiod_put() being called on an error value.
    
    Fixes: 560181d3ace6 ("nvmem: core: fix cleanup after dev_set_name()")
    Cc: stable@vger.kernel.org
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20230127104015.23839-10-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c00867afe4efd5754e696d5c0a8d3f682efd7ffb
Author: Dan Carpenter <error27@gmail.com>
Date:   Mon Feb 6 16:18:32 2023 +0300

    net: sched: sch: Fix off by one in htb_activate_prios()
    
    commit 9cec2aaffe969f2a3e18b5ec105fc20bb908e475 upstream.
    
    The > needs be >= to prevent an out of bounds access.
    
    Fixes: de5ca4c3852f ("net: sched: sch: Bounds check priority")
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/Y+D+KN18FQI2DKLq@kili
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31167df7c21feb2a74d69a758a5226d83cbfe905
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Thu Feb 16 18:23:40 2023 +0200

    ASoC: SOF: Intel: hda-dai: fix possible stream_tag leak
    
    commit 1f810d2b6b2fbdc5279644d8b2c140b1f7c9d43d upstream.
    
    The HDaudio stream allocation is done first, and in a second step the
    LOSIDV parameter is programmed for the multi-link used by a codec.
    
    This leads to a possible stream_tag leak, e.g. if a DisplayAudio link
    is not used. This would happen when a non-Intel graphics card is used
    and userspace unconditionally uses the Intel Display Audio PCMs without
    checking if they are connected to a receiver with jack controls.
    
    We should first check that there is a valid multi-link entry to
    configure before allocating a stream_tag. This change aligns the
    dma_assign and dma_cleanup phases.
    
    Complements: b0cd60f3e9f5 ("ALSA/ASoC: hda: clarify bus_get_link() and bus_link_get() helpers")
    Link: https://github.com/thesofproject/linux/issues/4151
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Rander Wang <rander.wang@intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20230216162340.19480-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6af2872cc62549b2b034dcd02770ac52edf440ba
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Feb 9 23:25:49 2023 +0100

    alarmtimer: Prevent starvation by small intervals and SIG_IGN
    
    commit d125d1349abeb46945dc5e98f7824bf688266f13 upstream.
    
    syzbot reported a RCU stall which is caused by setting up an alarmtimer
    with a very small interval and ignoring the signal. The reproducer arms the
    alarm timer with a relative expiry of 8ns and an interval of 9ns. Not a
    problem per se, but that's an issue when the signal is ignored because then
    the timer is immediately rearmed because there is no way to delay that
    rearming to the signal delivery path.  See posix_timer_fn() and commit
    58229a189942 ("posix-timers: Prevent softirq starvation by small intervals
    and SIG_IGN") for details.
    
    The reproducer does not set SIG_IGN explicitely, but it sets up the timers
    signal with SIGCONT. That has the same effect as explicitely setting
    SIG_IGN for a signal as SIGCONT is ignored if there is no handler set and
    the task is not ptraced.
    
    The log clearly shows that:
    
       [pid  5102] --- SIGCONT {si_signo=SIGCONT, si_code=SI_TIMER, si_timerid=0, si_overrun=316014, si_int=0, si_ptr=NULL} ---
    
    It works because the tasks are traced and therefore the signal is queued so
    the tracer can see it, which delays the restart of the timer to the signal
    delivery path. But then the tracer is killed:
    
       [pid  5087] kill(-5102, SIGKILL <unfinished ...>
       ...
       ./strace-static-x86_64: Process 5107 detached
    
    and after it's gone the stall can be observed:
    
       syzkaller login: [   79.439102][    C0] hrtimer: interrupt took 68471 ns
       [  184.460538][    C1] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
       ...
       [  184.658237][    C1] rcu: Stack dump where RCU GP kthread last ran:
       [  184.664574][    C1] Sending NMI from CPU 1 to CPUs 0:
       [  184.669821][    C0] NMI backtrace for cpu 0
       [  184.669831][    C0] CPU: 0 PID: 5108 Comm: syz-executor192 Not tainted 6.2.0-rc6-next-20230203-syzkaller #0
       ...
       [  184.670036][    C0] Call Trace:
       [  184.670041][    C0]  <IRQ>
       [  184.670045][    C0]  alarmtimer_fired+0x327/0x670
    
    posix_timer_fn() prevents that by checking whether the interval for
    timers which have the signal ignored is smaller than a jiffie and
    artifically delay it by shifting the next expiry out by a jiffie. That's
    accurate vs. the overrun accounting, but slightly inaccurate
    vs. timer_gettimer(2).
    
    The comment in that function says what needs to be done and there was a fix
    available for the regular userspace induced SIG_IGN mechanism, but that did
    not work due to the implicit ignore for SIGCONT and similar signals. This
    needs to be worked on, but for now the only available workaround is to do
    exactly what posix_timer_fn() does:
    
    Increase the interval of self-rearming timers, which have their signal
    ignored, to at least a jiffie.
    
    Interestingly this has been fixed before via commit ff86bf0c65f1
    ("alarmtimer: Rate limit periodic intervals") already, but that fix got
    lost in a later rework.
    
    Reported-by: syzbot+b9564ba6e8e00694511b@syzkaller.appspotmail.com
    Fixes: f2c45807d399 ("alarmtimer: Switch over to generic set/get/rearm routine")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: John Stultz <jstultz@google.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/87k00q1no2.ffs@tglx
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6416c2108ba54d569e4c98d3b62ac78cb12e7107
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Feb 14 11:33:04 2023 +0100

    kvm: initialize all of the kvm_debugregs structure before sending it to userspace
    
    commit 2c10b61421a28e95a46ab489fd56c0f442ff6952 upstream.
    
    When calling the KVM_GET_DEBUGREGS ioctl, on some configurations, there
    might be some unitialized portions of the kvm_debugregs structure that
    could be copied to userspace.  Prevent this as is done in the other kvm
    ioctls, by setting the whole structure to 0 before copying anything into
    it.
    
    Bonus is that this reduces the lines of code as the explicit flag
    setting and reserved space zeroing out can be removed.
    
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: <x86@kernel.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: stable <stable@kernel.org>
    Reported-by: Xingyuan Mo <hdthky0@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Message-Id: <20230214103304.3689213-1-gregkh@linuxfoundation.org>
    Tested-by: Xingyuan Mo <hdthky0@gmail.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fe9950815e19051b7b8268b4d4c3ac286a741bf
Author: Pedro Tammela <pctammela@mojatatu.com>
Date:   Mon Feb 13 22:47:29 2023 -0300

    net/sched: tcindex: search key must be 16 bits
    
    [ Upstream commit 42018a322bd453e38b3ffee294982243e50a484f ]
    
    Syzkaller found an issue where a handle greater than 16 bits would trigger
    a null-ptr-deref in the imperfect hash area update.
    
    general protection fault, probably for non-canonical address
    0xdffffc0000000015: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af]
    CPU: 0 PID: 5070 Comm: syz-executor456 Not tainted
    6.2.0-rc7-syzkaller-00112-gc68f345b7c42 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine,
    BIOS Google 01/21/2023
    RIP: 0010:tcindex_set_parms+0x1a6a/0x2990 net/sched/cls_tcindex.c:509
    Code: 01 e9 e9 fe ff ff 4c 8b bd 28 fe ff ff e8 0e 57 7d f9 48 8d bb
    a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c
    02 00 0f 85 94 0c 00 00 48 8b 85 f8 fd ff ff 48 8b 9b a8 00
    RSP: 0018:ffffc90003d3ef88 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: 0000000000000015 RSI: ffffffff8803a102 RDI: 00000000000000a8
    RBP: ffffc90003d3f1d8 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000000 R12: ffff88801e2b10a8
    R13: dffffc0000000000 R14: 0000000000030000 R15: ffff888017b3be00
    FS: 00005555569af300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000056041c6d2000 CR3: 000000002bfca000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    tcindex_change+0x1ea/0x320 net/sched/cls_tcindex.c:572
    tc_new_tfilter+0x96e/0x2220 net/sched/cls_api.c:2155
    rtnetlink_rcv_msg+0x959/0xca0 net/core/rtnetlink.c:6132
    netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
    netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
    netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
    netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1942
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg+0xd3/0x120 net/socket.c:734
    ____sys_sendmsg+0x334/0x8c0 net/socket.c:2476
    ___sys_sendmsg+0x110/0x1b0 net/socket.c:2530
    __sys_sendmmsg+0x18f/0x460 net/socket.c:2616
    __do_sys_sendmmsg net/socket.c:2645 [inline]
    __se_sys_sendmmsg net/socket.c:2642 [inline]
    __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2642
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
    
    Fixes: ee059170b1f7 ("net/sched: tcindex: update imperfect hash filters respecting rcu")
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b452e20b95d7e0b09ee4a6f773e3ebe6764ff1cf
Author: Natalia Petrova <n.petrova@fintech.ru>
Date:   Thu Feb 9 09:28:33 2023 -0800

    i40e: Add checking for null for nlmsg_find_attr()
    
    [ Upstream commit 7fa0b526f865cb42aa33917fd02a92cb03746f4d ]
    
    The result of nlmsg_find_attr() 'br_spec' is dereferenced in
    nla_for_each_nested(), but it can take NULL value in nla_find() function,
    which will result in an error.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 51616018dd1b ("i40e: Add support for getlink, setlink ndo ops")
    Signed-off-by: Natalia Petrova <n.petrova@fintech.ru>
    Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Link: https://lore.kernel.org/r/20230209172833.3596034-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5dfa51dbfc123fb42ce3464a3124e5cd758e0c59
Author: Pedro Tammela <pctammela@mojatatu.com>
Date:   Fri Feb 10 17:08:25 2023 -0300

    net/sched: act_ctinfo: use percpu stats
    
    [ Upstream commit 21c167aa0ba943a7cac2f6969814f83bb701666b ]
    
    The tc action act_ctinfo was using shared stats, fix it to use percpu stats
    since bstats_update() must be called with locks or with a percpu pointer argument.
    
    tdc results:
    1..12
    ok 1 c826 - Add ctinfo action with default setting
    ok 2 0286 - Add ctinfo action with dscp
    ok 3 4938 - Add ctinfo action with valid cpmark and zone
    ok 4 7593 - Add ctinfo action with drop control
    ok 5 2961 - Replace ctinfo action zone and action control
    ok 6 e567 - Delete ctinfo action with valid index
    ok 7 6a91 - Delete ctinfo action with invalid index
    ok 8 5232 - List ctinfo actions
    ok 9 7702 - Flush ctinfo actions
    ok 10 3201 - Add ctinfo action with duplicate index
    ok 11 8295 - Add ctinfo action with invalid index
    ok 12 3964 - Replace ctinfo action with invalid goto_chain control
    
    Fixes: 24ec483cec98 ("net: sched: Introduce act_ctinfo action")
    Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
    Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
    Link: https://lore.kernel.org/r/20230210200824.444856-1-pctammela@mojatatu.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 015ea70d72c3449ab708024521bcdce7aad58aba
Author: Baowen Zheng <baowen.zheng@corigine.com>
Date:   Fri Dec 17 19:16:17 2021 +0100

    flow_offload: fill flags to action structure
    
    [ Upstream commit 40bd094d65fc9f83941b024cde7c24516f036879 ]
    
    Fill flags to action structure to allow user control if
    the action should be offloaded to hardware or not.
    
    Signed-off-by: Baowen Zheng <baowen.zheng@corigine.com>
    Signed-off-by: Louis Peens <louis.peens@corigine.com>
    Signed-off-by: Simon Horman <simon.horman@corigine.com>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 21c167aa0ba9 ("net/sched: act_ctinfo: use percpu stats")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1d76a844487490fbb2165953d5523ed9feb3cdc4
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Wed Feb 1 14:28:29 2023 -0800

    drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list
    
    [ Upstream commit d5a1224aa68c8b124a4c5c390186e571815ed390 ]
    
    The UNSLICE_UNIT_LEVEL_CLKGATE register programmed by this workaround
    has 'BUS' style reset, indicating that it does not lose its value on
    engine resets.  Furthermore, this register is part of the GT forcewake
    domain rather than the RENDER domain, so it should not be impacted by
    RCS engine resets.  As such, we should implement this on the GT
    workaround list rather than an engine list.
    
    Bspec: 19219
    Fixes: 3551ff928744 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()")
    Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
    Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230201222831.608281-2-matthew.d.roper@intel.com
    (cherry picked from commit 5f21dc07b52eb54a908e66f5d6e05a87bcb5b049)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 210e6011806acba0bc7ad57b1cf24be7ba76d836
Author: Raviteja Goud Talla <ravitejax.goud.talla@intel.com>
Date:   Fri Dec 3 20:26:03 2021 +0530

    drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()
    
    [ Upstream commit 67b858dd89932086ae0ee2d0ce4dd070a2c88bb3 ]
    
    Bspec page says "Reset: BUS", Accordingly moving w/a's:
    Wa_1407352427,Wa_1406680159 to proper function icl_gt_workarounds_init()
    Which will resolve guc enabling error
    
    v2:
      - Previous patch rev2 was created by email client which caused the
        Build failure, This v2 is to resolve the previous broken series
    
    Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
    Signed-off-by: Raviteja Goud Talla <ravitejax.goud.talla@intel.com>
    Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211203145603.4006937-1-ravitejax.goud.talla@intel.com
    Stable-dep-of: d5a1224aa68c ("drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ee5ed0126a2211f7174492da2ca2c29f43755c5
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Wed Feb 15 07:40:43 2023 +0900

    nilfs2: fix underflow in second superblock position calculations
    
    commit 99b9402a36f0799f25feee4465bfa4b8dfa74b4d upstream.
    
    Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second
    superblock, underflows when the argument device size is less than 4096
    bytes.  Therefore, when using this macro, it is necessary to check in
    advance that the device size is not less than a lower limit, or at least
    that underflow does not occur.
    
    The current nilfs2 implementation lacks this check, causing out-of-bound
    block access when mounting devices smaller than 4096 bytes:
    
     I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0
     phys_seg 1 prio class 2
     NILFS (loop0): unable to read secondary superblock (blocksize = 1024)
    
    In addition, when trying to resize the filesystem to a size below 4096
    bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number
    of segments to nilfs_sufile_resize(), corrupting parameters such as the
    number of segments in superblocks.  This causes excessive loop iterations
    in nilfs_sufile_resize() during a subsequent resize ioctl, causing
    semaphore ns_segctor_sem to block for a long time and hang the writer
    thread:
    
     INFO: task segctord:5067 blocked for more than 143 seconds.
          Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0
     "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
     task:segctord        state:D stack:23456 pid:5067  ppid:2
     flags:0x00004000
     Call Trace:
      <TASK>
      context_switch kernel/sched/core.c:5293 [inline]
      __schedule+0x1409/0x43f0 kernel/sched/core.c:6606
      schedule+0xc3/0x190 kernel/sched/core.c:6682
      rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190
      nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357
      nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]
      nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570
      kthread+0x270/0x300 kernel/kthread.c:376
      ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
      </TASK>
     ...
     Call Trace:
      <TASK>
      folio_mark_accessed+0x51c/0xf00 mm/swap.c:515
      __nilfs_get_page_block fs/nilfs2/page.c:42 [inline]
      nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61
      nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121
      nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176
      nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251
      nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]
      nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]
      nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777
      nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422
      nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]
      nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301
      ...
    
    This fixes these issues by inserting appropriate minimum device size
    checks or anti-underflow checks, depending on where the macro is used.
    
    Link: https://lkml.kernel.org/r/0000000000004e1dfa05f4a48e6b@google.com
    Link: https://lkml.kernel.org/r/20230214224043.24141-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: <syzbot+f0c4082ce5ebebdac63b@syzkaller.appspotmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7546fb3554df580e49b490c21a61dd3c38212571
Author: Guillaume Nault <gnault@redhat.com>
Date:   Wed Feb 8 18:14:03 2023 +0100

    ipv6: Fix tcp socket connection with DSCP.
    
    commit 8230680f36fd1525303d1117768c8852314c488c upstream.
    
    Take into account the IPV6_TCLASS socket option (DSCP) in
    tcp_v6_connect(). Otherwise fib6_rule_match() can't properly
    match the DSCP value, resulting in invalid route lookup.
    
    For example:
    
      ip route add unreachable table main 2001:db8::10/124
    
      ip route add table 100 2001:db8::10/124 dev eth0
      ip -6 rule add dsfield 0x04 table 100
    
      echo test | socat - TCP6:[2001:db8::11]:54321,ipv6-tclass=0x04
    
    Without this patch, socat fails at connect() time ("No route to host")
    because the fib-rule doesn't jump to table 100 and the lookup ends up
    being done in the main table.
    
    Fixes: 2cc67cc731d9 ("[IPV6] ROUTE: Routing by Traffic Class.")
    Signed-off-by: Guillaume Nault <gnault@redhat.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5337bb508ba2b9cb086472def6c0aa0c832ca9d7
Author: Guillaume Nault <gnault@redhat.com>
Date:   Wed Feb 8 18:13:59 2023 +0100

    ipv6: Fix datagram socket connection with DSCP.
    
    commit e010ae08c71fda8be3d6bda256837795a0b3ea41 upstream.
    
    Take into account the IPV6_TCLASS socket option (DSCP) in
    ip6_datagram_flow_key_init(). Otherwise fib6_rule_match() can't
    properly match the DSCP value, resulting in invalid route lookup.
    
    For example:
    
      ip route add unreachable table main 2001:db8::10/124
    
      ip route add table 100 2001:db8::10/124 dev eth0
      ip -6 rule add dsfield 0x04 table 100
    
      echo test | socat - UDP6:[2001:db8::11]:54321,ipv6-tclass=0x04
    
    Without this patch, socat fails at connect() time ("No route to host")
    because the fib-rule doesn't jump to table 100 and the lookup ends up
    being done in the main table.
    
    Fixes: 2cc67cc731d9 ("[IPV6] ROUTE: Routing by Traffic Class.")
    Signed-off-by: Guillaume Nault <gnault@redhat.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a4a5fd652dd6f84eb7ca1ac4cba682196e3ea7d
Author: Jason Xing <kernelxing@tencent.com>
Date:   Thu Feb 9 10:41:28 2023 +0800

    ixgbe: add double of VLAN header when computing the max MTU
    
    commit 0967bf837784a11c65d66060623a74e65211af0b upstream.
    
    Include the second VLAN HLEN into account when computing the maximum
    MTU size as other drivers do.
    
    Fixes: fabf1bce103a ("ixgbe: Prevent unsupported configurations with XDP")
    Signed-off-by: Jason Xing <kernelxing@tencent.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ff0fdba82298d1f456c685e24930da89703c0fb
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Mon Feb 13 22:53:55 2023 -0800

    net: mpls: fix stale pointer if allocation fails during device rename
    
    commit fda6c89fe3d9aca073495a664e1d5aea28cd4377 upstream.
    
    lianhui reports that when MPLS fails to register the sysctl table
    under new location (during device rename) the old pointers won't
    get overwritten and may be freed again (double free).
    
    Handle this gracefully. The best option would be unregistering
    the MPLS from the device completely on failure, but unfortunately
    mpls_ifdown() can fail. So failing fully is also unreliable.
    
    Another option is to register the new table first then only
    remove old one if the new one succeeds. That requires more
    code, changes order of notifications and two tables may be
    visible at the same time.
    
    sysctl point is not used in the rest of the code - set to NULL
    on failures and skip unregister if already NULL.
    
    Reported-by: lianhui tang <bluetlh@gmail.com>
    Fixes: 0fae3bf018d9 ("mpls: handle device renames for per-device sysctls")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dd914105a1e59df820edee3a408f480f65c3705
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Fri Feb 10 22:21:26 2023 +0200

    net: stmmac: Restrict warning on disabling DMA store and fwd mode
    
    commit 05d7623a892a9da62da0e714428e38f09e4a64d8 upstream.
    
    When setting 'snps,force_thresh_dma_mode' DT property, the following
    warning is always emitted, regardless the status of force_sf_dma_mode:
    
    dwmac-starfive 10020000.ethernet: force_sf_dma_mode is ignored if force_thresh_dma_mode is set.
    
    Do not print the rather misleading message when DMA store and forward
    mode is already disabled.
    
    Fixes: e2a240c7d3bc ("driver:net:stmmac: Disable DMA store and forward mode if platform data force_thresh_dma_mode is set.")
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Link: https://lore.kernel.org/r/20230210202126.877548-1-cristian.ciocaltea@collabora.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7eb8ebb5e83f8fdbac2eda1f81ed70048cbdb090
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Fri Feb 10 12:31:55 2023 -0500

    bnxt_en: Fix mqprio and XDP ring checking logic
    
    commit 2038cc592811209de20c4e094ca08bfb1e6fbc6c upstream.
    
    In bnxt_reserve_rings(), there is logic to check that the number of TX
    rings reserved is enough to cover all the mqprio TCs, but it fails to
    account for the TX XDP rings.  So the check will always fail if there
    are mqprio TCs and TX XDP rings.  As a result, the driver always fails
    to initialize after the XDP program is attached and the device will be
    brought down.  A subsequent ifconfig up will also fail because the
    number of TX rings is set to an inconsistent number.  Fix the check to
    properly account for TX XDP rings.  If the check fails, set the number
    of TX rings back to a consistent number after calling netdev_reset_tc().
    
    Fixes: 674f50a5b026 ("bnxt_en: Implement new method to reserve rings.")
    Reviewed-by: Hongguang Gao <hongguang.gao@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc7ca4871a92611d537b75a2a8e466106782bb31
Author: Johannes Zink <j.zink@pengutronix.de>
Date:   Fri Feb 10 15:39:37 2023 +0100

    net: stmmac: fix order of dwmac5 FlexPPS parametrization sequence
    
    commit 4562c65ec852067c6196abdcf2d925f08841dcbc upstream.
    
    So far changing the period by just setting new period values while
    running did not work.
    
    The order as indicated by the publicly available reference manual of the i.MX8MP [1]
    indicates a sequence:
    
     * initiate the programming sequence
     * set the values for PPS period and start time
     * start the pulse train generation.
    
    This is currently not used in dwmac5_flex_pps_config(), which instead does:
    
     * initiate the programming sequence and immediately start the pulse train generation
     * set the values for PPS period and start time
    
    This caused the period values written not to take effect until the FlexPPS output was
    disabled and re-enabled again.
    
    This patch fix the order and allows the period to be set immediately.
    
    [1] https://www.nxp.com/webapp/Download?colCode=IMX8MPRM
    
    Fixes: 9a8a02c9d46d ("net: stmmac: Add Flexible PPS support")
    Signed-off-by: Johannes Zink <j.zink@pengutronix.de>
    Link: https://lore.kernel.org/r/20230210143937.3427483-1-j.zink@pengutronix.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0f65ee0a3329eb4b94beaef0268633696e2d0c6
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Fri Feb 10 10:05:51 2023 +0800

    net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()
    
    commit 2fa28f5c6fcbfc794340684f36d2581b4f2d20b5 upstream.
    
    old_meter needs to be free after it is detached regardless of whether
    the new meter is successfully attached.
    
    Fixes: c7c4c44c9a95 ("net: openvswitch: expand the meters supported number")
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Acked-by: Eelco Chaudron <echaudro@redhat.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 525bdcb0838d19d918c7786151ee14661967a030
Author: Miko Larsson <mikoxyzzz@gmail.com>
Date:   Fri Feb 10 09:13:44 2023 +0100

    net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path
    
    commit c68f345b7c425b38656e1791a0486769a8797016 upstream.
    
    syzbot reported that act_len in kalmia_send_init_packet() is
    uninitialized when passing it to the first usb_bulk_msg error path. Jiri
    Pirko noted that it's pointless to pass it in the error path, and that
    the value that would be printed in the second error path would be the
    value of act_len from the first call to usb_bulk_msg.[1]
    
    With this in mind, let's just not pass act_len to the usb_bulk_msg error
    paths.
    
    1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/
    
    Fixes: d40261236e8e ("net/usb: Add Samsung Kalmia driver for Samsung GT-B3730")
    Reported-and-tested-by: syzbot+cd80c5ef5121bfe85b55@syzkaller.appspotmail.com
    Signed-off-by: Miko Larsson <mikoxyzzz@gmail.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d68bfa2205d249f705469d6799d0e081ac2b017
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu Feb 9 16:22:01 2023 -0800

    dccp/tcp: Avoid negative sk_forward_alloc by ipv6_pinfo.pktoptions.
    
    commit ca43ccf41224b023fc290073d5603a755fd12eed upstream.
    
    Eric Dumazet pointed out [0] that when we call skb_set_owner_r()
    for ipv6_pinfo.pktoptions, sk_rmem_schedule() has not been called,
    resulting in a negative sk_forward_alloc.
    
    We add a new helper which clones a skb and sets its owner only
    when sk_rmem_schedule() succeeds.
    
    Note that we move skb_set_owner_r() forward in (dccp|tcp)_v6_do_rcv()
    because tcp_send_synack() can make sk_forward_alloc negative before
    ipv6_opt_accepted() in the crossed SYN-ACK or self-connect() cases.
    
    [0]: https://lore.kernel.org/netdev/CANn89iK9oc20Jdi_41jb9URdF210r7d1Y-+uypbMSbOfY6jqrg@mail.gmail.com/
    
    Fixes: 323fbd0edf3f ("net: dccp: Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv()")
    Fixes: 3df80d9320bc ("[DCCP]: Introduce DCCPv6")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb8e9d8572d1d9df17272783ad8a84843ce559d4
Author: Pedro Tammela <pctammela@mojatatu.com>
Date:   Thu Feb 9 11:37:39 2023 -0300

    net/sched: tcindex: update imperfect hash filters respecting rcu
    
    commit ee059170b1f7e94e55fa6cadee544e176a6e59c2 upstream.
    
    The imperfect hash area can be updated while packets are traversing,
    which will cause a use-after-free when 'tcf_exts_exec()' is called
    with the destroyed tcf_ext.
    
    CPU 0:               CPU 1:
    tcindex_set_parms    tcindex_classify
    tcindex_lookup
                         tcindex_lookup
    tcf_exts_change
                         tcf_exts_exec [UAF]
    
    Stop operating on the shared area directly, by using a local copy,
    and update the filter with 'rcu_replace_pointer()'. Delete the old
    filter version only after a rcu grace period elapsed.
    
    Fixes: 9b0d4446b569 ("net: sched: avoid atomic swap in tcf_exts_change")
    Reported-by: valis <sec@valis.email>
    Suggested-by: valis <sec@valis.email>
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
    Link: https://lore.kernel.org/r/20230209143739.279867-1-pctammela@mojatatu.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 747a17e25aecb4ea8a66427058e0d2d2a25046ad
Author: Pietro Borrello <borrello@diag.uniroma1.it>
Date:   Thu Feb 9 12:13:05 2023 +0000

    sctp: sctp_sock_filter(): avoid list_entry() on possibly empty list
    
    commit a1221703a0f75a9d81748c516457e0fc76951496 upstream.
    
    Use list_is_first() to check whether tsp->asoc matches the first
    element of ep->asocs, as the list is not guaranteed to have an entry.
    
    Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
    Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
    Acked-by: Xin Long <lucien.xin@gmail.com>
    Link: https://lore.kernel.org/r/20230208-sctp-filter-v2-1-6e1f4017f326@diag.uniroma1.it
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5c51e0c3202820192db3f3809e072f3ca2b1177
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Wed Feb 8 10:16:37 2023 +0100

    net: bgmac: fix BCM5358 support by setting correct flags
    
    commit d61615c366a489646a1bfe5b33455f916762d5f4 upstream.
    
    Code blocks handling BCMA_CHIP_ID_BCM5357 and BCMA_CHIP_ID_BCM53572 were
    incorrectly unified. Chip package values are not unique and cannot be
    checked independently. They are meaningful only in a context of a given
    chip.
    
    Packages BCM5358 and BCM47188 share the same value but then belong to
    different chips. Code unification resulted in treating BCM5358 as
    BCM47188 and broke its initialization.
    
    Link: https://github.com/openwrt/openwrt/issues/8278
    Fixes: cb1b0f90acfe ("net: ethernet: bgmac: unify code of the same family")
    Cc: Jon Mason <jdmason@kudzu.us>
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20230208091637.16291-1-zajec5@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23974088fd6a57922abc80ac7d6219572cd48a4f
Author: Jason Xing <kernelxing@tencent.com>
Date:   Wed Feb 8 10:43:33 2023 +0800

    i40e: add double of VLAN header when computing the max MTU
    
    commit ce45ffb815e8e238f05de1630be3969b6bb15e4e upstream.
    
    Include the second VLAN HLEN into account when computing the maximum
    MTU size as other drivers do.
    
    Fixes: 0c8493d90b6b ("i40e: add XDP support for pass and drop actions")
    Signed-off-by: Jason Xing <kernelxing@tencent.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 152a5f32ac9ec497b514130b603e720ed61df575
Author: Jason Xing <kernelxing@tencent.com>
Date:   Wed Feb 8 10:43:32 2023 +0800

    ixgbe: allow to increase MTU to 3K with XDP enabled
    
    commit f9cd6a4418bac6a046ee78382423b1ae7565fb24 upstream.
    
    Recently I encountered one case where I cannot increase the MTU size
    directly from 1500 to a much bigger value with XDP enabled if the
    server is equipped with IXGBE card, which happened on thousands of
    servers in production environment. After applying the current patch,
    we can set the maximum MTU size to 3K.
    
    This patch follows the behavior of changing MTU as i40e/ice does.
    
    References:
    [1] commit 23b44513c3e6 ("ice: allow 3k MTU for XDP")
    [2] commit 0c8493d90b6b ("i40e: add XDP support for pass and drop actions")
    
    Fixes: fabf1bce103a ("ixgbe: Prevent unsupported configurations with XDP")
    Signed-off-by: Jason Xing <kernelxing@tencent.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a63392c19e95f631a7ed24a215727d059c1feeb
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Thu Feb 2 18:07:35 2023 -0800

    revert "squashfs: harden sanity check in squashfs_read_xattr_id_table"
    
    commit a5b21d8d791cd4db609d0bbcaa9e0c7e019888d1 upstream.
    
    This fix was nacked by Philip, for reasons identified in the email linked
    below.
    
    Link: https://lkml.kernel.org/r/68f15d67-8945-2728-1f17-5b53a80ec52d@squashfs.org.uk
    Fixes: 72e544b1b28325 ("squashfs: harden sanity check in squashfs_read_xattr_id_table")
    Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Cc: Fedor Pchelkin <pchelkin@ispras.ru>
    Cc: Phillip Lougher <phillip@squashfs.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2bf52ff159db37b5b60d34069464c00a1f54fd6
Author: Felix Riemann <felix.riemann@sma.de>
Date:   Fri Feb 10 13:36:44 2023 +0100

    net: Fix unwanted sign extension in netdev_stats_to_stats64()
    
    commit 9b55d3f0a69af649c62cbc2633e6d695bb3cc583 upstream.
    
    When converting net_device_stats to rtnl_link_stats64 sign extension
    is triggered on ILP32 machines as 6c1c509778 changed the previous
    "ulong -> u64" conversion to "long -> u64" by accessing the
    net_device_stats fields through a (signed) atomic_long_t.
    
    This causes for example the received bytes counter to jump to 16EiB after
    having received 2^31 bytes. Casting the atomic value to "unsigned long"
    beforehand converting it into u64 avoids this.
    
    Fixes: 6c1c5097781f ("net: add atomic_long_t to net_device_stats fields")
    Signed-off-by: Felix Riemann <felix.riemann@sma.de>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1933be146c96b5a707ce297eddfc3c49a9eec775
Author: Aaron Thompson <dev@aaront.org>
Date:   Tue Feb 7 08:21:51 2023 +0000

    Revert "mm: Always release pages to the buddy allocator in memblock_free_late()."
    
    commit 647037adcad00f2bab8828d3d41cd0553d41f3bd upstream.
    
    This reverts commit 115d9d77bb0f9152c60b6e8646369fa7f6167593.
    
    The pages being freed by memblock_free_late() have already been
    initialized, but if they are in the deferred init range,
    __free_one_page() might access nearby uninitialized pages when trying to
    coalesce buddies. This can, for example, trigger this BUG:
    
      BUG: unable to handle page fault for address: ffffe964c02580c8
      RIP: 0010:__list_del_entry_valid+0x3f/0x70
       <TASK>
       __free_one_page+0x139/0x410
       __free_pages_ok+0x21d/0x450
       memblock_free_late+0x8c/0xb9
       efi_free_boot_services+0x16b/0x25c
       efi_enter_virtual_mode+0x403/0x446
       start_kernel+0x678/0x714
       secondary_startup_64_no_verify+0xd2/0xdb
       </TASK>
    
    A proper fix will be more involved so revert this change for the time
    being.
    
    Fixes: 115d9d77bb0f ("mm: Always release pages to the buddy allocator in memblock_free_late().")
    Signed-off-by: Aaron Thompson <dev@aaront.org>
    Link: https://lore.kernel.org/r/20230207082151.1303-1-dev@aaront.org
    Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9662320238b9903e691958add64f4125615a143a
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date:   Wed Feb 15 17:35:42 2023 -0800

    hugetlb: check for undefined shift on 32 bit architectures
    
    commit ec4288fe63966b26d53907212ecd05dfa81dd2cc upstream.
    
    Users can specify the hugetlb page size in the mmap, shmget and
    memfd_create system calls.  This is done by using 6 bits within the flags
    argument to encode the base-2 logarithm of the desired page size.  The
    routine hstate_sizelog() uses the log2 value to find the corresponding
    hugetlb hstate structure.  Converting the log2 value (page_size_log) to
    potential hugetlb page size is the simple statement:
    
            1UL << page_size_log
    
    Because only 6 bits are used for page_size_log, the left shift can not be
    greater than 63.  This is fine on 64 bit architectures where a long is 64
    bits.  However, if a value greater than 31 is passed on a 32 bit
    architecture (where long is 32 bits) the shift will result in undefined
    behavior.  This was generally not an issue as the result of the undefined
    shift had to exactly match hugetlb page size to proceed.
    
    Recent improvements in runtime checking have resulted in this undefined
    behavior throwing errors such as reported below.
    
    Fix by comparing page_size_log to BITS_PER_LONG before doing shift.
    
    Link: https://lkml.kernel.org/r/20230216013542.138708-1-mike.kravetz@oracle.com
    Link: https://lore.kernel.org/lkml/CA+G9fYuei_Tr-vN9GS7SfFyU1y9hNysnf=PB7kT0=yv4MiPgVg@mail.gmail.com/
    Fixes: 42d7395feb56 ("mm: support more pagesizes for MAP_HUGETLB/SHM_HUGETLB")
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Reviewed-by: Jesper Juhl <jesperjuhl76@gmail.com>
    Acked-by: Muchun Song <songmuchun@bytedance.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Cc: Anders Roxell <anders.roxell@linaro.org>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Sasha Levin <sashal@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec9c7aa08819f976b2492fa63c41b5712d2924b5
Author: Munehisa Kamata <kamatam@amazon.com>
Date:   Tue Feb 14 13:27:05 2023 -0800

    sched/psi: Fix use-after-free in ep_remove_wait_queue()
    
    commit c2dbe32d5db5c4ead121cf86dabd5ab691fb47fe upstream.
    
    If a non-root cgroup gets removed when there is a thread that registered
    trigger and is polling on a pressure file within the cgroup, the polling
    waitqueue gets freed in the following path:
    
     do_rmdir
       cgroup_rmdir
         kernfs_drain_open_files
           cgroup_file_release
             cgroup_pressure_release
               psi_trigger_destroy
    
    However, the polling thread still has a reference to the pressure file and
    will access the freed waitqueue when the file is closed or upon exit:
    
     fput
       ep_eventpoll_release
         ep_free
           ep_remove_wait_queue
             remove_wait_queue
    
    This results in use-after-free as pasted below.
    
    The fundamental problem here is that cgroup_file_release() (and
    consequently waitqueue's lifetime) is not tied to the file's real lifetime.
    Using wake_up_pollfree() here might be less than ideal, but it is in line
    with the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()")
    since the waitqueue's lifetime is not tied to file's one and can be
    considered as another special case. While this would be fixable by somehow
    making cgroup_file_release() be tied to the fput(), it would require
    sizable refactoring at cgroups or higher layer which might be more
    justifiable if we identify more cases like this.
    
      BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0
      Write of size 4 at addr ffff88810e625328 by task a.out/4404
    
            CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38
            Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017
            Call Trace:
            <TASK>
            dump_stack_lvl+0x73/0xa0
            print_report+0x16c/0x4e0
            kasan_report+0xc3/0xf0
            kasan_check_range+0x2d2/0x310
            _raw_spin_lock_irqsave+0x60/0xc0
            remove_wait_queue+0x1a/0xa0
            ep_free+0x12c/0x170
            ep_eventpoll_release+0x26/0x30
            __fput+0x202/0x400
            task_work_run+0x11d/0x170
            do_exit+0x495/0x1130
            do_group_exit+0x100/0x100
            get_signal+0xd67/0xde0
            arch_do_signal_or_restart+0x2a/0x2b0
            exit_to_user_mode_prepare+0x94/0x100
            syscall_exit_to_user_mode+0x20/0x40
            do_syscall_64+0x52/0x90
            entry_SYSCALL_64_after_hwframe+0x63/0xcd
            </TASK>
    
     Allocated by task 4404:
    
            kasan_set_track+0x3d/0x60
            __kasan_kmalloc+0x85/0x90
            psi_trigger_create+0x113/0x3e0
            pressure_write+0x146/0x2e0
            cgroup_file_write+0x11c/0x250
            kernfs_fop_write_iter+0x186/0x220
            vfs_write+0x3d8/0x5c0
            ksys_write+0x90/0x110
            do_syscall_64+0x43/0x90
            entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
     Freed by task 4407:
    
            kasan_set_track+0x3d/0x60
            kasan_save_free_info+0x27/0x40
            ____kasan_slab_free+0x11d/0x170
            slab_free_freelist_hook+0x87/0x150
            __kmem_cache_free+0xcb/0x180
            psi_trigger_destroy+0x2e8/0x310
            cgroup_file_release+0x4f/0xb0
            kernfs_drain_open_files+0x165/0x1f0
            kernfs_drain+0x162/0x1a0
            __kernfs_remove+0x1fb/0x310
            kernfs_remove_by_name_ns+0x95/0xe0
            cgroup_addrm_files+0x67f/0x700
            cgroup_destroy_locked+0x283/0x3c0
            cgroup_rmdir+0x29/0x100
            kernfs_iop_rmdir+0xd1/0x140
            vfs_rmdir+0xfe/0x240
            do_rmdir+0x13d/0x280
            __x64_sys_rmdir+0x2c/0x30
            do_syscall_64+0x43/0x90
            entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: 0e94682b73bf ("psi: introduce psi monitor")
    Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
    Signed-off-by: Mengchi Cheng <mengcc@amazon.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Suren Baghdasaryan <surenb@google.com>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/lkml/20230106224859.4123476-1-kamatam@amazon.com/
    Link: https://lore.kernel.org/r/20230214212705.4058045-1-kamatam@amazon.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ed5c147220fc205bb8a33ed36facc56ad6f3fd2
Author: Kailang Yang <kailang@realtek.com>
Date:   Mon Feb 13 14:54:22 2023 +0800

    ALSA: hda/realtek - fixed wrong gpio assigned
    
    commit 2bdccfd290d421b50df4ec6a68d832dad1310748 upstream.
    
    GPIO2 PIN use for output. Mask Dir and Data need to assign for 0x4. Not 0x3.
    This fixed was for Lenovo Desktop(0x17aa1056). GPIO2 use for AMP enable.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/8d02bb9ac8134f878cd08607fdf088fd@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59d5c80ce538e64074e0f6089d94bb9928938a8a
Author: Bo Liu <bo.liu@senarytech.com>
Date:   Thu Feb 9 10:13:48 2023 +0800

    ALSA: hda/conexant: add a new hda codec SN6180
    
    commit 18d7e16c917a08f08778ecf2b780d63648d5d923 upstream.
    
    The current kernel does not support the SN6180 codec chip.
    Add the SN6180 codec configuration item to kernel.
    
    Signed-off-by: Bo Liu <bo.liu@senarytech.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1675908828-1012-1-git-send-email-bo.liu@senarytech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b3edcb24bd81b3b2e3dac89f4733bfd47d283be
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Jan 31 09:38:35 2023 +0800

    mmc: mmc_spi: fix error handling in mmc_spi_probe()
    
    commit cf4c9d2ac1e42c7d18b921bec39486896645b714 upstream.
    
    If mmc_add_host() fails, it doesn't need to call mmc_remove_host(),
    or it will cause null-ptr-deref, because of deleting a not added
    device in mmc_remove_host().
    
    To fix this, goto label 'fail_glue_init', if mmc_add_host() fails,
    and change the label 'fail_add_host' to 'fail_gpiod_request'.
    
    Fixes: 15a0580ced08 ("mmc_spi host driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Cc:stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230131013835.3564011-1-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30716d9f0fa1766e522cf24c8a456244e4fc9931
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Jan 30 20:58:08 2023 +0800

    mmc: sdio: fix possible resource leaks in some error paths
    
    commit 605d9fb9556f8f5fb4566f4df1480f280f308ded upstream.
    
    If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can
    not release the resources, because the sdio function is not presented
    in these two cases, it won't call of_node_put() or put_device().
    
    To fix these leaks, make sdio_func_present() only control whether
    device_del() needs to be called or not, then always call of_node_put()
    and put_device().
    
    In error case in sdio_init_func(), the reference of 'card->dev' is
    not get, to avoid redundant put in sdio_free_func_cis(), move the
    get_device() to sdio_alloc_func() and put_device() to sdio_release_func(),
    it can keep the get/put function be balanced.
    
    Without this patch, while doing fault inject test, it can get the
    following leak reports, after this fix, the leak is gone.
    
    unreferenced object 0xffff888112514000 (size 2048):
      comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s)
      hex dump (first 32 bytes):
        00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff  ..o.....`X......
        10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff  .@Q......@Q.....
      backtrace:
        [<000000009e5931da>] kmalloc_trace+0x21/0x110
        [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core]
        [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core]
        [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]
        [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
    
    unreferenced object 0xffff888112511000 (size 2048):
      comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s)
      hex dump (first 32 bytes):
        00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff  .@Q......X......
        10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff  ..Q.......Q.....
      backtrace:
        [<000000009e5931da>] kmalloc_trace+0x21/0x110
        [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core]
        [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]
        [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
    
    Fixes: 3d10a1ba0d37 ("sdio: fix reference counting in sdio_remove_func()")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230130125808.3471254-1-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73ad25c50d3c3eba6ea4c6735a585c4613eae537
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Tue Jan 31 21:02:28 2023 +0000

    mmc: jz4740: Work around bug on JZ4760(B)
    
    commit 3f18c5046e633cc4bbad396b74c05d46d353033d upstream.
    
    On JZ4760 and JZ4760B, SD cards fail to run if the maximum clock
    rate is set to 50 MHz, even though the controller officially does
    support it.
    
    Until the actual bug is found and fixed, limit the maximum clock rate to
    24 MHz.
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230131210229.68129-1-paul@crapouillou.net
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eaba3f9b672c3a3f820da8ee9584b9520674eafa
Author: Florian Westphal <fw@strlen.de>
Date:   Sat Aug 20 17:54:06 2022 +0200

    netfilter: nft_tproxy: restrict to prerouting hook
    
    commit 18bbc3213383a82b05383827f4b1b882e3f0a5a5 upstream.
    
    TPROXY is only allowed from prerouting, but nft_tproxy doesn't check this.
    This fixes a crash (null dereference) when using tproxy from e.g. output.
    
    Fixes: 4ed8eb6570a4 ("netfilter: nf_tables: Add native tproxy support")
    Reported-by: Shell Chen <xierch@gmail.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Qingfang DENG <dqfext@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6618b0dcf265975555e3eb24183e2a9e9b1c947c
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Mon Oct 17 17:06:39 2022 +0200

    ovl: remove privs in ovl_fallocate()
    
    commit 23a8ce16419a3066829ad4a8b7032a75817af65b upstream.
    
    Underlying fs doesn't remove privs because fallocate is called with
    privileged mounter credentials.
    
    This fixes some failure in fstests generic/683..687.
    
    Fixes: aab8848cee5e ("ovl: add ovl_fallocate()")
    Acked-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6f94837d92f0f5f94700589bab6d880009dfc22
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Mon Oct 17 17:06:38 2022 +0200

    ovl: remove privs in ovl_copyfile()
    
    commit b306e90ffabdaa7e3b3350dbcd19b7663e71ab17 upstream.
    
    Underlying fs doesn't remove privs because copy_range/remap_range are
    called with privileged mounter credentials.
    
    This fixes some failures in fstest generic/673.
    
    Fixes: 8ede205541ff ("ovl: add reflink/copyfile/dedup support")
    Acked-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 645df4047bd67e368c5fe9783a115916c4128c1d
Author: Sumanth Korikkar <sumanthk@linux.ibm.com>
Date:   Wed Feb 15 15:13:24 2023 +0100

    s390/signal: fix endless loop in do_signal
    
    No upstream commit exists: the problem addressed here is that 'commit
    75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")' was backported
    to 5.10. This commit is broken, but nobody noticed upstream, since
    shortly after s390 converted to generic entry with 'commit 56e62a737028
    ("s390: convert to generic entry")', which implicitly fixed the problem
    outlined below.
    
    Thread flag is set to TIF_NOTIFY_SIGNAL for io_uring work.  The io work
    user or syscall calls do_signal when either one of the TIF_SIGPENDING or
    TIF_NOTIFY_SIGNAL flag is set.  However, do_signal does consider only
    TIF_SIGPENDING signal and ignores TIF_NOTIFY_SIGNAL condition.  This
    means get_signal is never invoked  for TIF_NOTIFY_SIGNAL and hence the
    flag is not cleared, which results in an endless do_signal loop.
    
    Reference: 'commit 788d0824269b ("io_uring: import 5.15-stable io_uring")'
    Fixes: 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")
    Cc: stable@vger.kernel.org  # 5.10.162
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Acked-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c261f798f7baa8080cf0214081d43d5f86bb073f
Author: Seth Jenkins <sethjenkins@google.com>
Date:   Tue Jan 31 12:25:55 2023 -0500

    aio: fix mremap after fork null-deref
    
    commit 81e9d6f8647650a7bead74c5f926e29970e834d1 upstream.
    
    Commit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduced
    a null-deref if mremap is called on an old aio mapping after fork as
    mm->ioctx_table will be set to NULL.
    
    [jmoyer@redhat.com: fix 80 column issue]
    Link: https://lkml.kernel.org/r/x49sffq4nvg.fsf@segfault.boston.devel.redhat.com
    Fixes: e4a0d3e720e7 ("aio: Make it possible to remap aio ring")
    Signed-off-by: Seth Jenkins <sethjenkins@google.com>
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Benjamin LaHaise <bcrl@kvack.org>
    Cc: Jann Horn <jannh@google.com>
    Cc: Pavel Emelyanov <xemul@parallels.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dcb474af1d5d06c1e343a0d7248219bb87a08b7
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Fri Jan 27 10:40:11 2023 +0000

    nvmem: core: fix registration vs use race
    
    [ Upstream commit ab3428cfd9aa2f3463ee4b2909b5bb2193bd0c4a ]
    
    The i.MX6 CPU frequency driver sometimes fails to register at boot time
    due to nvmem_cell_read_u32() sporadically returning -ENOENT.
    
    This happens because there is a window where __nvmem_device_get() in
    of_nvmem_cell_get() is able to return the nvmem device, but as cells
    have been setup, nvmem_find_cell_entry_by_node() returns NULL.
    
    The occurs because the nvmem core registration code violates one of the
    fundamental principles of kernel programming: do not publish data
    structures before their setup is complete.
    
    Fix this by making nvmem core code conform with this principle.
    
    Fixes: eace75cfdcf7 ("nvmem: Add a simple NVMEM framework for nvmem providers")
    Cc: stable@vger.kernel.org
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20230127104015.23839-7-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23676ecd2eb377f7c24a6ff578b0f4c7135658b6
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Fri Jan 27 10:40:10 2023 +0000

    nvmem: core: fix cleanup after dev_set_name()
    
    [ Upstream commit 560181d3ace61825f4ca9dd3481d6c0ee6709fa8 ]
    
    If dev_set_name() fails, we leak nvmem->wp_gpio as the cleanup does not
    put this. While a minimal fix for this would be to add the gpiod_put()
    call, we can do better if we split device_register(), and use the
    tested nvmem_release() cleanup code by initialising the device early,
    and putting the device.
    
    This results in a slightly larger fix, but results in clear code.
    
    Note: this patch depends on "nvmem: core: initialise nvmem->id early"
    and "nvmem: core: remove nvmem_config wp_gpio".
    
    Fixes: 5544e90c8126 ("nvmem: core: add error handling for dev_set_name")
    Cc: stable@vger.kernel.org
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    [Srini: Fixed subject line and error code handing with wp_gpio while applying.]
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20230127104015.23839-6-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: ab3428cfd9aa ("nvmem: core: fix registration vs use race")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89991ededcb557dcfe6398fa37eb182d01cfe257
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Fri Jan 27 10:40:09 2023 +0000

    nvmem: core: remove nvmem_config wp_gpio
    
    [ Upstream commit 569653f022a29a1a44ea9de5308b657228303fa5 ]
    
    No one provides wp_gpio, so let's remove it to avoid issues with
    the nvmem core putting this gpio.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20230127104015.23839-5-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: ab3428cfd9aa ("nvmem: core: fix registration vs use race")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a19a0f67dbb89ad2bfc466f2003841acba645884
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Fri Sep 16 13:20:50 2022 +0100

    nvmem: core: add error handling for dev_set_name
    
    [ Upstream commit 5544e90c81261e82e02bbf7c6015a4b9c8c825ef ]
    
    The type of return value of dev_set_name is int, which may return
    wrong result, so we add error handling for it to reclaim memory
    of nvmem resource, and return early when an error occurs.
    
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20220916122100.170016-4-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: ab3428cfd9aa ("nvmem: core: fix registration vs use race")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 25f65c83f5f7c5de3d7c7f0b10e15a7413dfe5bf
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Feb 2 11:34:13 2023 +0100

    platform/x86: touchscreen_dmi: Add Chuwi Vi8 (CWI501) DMI match
    
    [ Upstream commit eecf2acd4a580e9364e5087daf0effca60a240b7 ]
    
    Add a DMI match for the CWI501 version of the Chuwi Vi8 tablet,
    pointing to the same chuwi_vi8_data as the existing CWI506 version
    DMI match.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20230202103413.331459-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ecf5b49df38fa26e5039894e247fa12a8b796799
Author: Amit Engel <Amit.Engel@dell.com>
Date:   Mon Jan 23 14:37:28 2023 +0200

    nvme-fc: fix a missing queue put in nvmet_fc_ls_create_association
    
    [ Upstream commit 0cab4404874f2de52617de8400c844891c6ea1ce ]
    
    As part of nvmet_fc_ls_create_association there is a case where
    nvmet_fc_alloc_target_queue fails right after a new association with an
    admin queue is created. In this case, no one releases the get taken in
    nvmet_fc_alloc_target_assoc.  This fix is adding the missing put.
    
    Signed-off-by: Amit Engel <Amit.Engel@dell.com>
    Reviewed-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55dbd6f4ea954751340f4f73d5dcd7c8f12208b2
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Sun Jan 29 23:47:23 2023 +0100

    s390/decompressor: specify __decompress() buf len to avoid overflow
    
    [ Upstream commit 7ab41c2c08a32132ba8c14624910e2fe8ce4ba4b ]
    
    Historically calls to __decompress() didn't specify "out_len" parameter
    on many architectures including s390, expecting that no writes beyond
    uncompressed kernel image are performed. This has changed since commit
    2aa14b1ab2c4 ("zstd: import usptream v1.5.2") which includes zstd library
    commit 6a7ede3dfccb ("Reduce size of dctx by reutilizing dst buffer
    (#2751)"). Now zstd decompression code might store literal buffer in
    the unwritten portion of the destination buffer. Since "out_len" is
    not set, it is considered to be unlimited and hence free to use for
    optimization needs. On s390 this might corrupt initrd or ipl report
    which are often placed right after the decompressor buffer. Luckily the
    size of uncompressed kernel image is already known to the decompressor,
    so to avoid the problem simply specify it in the "out_len" parameter.
    
    Link: https://github.com/facebook/zstd/commit/6a7ede3dfccb
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Tested-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Link: https://lore.kernel.org/r/patch-1.thread-41c676.git-41c676c2d153.your-ad-here.call-01675030179-ext-9637@work.hours
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 90fcf55d83b20da1091f926a291af05fb74f61c6
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Jan 27 14:40:37 2023 -0800

    net: sched: sch: Bounds check priority
    
    [ Upstream commit de5ca4c3852f896cacac2bf259597aab5e17d9e3 ]
    
    Nothing was explicitly bounds checking the priority index used to access
    clpriop[]. WARN and bail out early if it's pathological. Seen with GCC 13:
    
    ../net/sched/sch_htb.c: In function 'htb_activate_prios':
    ../net/sched/sch_htb.c:437:44: warning: array subscript [0, 31] is outside array bounds of 'struct htb_prio[8]' [-Warray-bounds=]
      437 |                         if (p->inner.clprio[prio].feed.rb_node)
          |                             ~~~~~~~~~~~~~~~^~~~~~
    ../net/sched/sch_htb.c:131:41: note: while referencing 'clprio'
      131 |                         struct htb_prio clprio[TC_HTB_NUMPRIO];
          |                                         ^~~~~~
    
    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Cc: Jiri Pirko <jiri@resnulli.us>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: netdev@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Reviewed-by: Cong Wang <cong.wang@bytedance.com>
    Link: https://lore.kernel.org/r/20230127224036.never.561-kees@kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 614a58e00d7bcbaf0d698712e0decd29d53a3847
Author: Andrey Konovalov <andrey.konovalov@linaro.org>
Date:   Fri Jan 27 00:35:39 2023 +0300

    net: stmmac: do not stop RX_CLK in Rx LPI state for qcs404 SoC
    
    [ Upstream commit 54aa39a513dbf2164ca462a19f04519b2407a224 ]
    
    Currently in phy_init_eee() the driver unconditionally configures the PHY
    to stop RX_CLK after entering Rx LPI state. This causes an LPI interrupt
    storm on my qcs404-base board.
    
    Change the PHY initialization so that for "qcom,qcs404-ethqos" compatible
    device RX_CLK continues to run even in Rx LPI state.
    
    Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa84a8cc1b536883bc381d03fc036fa9b21d0e6a
Author: Hyunwoo Kim <v4bel@theori.io>
Date:   Wed Jan 25 02:59:44 2023 -0800

    net/rose: Fix to not accept on connected socket
    
    [ Upstream commit 14caefcf9837a2be765a566005ad82cd0d2a429f ]
    
    If you call listen() and accept() on an already connect()ed
    rose socket, accept() can successfully connect.
    This is because when the peer socket sends data to sendmsg,
    the skb with its own sk stored in the connected socket's
    sk->sk_receive_queue is connected, and rose_accept() dequeues
    the skb waiting in the sk->sk_receive_queue.
    
    This creates a child socket with the sk of the parent
    rose socket, which can cause confusion.
    
    Fix rose_listen() to return -EINVAL if the socket has
    already been successfully connected, and add lock_sock
    to prevent this issue.
    
    Signed-off-by: Hyunwoo Kim <v4bel@theori.io>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20230125105944.GA133314@ubuntu
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 37bb61763d9f62c12064c0c5b37ec4edcc7f5e76
Author: Shunsuke Mie <mie@igel.co.jp>
Date:   Tue Jan 10 12:43:10 2023 +0900

    tools/virtio: fix the vringh test for virtio ring changes
    
    [ Upstream commit 3f7b75abf41cc4143aa295f62acbb060a012868d ]
    
    Fix the build caused by missing kmsan_handle_dma() and is_power_of_2() that
    are used in drivers/virtio/virtio_ring.c.
    
    Signed-off-by: Shunsuke Mie <mie@igel.co.jp>
    Message-Id: <20230110034310.779744-1-mie@igel.co.jp>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ec44268e29cb0f3ed65aa12624d8589d7ac2feb
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Jan 26 17:21:24 2023 +0100

    ASoC: cs42l56: fix DT probe
    
    [ Upstream commit e18c6da62edc780e4f4f3c9ce07bdacd69505182 ]
    
    While looking through legacy platform data users, I noticed that
    the DT probing never uses data from the DT properties, as the
    platform_data structure gets overwritten directly after it
    is initialized.
    
    There have never been any boards defining the platform_data in
    the mainline kernel either, so this driver so far only worked
    with patched kernels or with the default values.
    
    For the benefit of possible downstream users, fix the DT probe
    by no longer overwriting the data.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20230126162203.2986339-1-arnd@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7fc4e7191eae9d9325511e03deadfdb2224914f8
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Thu Jan 19 15:32:35 2023 +0100

    ALSA: hda: Do not unset preset when cleaning up codec
    
    [ Upstream commit 87978e6ad45a16835cc58234451111091be3c59a ]
    
    Several functions that take part in codec's initialization and removal
    are re-used by ASoC codec drivers implementations. Drivers mimic the
    behavior of hda_codec_driver_probe/remove() found in
    sound/pci/hda/hda_bind.c with their component->probe/remove() instead.
    
    One of the reasons for that is the expectation of
    snd_hda_codec_device_new() to receive a valid pointer to an instance of
    struct snd_card. This expectation can be met only once sound card
    components probing commences.
    
    As ASoC sound card may be unbound without codec device being actually
    removed from the system, unsetting ->preset in
    snd_hda_codec_cleanup_for_unbind() interferes with module unload -> load
    scenario causing null-ptr-deref. Preset is assigned only once, during
    device/driver matching whereas ASoC codec driver's module reloading may
    occur several times throughout the lifetime of an audio stack.
    
    Suggested-by: Takashi Iwai <tiwai@suse.com>
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://lore.kernel.org/r/20230119143235.1159814-1-cezary.rojewski@intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 490fcbc7b5f6c4d7841de2baf59211dd3395cf21
Author: Eduard Zingerman <eddyz87@gmail.com>
Date:   Fri Jan 6 16:22:14 2023 +0200

    selftests/bpf: Verify copy_register_state() preserves parent/live fields
    
    [ Upstream commit b9fa9bc839291020b362ab5392e5f18ba79657ac ]
    
    A testcase to check that verifier.c:copy_register_state() preserves
    register parentage chain and livness information.
    
    Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
    Link: https://lore.kernel.org/r/20230106142214.1040390-3-eddyz87@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d3a5ec579759a57b0a6c192e2aadab956879a26
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Thu Jan 19 18:34:56 2023 +0200

    ASoC: Intel: sof_rt5682: always set dpcm_capture for amplifiers
    
    [ Upstream commit 324f065cdbaba1b879a63bf07e61ca156b789537 ]
    
    The amplifier may provide hardware support for I/V feedback, or
    alternatively the firmware may generate an echo reference attached to
    the SSP and dailink used for the amplifier.
    
    To avoid any issues with invalid/NULL substreams in the latter case,
    always unconditionally set dpcm_capture.
    
    Link: https://github.com/thesofproject/linux/issues/4083
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Link: https://lore.kernel.org/r/20230119163459.2235843-2-kai.vehmanen@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>