Linux 6.1.20

 
adreno: Shutdown the GPU properly [+ + +]
Author: Joel Fernandes (Google) <joel@joelfernandes.org>
Date:   Mon Jan 9 22:25:47 2023 +0000

    adreno: Shutdown the GPU properly
    
    [ Upstream commit e752e5454e6417da3f40ec1306a041ea96c56423 ]
    
    During kexec on ARM device, we notice that device_shutdown() only calls
    pm_runtime_force_suspend() while shutting down the GPU. This means the GPU
    kthread is still running and further, there maybe active submits.
    
    This causes all kinds of issues during a kexec reboot:
    
    Warning from shutdown path:
    
    [  292.509662] WARNING: CPU: 0 PID: 6304 at [...] adreno_runtime_suspend+0x3c/0x44
    [  292.509863] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
    [  292.509872] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [  292.509881] pc : adreno_runtime_suspend+0x3c/0x44
    [  292.509891] lr : pm_generic_runtime_suspend+0x30/0x44
    [  292.509905] sp : ffffffc014473bf0
    [...]
    [  292.510043] Call trace:
    [  292.510051]  adreno_runtime_suspend+0x3c/0x44
    [  292.510061]  pm_generic_runtime_suspend+0x30/0x44
    [  292.510071]  pm_runtime_force_suspend+0x54/0xc8
    [  292.510081]  adreno_shutdown+0x1c/0x28
    [  292.510090]  platform_shutdown+0x2c/0x38
    [  292.510104]  device_shutdown+0x158/0x210
    [  292.510119]  kernel_restart_prepare+0x40/0x4c
    
    And here from GPU kthread, an SError OOPs:
    
    [  192.648789]  el1h_64_error+0x7c/0x80
    [  192.648812]  el1_interrupt+0x20/0x58
    [  192.648833]  el1h_64_irq_handler+0x18/0x24
    [  192.648854]  el1h_64_irq+0x7c/0x80
    [  192.648873]  local_daif_inherit+0x10/0x18
    [  192.648900]  el1h_64_sync_handler+0x48/0xb4
    [  192.648921]  el1h_64_sync+0x7c/0x80
    [  192.648941]  a6xx_gmu_set_oob+0xbc/0x1fc
    [  192.648968]  a6xx_hw_init+0x44/0xe38
    [  192.648991]  msm_gpu_hw_init+0x48/0x80
    [  192.649013]  msm_gpu_submit+0x5c/0x1a8
    [  192.649034]  msm_job_run+0xb0/0x11c
    [  192.649058]  drm_sched_main+0x170/0x434
    [  192.649086]  kthread+0x134/0x300
    [  192.649114]  ret_from_fork+0x10/0x20
    
    Fix by calling adreno_system_suspend() in the device_shutdown() path.
    
    [ Applied Rob Clark feedback on fixing adreno_unbind() similarly, also
      tested as above. ]
    
    Cc: Rob Clark <robdclark@chromium.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Ricardo Ribalda <ribalda@chromium.org>
    Cc: Ross Zwisler <zwisler@kernel.org>
    Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
    Reviewed-by: Rob Clark <robdclark@gmail.com>
    Patchwork: https://patchwork.freedesktop.org/patch/517633/
    Link: https://lore.kernel.org/r/20230109222547.1368644-1-joel@joelfernandes.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Stable-dep-of: 6153c44392b0 ("drm/msm/adreno: fix runtime PM imbalance at unbind")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
af_unix: fix struct pid leaks in OOB support [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Mar 7 16:45:30 2023 +0000

    af_unix: fix struct pid leaks in OOB support
    
    [ Upstream commit 2aab4b96900272885bc157f8b236abf1cdc02e08 ]
    
    syzbot reported struct pid leak [1].
    
    Issue is that queue_oob() calls maybe_add_creds() which potentially
    holds a reference on a pid.
    
    But skb->destructor is not set (either directly or by calling
    unix_scm_to_skb())
    
    This means that subsequent kfree_skb() or consume_skb() would leak
    this reference.
    
    In this fix, I chose to fully support scm even for the OOB message.
    
    [1]
    BUG: memory leak
    unreferenced object 0xffff8881053e7f80 (size 128):
    comm "syz-executor242", pid 5066, jiffies 4294946079 (age 13.220s)
    hex dump (first 32 bytes):
    01 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:
    [<ffffffff812ae26a>] alloc_pid+0x6a/0x560 kernel/pid.c:180
    [<ffffffff812718df>] copy_process+0x169f/0x26c0 kernel/fork.c:2285
    [<ffffffff81272b37>] kernel_clone+0xf7/0x610 kernel/fork.c:2684
    [<ffffffff812730cc>] __do_sys_clone+0x7c/0xb0 kernel/fork.c:2825
    [<ffffffff849ad699>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    [<ffffffff849ad699>] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
    [<ffffffff84a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: 314001f0bf92 ("af_unix: Add OOB support")
    Reported-by: syzbot+7699d9e5635c10253a27@syzkaller.appspotmail.com
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Rao Shoaib <rao.shoaib@oracle.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20230307164530.771896-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
alpha: fix R_ALPHA_LITERAL reloc for large modules [+ + +]
Author: Edward Humes <aurxenon@lunos.org>
Date:   Sat Aug 27 02:49:39 2022 -0400

    alpha: fix R_ALPHA_LITERAL reloc for large modules
    
    [ Upstream commit b6b17a8b3ecd878d98d5472a9023ede9e669ca72 ]
    
    Previously, R_ALPHA_LITERAL relocations would overflow for large kernel
    modules.
    
    This was because the Alpha's apply_relocate_add was relying on the kernel's
    module loader to have sorted the GOT towards the very end of the module as it
    was mapped into memory in order to correctly assign the global pointer. While
    this behavior would mostly work fine for small kernel modules, this approach
    would overflow on kernel modules with large GOT's since the global pointer
    would be very far away from the GOT, and thus, certain entries would be out of
    range.
    
    This patch fixes this by instead using the Tru64 behavior of assigning the
    global pointer to be 32KB away from the start of the GOT. The change made
    in this patch won't work for multi-GOT kernel modules as it makes the
    assumption the module only has one GOT located at the beginning of .got,
    although for the vast majority kernel modules, this should be fine. Of the
    kernel modules that would previously result in a relocation error, none of
    them, even modules like nouveau, have even come close to filling up a single
    GOT, and they've all worked fine under this patch.
    
    Signed-off-by: Edward Humes <aurxenon@lunos.org>
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bgmac: fix *initial* chip reset to support BCM5358 [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Mon Feb 27 10:11:56 2023 +0100

    bgmac: fix *initial* chip reset to support BCM5358
    
    [ Upstream commit f99e6d7c4ed3be2531bd576425a5bd07fb133bd7 ]
    
    While bringing hardware up we should perform a full reset including the
    switch bit (BGMAC_BCMA_IOCTL_SW_RESET aka SICF_SWRST). It's what
    specification says and what reference driver does.
    
    This seems to be critical for the BCM5358. Without this hardware doesn't
    get initialized properly and doesn't seem to transmit or receive any
    packets.
    
    Originally bgmac was calling bgmac_chip_reset() before setting
    "has_robosw" property which resulted in expected behaviour. That has
    changed as a side effect of adding platform device support which
    regressed BCM5358 support.
    
    Fixes: f6a95a24957a ("net: ethernet: bgmac: Add platform device support")
    Cc: Jon Mason <jdmason@kudzu.us>
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20230227091156.19509-1-zajec5@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block: fix scan partition for exclusively open device again [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Fri Feb 17 10:22:00 2023 +0800

    block: fix scan partition for exclusively open device again
    
    [ Upstream commit e5cfefa97bccf956ea0bb6464c1f6c84fd7a8d9f ]
    
    As explained in commit 36369f46e917 ("block: Do not reread partition table
    on exclusively open device"), reread partition on the device that is
    exclusively opened by someone else is problematic.
    
    This patch will make sure partition scan will only be proceed if current
    thread open the device exclusively, or the device is not opened
    exclusively, and in the later case, other scanners and exclusive openers
    will be blocked temporarily until partition scan is done.
    
    Fixes: 10c70d95c0f2 ("block: remove the bd_openers checks in blk_drop_partitions")
    Cc: <stable@vger.kernel.org>
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20230217022200.3092987-3-yukuai1@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: fix wrong mode for blkdev_put() from disk_scan_partitions() [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Mar 7 18:55:52 2023 +0800

    block: fix wrong mode for blkdev_put() from disk_scan_partitions()
    
    [ Upstream commit 428913bce1e67ccb4dae317fd0332545bf8c9233 ]
    
    If disk_scan_partitions() is called with 'FMODE_EXCL',
    blkdev_get_by_dev() will be called without 'FMODE_EXCL', however, follow
    blkdev_put() is still called with 'FMODE_EXCL', which will cause
    'bd_holders' counter to leak.
    
    Fix the problem by using the right mode for blkdev_put().
    
    Reported-by: syzbot+2bcc0d79e548c4f62a59@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/lkml/f9649d501bc8c3444769418f6c26263555d9d3be.camel@linux.ibm.com/T/
    Tested-by: Julian Ruess <julianr@linux.ibm.com>
    Fixes: e5cfefa97bcc ("block: fix scan partition for exclusively open device again")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: Revert "block: Do not reread partition table on exclusively open device" [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Fri Feb 17 10:21:59 2023 +0800

    block: Revert "block: Do not reread partition table on exclusively open device"
    
    [ Upstream commit 0f77b29ad14e34a89961f32edc87b92db623bb37 ]
    
    This reverts commit 36369f46e91785688a5f39d7a5590e3f07981316.
    
    This patch can't fix the problem in a corner case that device can be
    opened exclusively after the checking and before blkdev_get_by_dev().
    We'll use a new solution to fix the problem in the next patch, and
    the new solution doesn't need to change apis.
    
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Acked-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230217022200.3092987-2-yukuai1@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: e5cfefa97bcc ("block: fix scan partition for exclusively open device again")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bnxt_en: Avoid order-5 memory allocation for TPA data [+ + +]
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Fri Mar 3 18:43:57 2023 -0800

    bnxt_en: Avoid order-5 memory allocation for TPA data
    
    [ Upstream commit accd7e23693aaaa9aa0d3e9eca0ae77d1be80ab3 ]
    
    The driver needs to keep track of all the possible concurrent TPA (GRO/LRO)
    completions on the aggregation ring.  On P5 chips, the maximum number
    of concurrent TPA is 256 and the amount of memory we allocate is order-5
    on systems using 4K pages.  Memory allocation failure has been reported:
    
    NetworkManager: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0-1
    CPU: 15 PID: 2995 Comm: NetworkManager Kdump: loaded Not tainted 5.10.156 #1
    Hardware name: Dell Inc. PowerEdge R660/0M1CC5, BIOS 0.2.25 08/12/2022
    Call Trace:
     dump_stack+0x57/0x6e
     warn_alloc.cold.120+0x7b/0xdd
     ? _cond_resched+0x15/0x30
     ? __alloc_pages_direct_compact+0x15f/0x170
     __alloc_pages_slowpath.constprop.108+0xc58/0xc70
     __alloc_pages_nodemask+0x2d0/0x300
     kmalloc_order+0x24/0xe0
     kmalloc_order_trace+0x19/0x80
     bnxt_alloc_mem+0x1150/0x15c0 [bnxt_en]
     ? bnxt_get_func_stat_ctxs+0x13/0x60 [bnxt_en]
     __bnxt_open_nic+0x12e/0x780 [bnxt_en]
     bnxt_open+0x10b/0x240 [bnxt_en]
     __dev_open+0xe9/0x180
     __dev_change_flags+0x1af/0x220
     dev_change_flags+0x21/0x60
     do_setlink+0x35c/0x1100
    
    Instead of allocating this big chunk of memory and dividing it up for the
    concurrent TPA instances, allocate each small chunk separately for each
    TPA instance.  This will reduce it to order-0 allocations.
    
    Fixes: 79632e9ba386 ("bnxt_en: Expand bnxt_tpa_info struct to support 57500 chips.")
    Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
    Reviewed-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com>
    Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser() [+ + +]
Author: Liu Jian <liujian56@huawei.com>
Date:   Fri Mar 3 16:09:46 2023 +0800

    bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser()
    
    [ Upstream commit d900f3d20cc3169ce42ec72acc850e662a4d4db2 ]
    
    When the buffer length of the recvmsg system call is 0, we got the
    flollowing soft lockup problem:
    
    watchdog: BUG: soft lockup - CPU#3 stuck for 27s! [a.out:6149]
    CPU: 3 PID: 6149 Comm: a.out Kdump: loaded Not tainted 6.2.0+ #30
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
    RIP: 0010:remove_wait_queue+0xb/0xc0
    Code: 5e 41 5f c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 57 <41> 56 41 55 41 54 55 48 89 fd 53 48 89 f3 4c 8d 6b 18 4c 8d 73 20
    RSP: 0018:ffff88811b5978b8 EFLAGS: 00000246
    RAX: 0000000000000000 RBX: ffff88811a7d3780 RCX: ffffffffb7a4d768
    RDX: dffffc0000000000 RSI: ffff88811b597908 RDI: ffff888115408040
    RBP: 1ffff110236b2f1b R08: 0000000000000000 R09: ffff88811a7d37e7
    R10: ffffed10234fa6fc R11: 0000000000000001 R12: ffff88811179b800
    R13: 0000000000000001 R14: ffff88811a7d38a8 R15: ffff88811a7d37e0
    FS:  00007f6fb5398740(0000) GS:ffff888237180000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020000000 CR3: 000000010b6ba002 CR4: 0000000000370ee0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     tcp_msg_wait_data+0x279/0x2f0
     tcp_bpf_recvmsg_parser+0x3c6/0x490
     inet_recvmsg+0x280/0x290
     sock_recvmsg+0xfc/0x120
     ____sys_recvmsg+0x160/0x3d0
     ___sys_recvmsg+0xf0/0x180
     __sys_recvmsg+0xea/0x1a0
     do_syscall_64+0x3f/0x90
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    The logic in tcp_bpf_recvmsg_parser is as follows:
    
    msg_bytes_ready:
            copied = sk_msg_recvmsg(sk, psock, msg, len, flags);
            if (!copied) {
                    wait data;
                    goto msg_bytes_ready;
            }
    
    In this case, "copied" always is 0, the infinite loop occurs.
    
    According to the Linux system call man page, 0 should be returned in this
    case. Therefore, in tcp_bpf_recvmsg_parser(), if the length is 0, directly
    return. Also modify several other functions with the same problem.
    
    Fixes: 1f5be6b3b063 ("udp: Implement udp_bpf_recvmsg() for sockmap")
    Fixes: 9825d866ce0d ("af_unix: Implement unix_dgram_bpf_recvmsg()")
    Fixes: c5d2177a72a1 ("bpf, sockmap: Fix race in ingress receive verdict with redirect to self")
    Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
    Signed-off-by: Liu Jian <liujian56@huawei.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Cc: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/20230303080946.1146638-1-liujian56@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, test_run: fix &xdp_frame misplacement for LIVE_FRAMES [+ + +]
Author: Alexander Lobakin <aleksander.lobakin@intel.com>
Date:   Wed Feb 15 19:54:40 2023 +0100

    bpf, test_run: fix &xdp_frame misplacement for LIVE_FRAMES
    
    [ Upstream commit 6c20822fada1b8adb77fa450d03a0d449686a4a9 ]
    
    &xdp_buff and &xdp_frame are bound in a way that
    
    xdp_buff->data_hard_start == xdp_frame
    
    It's always the case and e.g. xdp_convert_buff_to_frame() relies on
    this.
    IOW, the following:
    
            for (u32 i = 0; i < 0xdead; i++) {
                    xdpf = xdp_convert_buff_to_frame(&xdp);
                    xdp_convert_frame_to_buff(xdpf, &xdp);
            }
    
    shouldn't ever modify @xdpf's contents or the pointer itself.
    However, "live packet" code wrongly treats &xdp_frame as part of its
    context placed *before* the data_hard_start. With such flow,
    data_hard_start is sizeof(*xdpf) off to the right and no longer points
    to the XDP frame.
    
    Instead of replacing `sizeof(ctx)` with `offsetof(ctx, xdpf)` in several
    places and praying that there are no more miscalcs left somewhere in the
    code, unionize ::frm with ::data in a flex array, so that both starts
    pointing to the actual data_hard_start and the XDP frame actually starts
    being a part of it, i.e. a part of the headroom, not the context.
    A nice side effect is that the maximum frame size for this mode gets
    increased by 40 bytes, as xdp_buff::frame_sz includes everything from
    data_hard_start (-> includes xdpf already) to the end of XDP/skb shared
    info.
    Also update %MAX_PKT_SIZE accordingly in the selftests code. Leave it
    hardcoded for 64 bit && 4k pages, it can be made more flexible later on.
    
    Minor: align `&head->data` with how `head->frm` is assigned for
    consistency.
    Minor #2: rename 'frm' to 'frame' in &xdp_page_head while at it for
    clarity.
    
    (was found while testing XDP traffic generator on ice, which calls
     xdp_convert_frame_to_buff() for each XDP frame)
    
    Fixes: b530e9e1063e ("bpf: Add "live packet" mode for XDP in BPF_PROG_RUN")
    Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
    Link: https://lore.kernel.org/r/20230215185440.4126672-1-aleksander.lobakin@intel.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btf: fix resolving BTF_KIND_VAR after ARRAY, STRUCT, UNION, PTR [+ + +]
Author: Lorenz Bauer <lorenz.bauer@isovalent.com>
Date:   Mon Mar 6 11:21:37 2023 +0000

    btf: fix resolving BTF_KIND_VAR after ARRAY, STRUCT, UNION, PTR
    
    [ Upstream commit 9b459804ff9973e173fabafba2a1319f771e85fa ]
    
    btf_datasec_resolve contains a bug that causes the following BTF
    to fail loading:
    
        [1] DATASEC a size=2 vlen=2
            type_id=4 offset=0 size=1
            type_id=7 offset=1 size=1
        [2] INT (anon) size=1 bits_offset=0 nr_bits=8 encoding=(none)
        [3] PTR (anon) type_id=2
        [4] VAR a type_id=3 linkage=0
        [5] INT (anon) size=1 bits_offset=0 nr_bits=8 encoding=(none)
        [6] TYPEDEF td type_id=5
        [7] VAR b type_id=6 linkage=0
    
    This error message is printed during btf_check_all_types:
    
        [1] DATASEC a size=2 vlen=2
            type_id=7 offset=1 size=1 Invalid type
    
    By tracing btf_*_resolve we can pinpoint the problem:
    
        btf_datasec_resolve(depth: 1, type_id: 1, mode: RESOLVE_TBD) = 0
            btf_var_resolve(depth: 2, type_id: 4, mode: RESOLVE_TBD) = 0
                btf_ptr_resolve(depth: 3, type_id: 3, mode: RESOLVE_PTR) = 0
            btf_var_resolve(depth: 2, type_id: 4, mode: RESOLVE_PTR) = 0
        btf_datasec_resolve(depth: 1, type_id: 1, mode: RESOLVE_PTR) = -22
    
    The last invocation of btf_datasec_resolve should invoke btf_var_resolve
    by means of env_stack_push, instead it returns EINVAL. The reason is that
    env_stack_push is never executed for the second VAR.
    
        if (!env_type_is_resolve_sink(env, var_type) &&
            !env_type_is_resolved(env, var_type_id)) {
            env_stack_set_next_member(env, i + 1);
            return env_stack_push(env, var_type, var_type_id);
        }
    
    env_type_is_resolve_sink() changes its behaviour based on resolve_mode.
    For RESOLVE_PTR, we can simplify the if condition to the following:
    
        (btf_type_is_modifier() || btf_type_is_ptr) && !env_type_is_resolved()
    
    Since we're dealing with a VAR the clause evaluates to false. This is
    not sufficient to trigger the bug however. The log output and EINVAL
    are only generated if btf_type_id_size() fails.
    
        if (!btf_type_id_size(btf, &type_id, &type_size)) {
            btf_verifier_log_vsi(env, v->t, vsi, "Invalid type");
            return -EINVAL;
        }
    
    Most types are sized, so for example a VAR referring to an INT is not a
    problem. The bug is only triggered if a VAR points at a modifier. Since
    we skipped btf_var_resolve that modifier was also never resolved, which
    means that btf_resolved_type_id returns 0 aka VOID for the modifier.
    This in turn causes btf_type_id_size to return NULL, triggering EINVAL.
    
    To summarise, the following conditions are necessary:
    
    - VAR pointing at PTR, STRUCT, UNION or ARRAY
    - Followed by a VAR pointing at TYPEDEF, VOLATILE, CONST, RESTRICT or
      TYPE_TAG
    
    The fix is to reset resolve_mode to RESOLVE_TBD before attempting to
    resolve a VAR from a DATASEC.
    
    Fixes: 1dc92851849c ("bpf: kernel side support for BTF Var and DataSec")
    Signed-off-by: Lorenz Bauer <lmb@isovalent.com>
    Link: https://lore.kernel.org/r/20230306112138.155352-2-lmb@isovalent.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: fix extent map logging bit not cleared for split maps after dropping range [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Feb 27 12:53:56 2023 +0000

    btrfs: fix extent map logging bit not cleared for split maps after dropping range
    
    [ Upstream commit e4cc1483f35940c9288c332dd275f6fad485f8d2 ]
    
    At btrfs_drop_extent_map_range() we are clearing the EXTENT_FLAG_LOGGING
    bit on a 'flags' variable that was not initialized. This makes static
    checkers complain about it, so initialize the 'flags' variable before
    clearing the bit.
    
    In practice this has no consequences, because EXTENT_FLAG_LOGGING should
    not be set when btrfs_drop_extent_map_range() is called, as an fsync locks
    the inode in exclusive mode, locks the inode's mmap semaphore in exclusive
    mode too and it always flushes all delalloc.
    
    Also add a comment about why we clear EXTENT_FLAG_LOGGING on a copy of the
    flags of the split extent map.
    
    Reported-by: Dan Carpenter <error27@gmail.com>
    Link: https://lore.kernel.org/linux-btrfs/Y%2FyipSVozUDEZKow@kili/
    Fixes: db21370bffbc ("btrfs: drop extent map range more efficiently")
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: fix percent calculation for bg reclaim message [+ + +]
Author: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Date:   Tue Feb 21 10:11:24 2023 -0800

    btrfs: fix percent calculation for bg reclaim message
    
    commit 95cd356ca23c3807b5f3503687161e216b1c520d upstream.
    
    We have a report, that the info message for block-group reclaim is
    crossing the 100% used mark.
    
    This is happening as we were truncating the divisor for the division
    (the block_group->length) to a 32bit value.
    
    Fix this by using div64_u64() to not truncate the divisor.
    
    In the worst case, it can lead to a div by zero error and should be
    possible to trigger on 4 disks RAID0, and each device is large enough:
    
      $ mkfs.btrfs  -f /dev/test/scratch[1234] -m raid1 -d raid0
      btrfs-progs v6.1
      [...]
      Filesystem size:    40.00GiB
      Block group profiles:
        Data:             RAID0             4.00GiB <<<
        Metadata:         RAID1           256.00MiB
        System:           RAID1             8.00MiB
    
    Reported-by: Forza <forza@tnonline.net>
    Link: https://lore.kernel.org/linux-btrfs/e99483.c11a58d.1863591ca52@tnonline.net/
    Fixes: 5f93e776c673 ("btrfs: zoned: print unusable percentage when reclaiming block groups")
    CC: stable@vger.kernel.org # 5.15+
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    [ add Qu's note ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix unnecessary increment of read error stat on write error [+ + +]
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Mon Feb 13 14:10:38 2023 +0900

    btrfs: fix unnecessary increment of read error stat on write error
    
    commit 98e8d36a26c2ed22f78316df7d4bf33e554b9f9f upstream.
    
    Current btrfs_log_dev_io_error() increases the read error count even if the
    erroneous IO is a WRITE request. This is because it forget to use "else
    if", and all the error WRITE requests counts as READ error as there is (of
    course) no REQ_RAHEAD bit set.
    
    Fixes: c3a62baf21ad ("btrfs: use chained bios when cloning")
    CC: stable@vger.kernel.org # 6.1+
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bus: mhi: ep: Change state_lock to mutex [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Mon Jan 23 12:59:45 2023 +0530

    bus: mhi: ep: Change state_lock to mutex
    
    [ Upstream commit 1ddc7618294084fff8d673217a9479550990ee84 ]
    
    state_lock, the spinlock type is meant to protect race against concurrent
    MHI state transitions. In mhi_ep_set_m0_state(), while the state_lock is
    being held, the channels are resumed in mhi_ep_resume_channels() if the
    previous state was M3. This causes sleeping in atomic bug, since
    mhi_ep_resume_channels() use mutex internally.
    
    Since the state_lock is supposed to be held throughout the state change,
    it is not ideal to drop the lock before calling mhi_ep_resume_channels().
    So to fix this issue, let's change the type of state_lock to mutex. This
    would also allow holding the lock throughout all state transitions thereby
    avoiding any potential race.
    
    Cc: <stable@vger.kernel.org> # 5.19
    Fixes: e4b7b5f0f30a ("bus: mhi: ep: Add support for suspending and resuming channels")
    Reported-by: Dan Carpenter <error27@gmail.com>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bus: mhi: ep: Power up/down MHI stack during MHI RESET [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Wed Dec 28 21:46:59 2022 +0530

    bus: mhi: ep: Power up/down MHI stack during MHI RESET
    
    [ Upstream commit 47a1dcaea07367c84238e71c08244ae3ed48c1cc ]
    
    During graceful shutdown scenario, host will issue MHI RESET to the
    endpoint device before initiating shutdown. In that case, it makes sense
    to completely power down the MHI stack as sooner or later the access to
    MMIO registers will be prohibited. Also, the stack needs to be powered
    up in the case of SYS_ERR to recover the device.
    
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Link: https://lore.kernel.org/r/20221228161704.255268-2-manivannan.sadhasivam@linaro.org
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Stable-dep-of: 1ddc76182940 ("bus: mhi: ep: Change state_lock to mutex")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cifs: improve checking of DFS links over STATUS_OBJECT_NAME_INVALID [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Tue Feb 28 19:01:54 2023 -0300

    cifs: improve checking of DFS links over STATUS_OBJECT_NAME_INVALID
    
    [ Upstream commit b9ee2e307c6b06384b6f9e393a9b8e048e8fc277 ]
    
    Do not map STATUS_OBJECT_NAME_INVALID to -EREMOTE under non-DFS
    shares, or 'nodfs' mounts or CONFIG_CIFS_DFS_UPCALL=n builds.
    Otherwise, in the slow path, get a referral to figure out whether it
    is an actual DFS link.
    
    This could be simply reproduced under a non-DFS share by running the
    following
    
      $ mount.cifs //srv/share /mnt -o ...
      $ cat /mnt/$(printf '\U110000')
      cat: '/mnt/'$'\364\220\200\200': Object is remote
    
    Fixes: c877ce47e137 ("cifs: reduce roundtrips on create/qinfo requests")
    CC: stable@vger.kernel.org # 6.2
    Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: renesas: rcar-gen3: Disable R-Car H3 ES1.* [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Thu Feb 2 10:23:31 2023 +0100

    clk: renesas: rcar-gen3: Disable R-Car H3 ES1.*
    
    [ Upstream commit b1dec4e78599a2ce5bf8557056cd6dd72e1096b0 ]
    
    R-Car H3 ES1.* was only available to an internal development group and
    needed a lot of quirks and workarounds. These become a maintenance
    burden now, so our development group decided to remove upstream support
    for this SoC. Public users only have ES2 onwards.
    
    In addition to the ES1 specific removals, a check for it was added
    preventing the machine to boot further. It may otherwise inherit wrong
    clock settings from ES2 which could damage the hardware.
    
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20230202092332.2504-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: adjust MALL size available for DCN32 and DCN321 [+ + +]
Author: Samson Tam <Samson.Tam@amd.com>
Date:   Wed Jan 11 13:31:31 2023 -0500

    drm/amd/display: adjust MALL size available for DCN32 and DCN321
    
    commit 235fef6c7fd341026eee90cc546e6e8ff8b2c315 upstream.
    
    [Why]
    MALL size available can vary for different SKUs.
    Use num_chans read from VBIOS to determine the available MALL size we can use
    
    [How]
    Define max_chans for DCN32 and DCN321.
    If num_chans is max_chans, then return max_chans as we can access the
     entire MALL space.
    Otherwise, define avail_chans as the number of available channels we are
     allowed instead.
    Return corresponding number of channels back and use this to calculate
     available MALL size.
    
    Reviewed-by: Nevenko Stupar <Nevenko.Stupar@amd.com>
    Acked-by: Alan Liu <HaoPing.Liu@amd.com>
    Signed-off-by: Samson Tam <Samson.Tam@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Allow subvp on vactive pipes that are 2560x1440@60 [+ + +]
Author: Alvin Lee <Alvin.Lee2@amd.com>
Date:   Wed Dec 14 10:12:55 2022 -0500

    drm/amd/display: Allow subvp on vactive pipes that are 2560x1440@60
    
    commit 2ebd1036209c2e7b61e6bc6e5bee4b67c1684ac6 upstream.
    
    Enable subvp on specifically 1440p@60hz displays even though it can
    switch in vactive.
    
    Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
    Reviewed-by: Jun Lei <Jun.Lei@amd.com>
    Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4 [+ + +]
Author: Veerabadhran Gopalakrishnan <veerabadhran.gopalakrishnan@amd.com>
Date:   Wed Mar 8 19:33:53 2023 +0530

    drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4
    
    [ Upstream commit 6ce2ea07c5ff0a8188eab0e5cd1f0e4899b36835 ]
    
    Added the video capability query support for VCN version 4_0_4
    
    Signed-off-by: Veerabadhran Gopalakrishnan <veerabadhran.gopalakrishnan@amd.com>
    Reviewed-by: Leo Liu <leo.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org # 6.1.x
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu/soc21: don't expose AV1 if VCN0 is harvested [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Jan 13 10:45:59 2023 -0500

    drm/amdgpu/soc21: don't expose AV1 if VCN0 is harvested
    
    [ Upstream commit a6de636eb04f146d23644dbbb7173e142452a9b7 ]
    
    Only VCN0 supports AV1.
    
    Reviewed-by: Leo Liu <leo.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: 6ce2ea07c5ff ("drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: fix error checking in amdgpu_read_mm_registers for nv [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Mar 7 08:59:13 2023 -0500

    drm/amdgpu: fix error checking in amdgpu_read_mm_registers for nv
    
    commit b42fee5e0b44344cfe4c38e61341ee250362c83f upstream.
    
    Properly skip non-existent registers as well.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2442
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc15 [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Mar 6 10:34:20 2023 -0500

    drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc15
    
    commit 0dcdf8498eae2727bb33cef3576991dc841d4343 upstream.
    
    Properly skip non-existent registers as well.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2442
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc21 [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Mar 6 10:35:34 2023 -0500

    drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc21
    
    commit 2915e43a033a778816fa4bc621f033576796521e upstream.
    
    Properly skip non-existent registers as well.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2442
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: fix return value check in kfd [+ + +]
Author: Shashank Sharma <shashank.sharma@amd.com>
Date:   Mon Feb 27 15:42:28 2023 +0100

    drm/amdgpu: fix return value check in kfd
    
    [ Upstream commit 20534dbcc7b7bfb447279cdcfb0d88ee3b779a18 ]
    
    This patch fixes a return value check in kfd doorbell handling.
    This function should return 0(error) only when the ida_simple_get
    returns < 0(error), return > 0 is a success case.
    
    Cc: Felix Kuehling <Felix.Kuehling@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Fixes: 16f0013157bf ("drm/amdkfd: Allocate doorbells only when needed")
    Acked-by: Christian Koenig <chriatian.koenig@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Shashank Sharma <shashank.sharma@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/connector: print max_requested_bpc in state debugfs [+ + +]
Author: Harry Wentland <harry.wentland@amd.com>
Date:   Fri Jan 13 11:24:09 2023 -0500

    drm/connector: print max_requested_bpc in state debugfs
    
    commit 7d386975f6a495902e679a3a250a7456d7e54765 upstream.
    
    This is useful to understand the bpc defaults and
    support of a driver.
    
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Cc: Pekka Paalanen <ppaalanen@gmail.com>
    Cc: Sebastian Wick <sebastian.wick@redhat.com>
    Cc: Vitaly.Prosyak@amd.com
    Cc: Uma Shankar <uma.shankar@intel.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Joshua Ashton <joshua@froggi.es>
    Cc: Jani Nikula <jani.nikula@linux.intel.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: amd-gfx@lists.freedesktop.org
    Reviewed-By: Joshua Ashton <joshua@froggi.es>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-3-harry.wentland@amd.com
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF [+ + +]
Author: Harry Wentland <harry.wentland@amd.com>
Date:   Fri Jan 13 11:24:08 2023 -0500

    drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF
    
    commit e5eef23e267c72521d81f23f7f82d1f523d4a253 upstream.
    
    The EDID of an HDR display defines EOTFs that are supported
    by the display and can be set in the HDR metadata infoframe.
    Userspace is expected to read the EDID and set an appropriate
    HDR_OUTPUT_METADATA.
    
    In drm_parse_hdr_metadata_block the kernel reads the supported
    EOTFs from the EDID and stores them in the
    drm_connector->hdr_sink_metadata. While doing so it also
    filters the EOTFs to the EOTFs the kernel knows about.
    When an HDR_OUTPUT_METADATA is set it then checks to
    make sure the EOTF is a supported EOTF. In cases where
    the kernel doesn't know about a new EOTF this check will
    fail, even if the EDID advertises support.
    
    Since it is expected that userspace reads the EDID to understand
    what the display supports it doesn't make sense for DRM to block
    an HDR_OUTPUT_METADATA if it contains an EOTF the kernel doesn't
    understand.
    
    This comes with the added benefit of future-proofing metadata
    support. If the spec defines a new EOTF there is no need to
    update DRM and an compositor can immediately make use of it.
    
    Bug: https://gitlab.freedesktop.org/wayland/weston/-/issues/609
    
    v2: Distinguish EOTFs defind in kernel and ones defined
        in EDID in the commit description (Pekka)
    
    v3: Rebase; drm_hdmi_infoframe_set_hdr_metadata moved
        to drm_hdmi_helper.c
    
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Cc: Pekka Paalanen <ppaalanen@gmail.com>
    Cc: Sebastian Wick <sebastian.wick@redhat.com>
    Cc: Vitaly.Prosyak@amd.com
    Cc: Uma Shankar <uma.shankar@intel.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Joshua Ashton <joshua@froggi.es>
    Cc: Jani Nikula <jani.nikula@linux.intel.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: amd-gfx@lists.freedesktop.org
    Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
    Reviewed-By: Joshua Ashton <joshua@froggi.es>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-2-harry.wentland@amd.com
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915: Do panel VBT init early if the VBT declares an explicit panel type [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Nov 25 19:31:49 2022 +0200

    drm/i915: Do panel VBT init early if the VBT declares an explicit panel type
    
    [ Upstream commit 3f9ffce5765d68775163b8b134c4d7f156b48eec ]
    
    Lots of ADL machines out there with bogus VBTs that declare
    two eDP child devices. In order for those to work we need to
    figure out which power sequencer to use before we try the EDID
    read. So let's do the panel VBT init early if we can, falling
    back to the post-EDID init otherwise.
    
    The post-EDID init panel_type=0xff approach of assuming the
    power sequencer should already be enabled doesn't really work
    with multiple eDP panels, and currently we just end up using
    the same power sequencer for both eDP ports, which at least
    confuses the wakeref tracking, and potentially also causes us
    to toggle the VDD for the panel when we should not.
    
    Cc: Animesh Manna <animesh.manna@intel.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-3-ville.syrjala@linux.intel.com
    Stable-dep-of: 14e591a1930c ("drm/i915: Populate encoder->devdata for DSI on icl+")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/i915: Introduce intel_panel_init_alloc() [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Nov 25 19:31:48 2022 +0200

    drm/i915: Introduce intel_panel_init_alloc()
    
    [ Upstream commit f70f8153e3642337b444fbc0c64d546a46bbcd62 ]
    
    Introduce a place where we can initialize connector->panel
    after it's been allocated. We already have a intel_panel_init()
    so had to get creative with the name and came up with
    intel_panel_init_alloc().
    
    Cc: Animesh Manna <animesh.manna@intel.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-2-ville.syrjala@linux.intel.com
    Stable-dep-of: 14e591a1930c ("drm/i915: Populate encoder->devdata for DSI on icl+")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/i915: Populate encoder->devdata for DSI on icl+ [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Feb 7 08:43:36 2023 +0200

    drm/i915: Populate encoder->devdata for DSI on icl+
    
    [ Upstream commit 14e591a1930c2790fe862af5b01ee3ca587f752f ]
    
    We now have some eDP+DSI dual panel systems floating around
    where the DSI panel is the secondary LFP and thus needs to
    consult "panel type 2" in VBT in order to locate all the
    other panel type dependant stuff correctly.
    
    To that end we need to pass in the devdata to
    intel_bios_init_panel_late(), otherwise it'll just assume
    we want the primary panel type. So let's try to just populate
    the vbt.ports[] stuff and encoder->devdata for icl+ DSI
    panels as well.
    
    We can't do this on older platforms as there we risk a DSI
    port aliasing with a HDMI/DP port, which is a totally legal
    thing as the DSI ports live in their own little parallel
    universe.
    
    Cc: stable@vger.kernel.org
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-3-ville.syrjala@linux.intel.com
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    (cherry picked from commit ba00eb6a4bfbe5194ddda50730aba063951f8ce0)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/a5xx: fix context faults during ring switch [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Feb 14 05:09:56 2023 +0300

    drm/msm/a5xx: fix context faults during ring switch
    
    [ Upstream commit 32e7083429d46f29080626fe387ff90c086b1fbe ]
    
    The rptr_addr is set in the preempt_init_ring(), which is called from
    a5xx_gpu_init(). It uses shadowptr() to set the address, however the
    shadow_iova is not yet initialized at that time. Move the rptr_addr
    setting to the a5xx_preempt_hw_init() which is called after setting the
    shadow_iova, getting the correct value for the address.
    
    Fixes: 8907afb476ac ("drm/msm: Allow a5xx to mark the RPTR shadow as privileged")
    Suggested-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/522640/
    Link: https://lore.kernel.org/r/20230214020956.164473-5-dmitry.baryshkov@linaro.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/a5xx: fix highest bank bit for a530 [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Feb 14 05:09:54 2023 +0300

    drm/msm/a5xx: fix highest bank bit for a530
    
    [ Upstream commit 141f66ebbfa17cc7e2075f06c50107da978c965b ]
    
    A530 has highest bank bit equal to 15 (like A540). Fix values written to
    REG_A5XX_RB_MODE_CNTL and REG_A5XX_TPL1_MODE_CNTL registers.
    
    Fixes: 1d832ab30ce6 ("drm/msm/a5xx: Add support for Adreno 508, 509, 512 GPUs")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/522639/
    Link: https://lore.kernel.org/r/20230214020956.164473-3-dmitry.baryshkov@linaro.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/a5xx: fix setting of the CP_PREEMPT_ENABLE_LOCAL register [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Feb 14 05:09:53 2023 +0300

    drm/msm/a5xx: fix setting of the CP_PREEMPT_ENABLE_LOCAL register
    
    [ Upstream commit a7a4c19c36de1e4b99b06e4060ccc8ab837725bc ]
    
    Rather than writing CP_PREEMPT_ENABLE_GLOBAL twice, follow the vendor
    kernel and set CP_PREEMPT_ENABLE_LOCAL register instead. a5xx_submit()
    will override it during submission, but let's get the sequence correct.
    
    Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/522638/
    Link: https://lore.kernel.org/r/20230214020956.164473-2-dmitry.baryshkov@linaro.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/a5xx: fix the emptyness check in the preempt code [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Feb 14 05:09:55 2023 +0300

    drm/msm/a5xx: fix the emptyness check in the preempt code
    
    [ Upstream commit b4fb748f0b734ce1d2e7834998cc599fcbd25d67 ]
    
    Quoting Yassine: ring->memptrs->rptr is never updated and stays 0, so
    the comparison always evaluates to false and get_next_ring always
    returns ring 0 thinking it isn't empty.
    
    Fix this by calling get_rptr() instead of reading rptr directly.
    
    Reported-by: Yassine Oudjana <y.oudjana@protonmail.com>
    Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/522642/
    Link: https://lore.kernel.org/r/20230214020956.164473-4-dmitry.baryshkov@linaro.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/adreno: fix runtime PM imbalance at unbind [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Tue Feb 21 11:14:27 2023 +0100

    drm/msm/adreno: fix runtime PM imbalance at unbind
    
    [ Upstream commit 6153c44392b04ff2da1e9aa82ba87da9ab9a0fc1 ]
    
    A recent commit moved enabling of runtime PM from adreno_gpu_init() to
    adreno_load_gpu() (called on first open()), which means that unbind()
    may now be called with runtime PM disabled in case the device was never
    opened in between.
    
    Make sure to only forcibly suspend and disable runtime PM at unbind() in
    case runtime PM has been enabled to prevent a disable count imbalance.
    
    This specifically avoids leaving runtime PM disabled when the device
    is later opened after a successful bind:
    
            msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* Couldn't power up the GPU: -13
    
    Fixes: 4b18299b3365 ("drm/msm/adreno: Defer enabling runpm until hw_init()")
    Reported-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Link: https://lore.kernel.org/lkml/20230203181245.3523937-1-quic_bjorande@quicinc.com
    Cc: stable@vger.kernel.org      # 6.0
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Patchwork: https://patchwork.freedesktop.org/patch/523549/
    Link: https://lore.kernel.org/r/20230221101430.14546-2-johan+linaro@kernel.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dpu: clear DSPP reservations in rm release [+ + +]
Author: Kalyan Thota <quic_kalyant@quicinc.com>
Date:   Mon Feb 13 03:11:41 2023 -0800

    drm/msm/dpu: clear DSPP reservations in rm release
    
    [ Upstream commit 5ec498ba86550909f2611b07087d57a71a78c336 ]
    
    Clear DSPP reservations from the global state during
    rm release
    
    Fixes: e47616df008b ("drm/msm/dpu: add support for color processing blocks in dpu driver")
    Signed-off-by: Kalyan Thota <quic_kalyant@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Patchwork: https://patchwork.freedesktop.org/patch/522443/
    Link: https://lore.kernel.org/r/1676286704-818-2-git-send-email-quic_kalyant@quicinc.com
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: disable features unsupported by QCM2290 [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sun Feb 12 01:12:11 2023 +0200

    drm/msm/dpu: disable features unsupported by QCM2290
    
    [ Upstream commit a2a448b4d9bcb5bff0e0f687b7932a7be9ca898a ]
    
    QCM2290 doesn't seem to support reg-dma, UBWC and CSC. Drop
    corresponding features being incorrectly enabled for qcm2290.
    
    Cc: Loic Poulain <loic.poulain@linaro.org>
    Fixes: 5334087ee743 ("drm/msm: add support for QCM2290 MDSS")
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/522209/
    Link: https://lore.kernel.org/r/20230211231259.1308718-3-dmitry.baryshkov@linaro.org
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: drop DPU_DIM_LAYER from MIXER_MSM8998_MASK [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sun Feb 12 01:12:20 2023 +0200

    drm/msm/dpu: drop DPU_DIM_LAYER from MIXER_MSM8998_MASK
    
    [ Upstream commit a5045b00a68171de11603812f4304179ef608e60 ]
    
    The msm8998 doesn't seem to support DIM_LAYER, so drop it from
    the supported features mask.
    
    Fixes: 2d8a4edb672d ("drm/msm/dpu: use feature bit for LM combined alpha check")
    Fixes: 94391a14fc27 ("drm/msm/dpu1: Add MSM8998 to hw catalog")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/522231/
    Link: https://lore.kernel.org/r/20230211231259.1308718-12-dmitry.baryshkov@linaro.org
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: fix clocks settings for msm8998 SSPP blocks [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sun Feb 12 01:12:21 2023 +0200

    drm/msm/dpu: fix clocks settings for msm8998 SSPP blocks
    
    [ Upstream commit 0abb6a24aabc1252eae75fe23b0ccd3217c6ee07 ]
    
    DMA2 and DMA3 planes on msm8998 should use corresponding DMA2 and DMA3
    clocks rather than CURSOR0/1 clocks (which are used for the CURSOR
    planes). Correct corresponding SSPP declarations.
    
    Fixes: 94391a14fc27 ("drm/msm/dpu1: Add MSM8998 to hw catalog")
    Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
    Cc: Jami Kettunen <jami.kettunen@somainline.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/522230/
    Link: https://lore.kernel.org/r/20230211231259.1308718-13-dmitry.baryshkov@linaro.org
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: fix len of sc7180 ctl blocks [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sun Feb 12 01:12:13 2023 +0200

    drm/msm/dpu: fix len of sc7180 ctl blocks
    
    [ Upstream commit ce6bd00abc220e9edf10986234fadba6462b4abf ]
    
    Change sc7180's ctl block len to 0x1dc.
    
    Fixes: 7bdc0c4b8126 ("msm:disp:dpu1: add support for display for SC7180 target")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/522210/
    Link: https://lore.kernel.org/r/20230211231259.1308718-5-dmitry.baryshkov@linaro.org
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm: Fix potential invalid ptr free [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Wed Feb 15 15:50:48 2023 -0800

    drm/msm: Fix potential invalid ptr free
    
    [ Upstream commit 8a86f213f4426f19511a16d886871805b35c3acf ]
    
    The error path cleanup expects that chain and syncobj are either NULL or
    valid pointers.  But post_deps was not allocated with __GFP_ZERO.
    
    Fixes: ab723b7a992a ("drm/msm: Add syncobj support.")
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Patchwork: https://patchwork.freedesktop.org/patch/523051/
    Link: https://lore.kernel.org/r/20230215235048.1166484-1-robdclark@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/nouveau/kms/nv50: fix nv50_wndw_new_ prototype [+ + +]
Author: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Date:   Mon Oct 31 12:42:29 2022 +0100

    drm/nouveau/kms/nv50: fix nv50_wndw_new_ prototype
    
    [ Upstream commit 3638a820c5c3b52f327cebb174fd4274bee08aa7 ]
    
    gcc-13 warns about mismatching types for enums. That revealed switched
    arguments of nv50_wndw_new_():
      drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for 'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct nv50_wndw_func *, struct drm_device *, enum drm_plane_type,  const char *, int,  const u32 *, u32,  enum nv50_disp_interlock_type,  u32,  struct nv50_wndw **)'
      drivers/gpu/drm/nouveau/dispnv50/wndw.h:36:5: note: previous declaration of 'nv50_wndw_new_' with type 'int(const struct nv50_wndw_func *, struct drm_device *, enum drm_plane_type,  const char *, int,  const u32 *, enum nv50_disp_interlock_type,  u32,  u32,  struct nv50_wndw **)'
    
    It can be barely visible, but the declaration says about the parameters
    in the middle:
      enum nv50_disp_interlock_type,
      u32 interlock_data,
      u32 heads,
    
    While the definition states differently:
      u32 heads,
      enum nv50_disp_interlock_type interlock_type,
      u32 interlock_data,
    
    Unify/fix the declaration to match the definition.
    
    Fixes: 53e0a3e70de6 ("drm/nouveau/kms/nv50-: simplify tracking of channel interlocks")
    Cc: Martin Liska <mliska@suse.cz>
    Cc: Ben Skeggs <bskeggs@redhat.com>
    Cc: Karol Herbst <kherbst@redhat.com>
    Cc: Lyude Paul <lyude@redhat.com>
    Cc: David Airlie <airlied@gmail.com>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: dri-devel@lists.freedesktop.org
    Cc: nouveau@lists.freedesktop.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
    Signed-off-by: Karol Herbst <kherbst@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221031114229.10289-1-jirislaby@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
erofs: fix wrong kunmap when using LZMA on HIGHMEM platforms [+ + +]
Author: Gao Xiang <xiang@kernel.org>
Date:   Sun Mar 5 21:44:55 2023 +0800

    erofs: fix wrong kunmap when using LZMA on HIGHMEM platforms
    
    commit 8f121dfb15f7b4ab345992ce96003eb63fd608f4 upstream.
    
    As the call trace shown, the root cause is kunmap incorrect pages:
    
     BUG: kernel NULL pointer dereference, address: 00000000
     CPU: 1 PID: 40 Comm: kworker/u5:0 Not tainted 6.2.0-rc5 #4
     Workqueue: erofs_worker z_erofs_decompressqueue_work
     EIP: z_erofs_lzma_decompress+0x34b/0x8ac
      z_erofs_decompress+0x12/0x14
      z_erofs_decompress_queue+0x7e7/0xb1c
      z_erofs_decompressqueue_work+0x32/0x60
      process_one_work+0x24b/0x4d8
      ? process_one_work+0x1a4/0x4d8
      worker_thread+0x14c/0x3fc
      kthread+0xe6/0x10c
      ? rescuer_thread+0x358/0x358
      ? kthread_complete_and_exit+0x18/0x18
      ret_from_fork+0x1c/0x28
     ---[ end trace 0000000000000000 ]---
    
    The bug is trivial and should be fixed now.  It has no impact on
    !HIGHMEM platforms.
    
    Fixes: 622ceaddb764 ("erofs: lzma compression support")
    Cc: <stable@vger.kernel.org> # 5.16+
    Reviewed-by: Yue Hu <huyue2@coolpad.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20230305134455.88236-1-hsiangkao@linux.alibaba.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

erofs: Revert "erofs: fix kvcalloc() misuse with __GFP_NOFAIL" [+ + +]
Author: Gao Xiang <xiang@kernel.org>
Date:   Thu Mar 9 13:31:47 2023 +0800

    erofs: Revert "erofs: fix kvcalloc() misuse with __GFP_NOFAIL"
    
    [ Upstream commit 647dd2c3f0e16b71a1a77897d038164d48eea154 ]
    
    Let's revert commit 12724ba38992 ("erofs: fix kvcalloc() misuse with
    __GFP_NOFAIL") since kvmalloc() already supports __GFP_NOFAIL in commit
    a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc").  So
    the original fix was wrong.
    
    Actually there was some issue as [1] discussed, so before that mm fix
    is landed, the warn could still happen but applying this commit first
    will cause less.
    
    [1] https://lore.kernel.org/r/20230305053035.1911-1-hsiangkao@linux.alibaba.com
    
    Fixes: 12724ba38992 ("erofs: fix kvcalloc() misuse with __GFP_NOFAIL")
    Reviewed-by: Chao Yu <chao@kernel.org>
    Link: https://lore.kernel.org/r/20230309053148.9223-1-hsiangkao@linux.alibaba.com
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ethernet: ice: avoid gcc-9 integer overflow warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Feb 14 16:25:36 2023 +0100

    ethernet: ice: avoid gcc-9 integer overflow warning
    
    [ Upstream commit 8f5c5a790e3025d6eca96bf7ee5e3873dc92373f ]
    
    With older compilers like gcc-9, the calculation of the vlan
    priority field causes a false-positive warning from the byteswap:
    
    In file included from drivers/net/ethernet/intel/ice/ice_tc_lib.c:4:
    drivers/net/ethernet/intel/ice/ice_tc_lib.c: In function 'ice_parse_cls_flower':
    include/uapi/linux/swab.h:15:15: error: integer overflow in expression '(int)(short unsigned int)((int)match.key-><U67c8>.<U6698>.vlan_priority << 13) & 57344 & 255' of type 'int' results in '0' [-Werror=overflow]
       15 |  (((__u16)(x) & (__u16)0x00ffU) << 8) |   \
          |   ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
    include/uapi/linux/swab.h:106:2: note: in expansion of macro '___constant_swab16'
      106 |  ___constant_swab16(x) :   \
          |  ^~~~~~~~~~~~~~~~~~
    include/uapi/linux/byteorder/little_endian.h:42:43: note: in expansion of macro '__swab16'
       42 | #define __cpu_to_be16(x) ((__force __be16)__swab16((x)))
          |                                           ^~~~~~~~
    include/linux/byteorder/generic.h:96:21: note: in expansion of macro '__cpu_to_be16'
       96 | #define cpu_to_be16 __cpu_to_be16
          |                     ^~~~~~~~~~~~~
    drivers/net/ethernet/intel/ice/ice_tc_lib.c:1458:5: note: in expansion of macro 'cpu_to_be16'
     1458 |     cpu_to_be16((match.key->vlan_priority <<
          |     ^~~~~~~~~~~
    
    After a change to be16_encode_bits(), the code becomes more
    readable to both people and compilers, which avoids the warning.
    
    Fixes: 34800178b302 ("ice: Add support for VLAN priority filters in switchdev")
    Suggested-by: Alexander Lobakin <alexandr.lobakin@intel.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com>
    Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: fix another off-by-one fsmap error on 1k block filesystems [+ + +]
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Thu Feb 16 10:55:48 2023 -0800

    ext4: fix another off-by-one fsmap error on 1k block filesystems
    
    commit c993799baf9c5861f8df91beb80e1611b12efcbd upstream.
    
    Apparently syzbot figured out that issuing this FSMAP call:
    
    struct fsmap_head cmd = {
            .fmh_count      = ...;
            .fmh_keys       = {
                    { .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
                    { .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
            },
    ...
    };
    ret = ioctl(fd, FS_IOC_GETFSMAP, &cmd);
    
    Produces this crash if the underlying filesystem is a 1k-block ext4
    filesystem:
    
    kernel BUG at fs/ext4/ext4.h:3331!
    invalid opcode: 0000 [#1] PREEMPT SMP
    CPU: 3 PID: 3227965 Comm: xfs_io Tainted: G        W  O       6.2.0-rc8-achx
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
    RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4]
    RSP: 0018:ffffc90007c03998 EFLAGS: 00010246
    RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000
    RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11
    RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400
    R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001
    R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398
    FS:  00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0
    Call Trace:
     <TASK>
     ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
     ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
     ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
     ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
     __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]
     __x64_sys_ioctl+0x82/0xa0
     do_syscall_64+0x2b/0x80
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    RIP: 0033:0x7fdf20558aff
    RSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff
    RDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003
    RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010
    R13: 00005625be70d994 R14: 0000000000000800 R15: 0000000000000000
    
    For GETFSMAP calls, the caller selects a physical block device by
    writing its block number into fsmap_head.fmh_keys[01].fmr_device.
    To query mappings for a subrange of the device, the starting byte of the
    range is written to fsmap_head.fmh_keys[0].fmr_physical and the last
    byte of the range goes in fsmap_head.fmh_keys[1].fmr_physical.
    
    IOWs, to query what mappings overlap with bytes 3-14 of /dev/sda, you'd
    set the inputs as follows:
    
            fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3},
            fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14},
    
    Which would return you whatever is mapped in the 12 bytes starting at
    physical offset 3.
    
    The crash is due to insufficient range validation of keys[1] in
    ext4_getfsmap_datadev.  On 1k-block filesystems, block 0 is not part of
    the filesystem, which means that s_first_data_block is nonzero.
    ext4_get_group_no_and_offset subtracts this quantity from the blocknr
    argument before cracking it into a group number and a block number
    within a group.  IOWs, block group 0 spans blocks 1-8192 (1-based)
    instead of 0-8191 (0-based) like what happens with larger blocksizes.
    
    The net result of this encoding is that blocknr < s_first_data_block is
    not a valid input to this function.  The end_fsb variable is set from
    the keys that are copied from userspace, which means that in the above
    example, its value is zero.  That leads to an underflow here:
    
            blocknr = blocknr - le32_to_cpu(es->s_first_data_block);
    
    The division then operates on -1:
    
            offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >>
                    EXT4_SB(sb)->s_cluster_bits;
    
    Leaving an impossibly large group number (2^32-1) in blocknr.
    ext4_getfsmap_check_keys checked that keys[0].fmr_physical and
    keys[1].fmr_physical are in increasing order, but
    ext4_getfsmap_datadev adjusts keys[0].fmr_physical to be at least
    s_first_data_block.  This implies that we have to check it again after
    the adjustment, which is the piece that I forgot.
    
    Reported-by: syzbot+6be2b977c89f79b6b153@syzkaller.appspotmail.com
    Fixes: 4a4956249dac ("ext4: fix off-by-one fsmap error on 1k block filesystems")
    Link: https://syzkaller.appspot.com/bug?id=79d5768e9bfe362911ac1a5057a36fc6b5c30002
    Cc: stable@vger.kernel.org
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Link: https://lore.kernel.org/r/Y+58NPTH7VNGgzdd@magnolia
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix cgroup writeback accounting with fs-layer encryption [+ + +]
Author: Eric Biggers <ebiggers@google.com>
Date:   Thu Feb 2 16:55:03 2023 -0800

    ext4: fix cgroup writeback accounting with fs-layer encryption
    
    commit ffec85d53d0f39ee4680a2cf0795255e000e1feb upstream.
    
    When writing a page from an encrypted file that is using
    filesystem-layer encryption (not inline encryption), ext4 encrypts the
    pagecache page into a bounce page, then writes the bounce page.
    
    It also passes the bounce page to wbc_account_cgroup_owner().  That's
    incorrect, because the bounce page is a newly allocated temporary page
    that doesn't have the memory cgroup of the original pagecache page.
    This makes wbc_account_cgroup_owner() not account the I/O to the owner
    of the pagecache page as it should.
    
    Fix this by always passing the pagecache page to
    wbc_account_cgroup_owner().
    
    Fixes: 001e4a8775f6 ("ext4: implement cgroup writeback support")
    Cc: stable@vger.kernel.org
    Reported-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: https://lore.kernel.org/r/20230203005503.141557-1-ebiggers@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: Fix deadlock during directory rename [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Mar 1 15:10:04 2023 +0100

    ext4: Fix deadlock during directory rename
    
    [ Upstream commit 3c92792da8506a295afb6d032b4476e46f979725 ]
    
    As lockdep properly warns, we should not be locking i_rwsem while having
    transactions started as the proper lock ordering used by all directory
    handling operations is i_rwsem -> transaction start. Fix the lock
    ordering by moving the locking of the directory earlier in
    ext4_rename().
    
    Reported-by: syzbot+9d16c39efb5fade84574@syzkaller.appspotmail.com
    Fixes: 0813299c586b ("ext4: Fix possible corruption when moving a directory")
    Link: https://syzkaller.appspot.com/bug?extid=9d16c39efb5fade84574
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230301141004.15087-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: Fix possible corruption when moving a directory [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Thu Jan 26 12:22:21 2023 +0100

    ext4: Fix possible corruption when moving a directory
    
    [ Upstream commit 0813299c586b175d7edb25f56412c54b812d0379 ]
    
    When we are renaming a directory to a different directory, we need to
    update '..' entry in the moved directory. However nothing prevents moved
    directory from being modified and even converted from the inline format
    to the normal format. When such race happens the rename code gets
    confused and we crash. Fix the problem by locking the moved directory.
    
    CC: stable@vger.kernel.org
    Fixes: 32f7f22c0b52 ("ext4: let ext4_rename handle inline dir")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230126112221.11866-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix RENAME_WHITEOUT handling for inline directories [+ + +]
Author: Eric Whitney <enwlinux@gmail.com>
Date:   Fri Feb 10 12:32:44 2023 -0500

    ext4: fix RENAME_WHITEOUT handling for inline directories
    
    commit c9f62c8b2dbf7240536c0cc9a4529397bb8bf38e upstream.
    
    A significant number of xfstests can cause ext4 to log one or more
    warning messages when they are run on a test file system where the
    inline_data feature has been enabled.  An example:
    
    "EXT4-fs warning (device vdc): ext4_dirblock_csum_set:425: inode
     #16385: comm fsstress: No space for directory leaf checksum. Please
    run e2fsck -D."
    
    The xfstests include: ext4/057, 058, and 307; generic/013, 051, 068,
    070, 076, 078, 083, 232, 269, 270, 390, 461, 475, 476, 482, 579, 585,
    589, 626, 631, and 650.
    
    In this situation, the warning message indicates a bug in the code that
    performs the RENAME_WHITEOUT operation on a directory entry that has
    been stored inline.  It doesn't detect that the directory is stored
    inline, and incorrectly attempts to compute a dirent block checksum on
    the whiteout inode when creating it.  This attempt fails as a result
    of the integrity checking in get_dirent_tail (usually due to a failure
    to match the EXT4_FT_DIR_CSUM magic cookie), and the warning message
    is then emitted.
    
    Fix this by simply collecting the inlined data state at the time the
    search for the source directory entry is performed.  Existing code
    handles the rest, and this is sufficient to eliminate all spurious
    warning messages produced by the tests above.  Go one step further
    and do the same in the code that resets the source directory entry in
    the event of failure.  The inlined state should be present in the
    "old" struct, but given the possibility of a race there's no harm
    in taking a conservative approach and getting that information again
    since the directory entry is being reread anyway.
    
    Fixes: b7ff91fd030d ("ext4: find old entry again if failed to rename whiteout")
    Cc: stable@kernel.org
    Signed-off-by: Eric Whitney <enwlinux@gmail.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230210173244.679890-1-enwlinux@gmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix WARNING in ext4_update_inline_data [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Tue Mar 7 09:52:53 2023 +0800

    ext4: fix WARNING in ext4_update_inline_data
    
    commit 2b96b4a5d9443ca4cad58b0040be455803c05a42 upstream.
    
    Syzbot found the following issue:
    EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
    fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni"
    fscrypt: AES-256-XTS using implementation "xts-aes-aesni"
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
    Modules linked in:
    CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
    RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246
    RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000
    RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248
    RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220
    R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40
    R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c
    FS:  0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     __alloc_pages_node include/linux/gfp.h:237 [inline]
     alloc_pages_node include/linux/gfp.h:260 [inline]
     __kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113
     __do_kmalloc_node mm/slab_common.c:956 [inline]
     __kmalloc+0xfe/0x190 mm/slab_common.c:981
     kmalloc include/linux/slab.h:584 [inline]
     kzalloc include/linux/slab.h:720 [inline]
     ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346
     ext4_update_inline_dir fs/ext4/inline.c:1115 [inline]
     ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307
     ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385
     ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772
     ext4_create+0x36c/0x560 fs/ext4/namei.c:2817
     lookup_open fs/namei.c:3413 [inline]
     open_last_lookups fs/namei.c:3481 [inline]
     path_openat+0x12ac/0x2dd0 fs/namei.c:3711
     do_filp_open+0x264/0x4f0 fs/namei.c:3741
     do_sys_openat2+0x124/0x4e0 fs/open.c:1310
     do_sys_open fs/open.c:1326 [inline]
     __do_sys_openat fs/open.c:1342 [inline]
     __se_sys_openat fs/open.c:1337 [inline]
     __x64_sys_openat+0x243/0x290 fs/open.c:1337
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Above issue happens as follows:
    ext4_iget
       ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60
    ext4_try_add_inline_entry
       __ext4_mark_inode_dirty
          ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44
             ext4_xattr_shift_entries
             ->after shift i_inline_off is incorrect, actually is change to 176
    ext4_try_add_inline_entry
      ext4_update_inline_dir
        get_max_inline_xattr_value_size
          if (EXT4_I(inode)->i_inline_off)
            entry = (struct ext4_xattr_entry *)((void *)raw_inode +
                            EXT4_I(inode)->i_inline_off);
            free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size));
            ->As entry is incorrect, then 'free' may be negative
       ext4_update_inline_data
          value = kzalloc(len, GFP_NOFS);
          -> len is unsigned int, maybe very large, then trigger warning when
             'kzalloc()'
    
    To resolve the above issue we need to update 'i_inline_off' after
    'ext4_xattr_shift_entries()'.  We do not need to set
    EXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty()
    already sets this flag if needed.  Setting EXT4_STATE_MAY_INLINE_DATA
    when it is needed may trigger a BUG_ON in ext4_writepages().
    
    Reported-by: syzbot+d30838395804afc2fa6f@syzkaller.appspotmail.com
    Cc: stable@kernel.org
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230307015253.2232062-3-yebin@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: move where set the MAY_INLINE_DATA flag is set [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Tue Mar 7 09:52:52 2023 +0800

    ext4: move where set the MAY_INLINE_DATA flag is set
    
    commit 1dcdce5919115a471bf4921a57f20050c545a236 upstream.
    
    The only caller of ext4_find_inline_data_nolock() that needs setting of
    EXT4_STATE_MAY_INLINE_DATA flag is ext4_iget_extra_inode().  In
    ext4_write_inline_data_end() we just need to update inode->i_inline_off.
    Since we are going to add one more caller that does not need to set
    EXT4_STATE_MAY_INLINE_DATA, just move setting of EXT4_STATE_MAY_INLINE_DATA
    out to ext4_iget_extra_inode().
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Cc: stable@kernel.org
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230307015253.2232062-2-yebin@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: zero i_disksize when initializing the bootloader inode [+ + +]
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Wed Mar 8 11:26:43 2023 +0800

    ext4: zero i_disksize when initializing the bootloader inode
    
    commit f5361da1e60d54ec81346aee8e3d8baf1be0b762 upstream.
    
    If the boot loader inode has never been used before, the
    EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the
    i_size to 0.  However, if the "never before used" boot loader has a
    non-zero i_size, then i_disksize will be non-zero, and the
    inconsistency between i_size and i_disksize can trigger a kernel
    warning:
    
     WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319
     CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa
     RIP: 0010:ext4_file_write_iter+0xbc7/0xd10
     Call Trace:
      vfs_write+0x3b1/0x5c0
      ksys_write+0x77/0x160
      __x64_sys_write+0x22/0x30
      do_syscall_64+0x39/0x80
    
    Reproducer:
     1. create corrupted image and mount it:
           mke2fs -t ext4 /tmp/foo.img 200
           debugfs -wR "sif <5> size 25700" /tmp/foo.img
           mount -t ext4 /tmp/foo.img /mnt
           cd /mnt
           echo 123 > file
     2. Run the reproducer program:
           posix_memalign(&buf, 1024, 1024)
           fd = open("file", O_RDWR | O_DIRECT);
           ioctl(fd, EXT4_IOC_SWAP_BOOT);
           write(fd, buf, 1024);
    
    Fix this by setting i_disksize as well as i_size to zero when
    initiaizing the boot loader inode.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159
    Cc: stable@kernel.org
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Link: https://lore.kernel.org/r/20230308032643.641113-1-chengzhihao1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fd: dlm: trace send/recv of dlm message and rcom [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Oct 27 16:45:15 2022 -0400

    fd: dlm: trace send/recv of dlm message and rcom
    
    [ Upstream commit e01c4b7bd41522ae0299c07e2ee8c721fee02595 ]
    
    This patch adds tracepoints for send and recv cases of dlm messages and
    dlm rcom messages. In case of send and dlm message we add the dlm rsb
    resource name this dlm messages belongs to. This has the advantage to
    follow dlm messages on a per lock basis. In case of recv message the
    resource name can be extracted by follow the send message sequence
    number.
    
    The dlm message DLM_MSG_PURGE doesn't belong to a lock request and will
    not set the resource name in a dlm_message trace. The same for all rcom
    messages.
    
    There is additional handling required for this debugging functionality
    which is tried to be small as possible. Also the midcomms layer gets
    aware of lock resource names, for now this is required to make a
    connection between sequence number and lock resource names. It is for
    debugging purpose only.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Stable-dep-of: 724b6bab0d75 ("fs: dlm: fix use after free in midcomms commit")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
filelocks: use mount idmapping for setlease permission check [+ + +]
Author: Seth Forshee <sforshee@kernel.org>
Date:   Thu Mar 9 14:39:09 2023 -0600

    filelocks: use mount idmapping for setlease permission check
    
    commit 42d0c4bdf753063b6eec55415003184d3ca24f6e upstream.
    
    A user should be allowed to take out a lease via an idmapped mount if
    the fsuid matches the mapped uid of the inode. generic_setlease() is
    checking the unmapped inode uid, causing these operations to be denied.
    
    Fix this by comparing against the mapped inode uid instead of the
    unmapped uid.
    
    Fixes: 9caccd41541a ("fs: introduce MOUNT_ATTR_IDMAP")
    Cc: stable@vger.kernel.org
    Signed-off-by: Seth Forshee (DigitalOcean) <sforshee@kernel.org>
    Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fork: allow CLONE_NEWTIME in clone3 flags [+ + +]
Author: Tobias Klauser <tklauser@distanz.ch>
Date:   Wed Mar 8 11:51:26 2023 +0100

    fork: allow CLONE_NEWTIME in clone3 flags
    
    commit a402f1e35313fc7ce2ca60f543c4402c2c7c3544 upstream.
    
    Currently, calling clone3() with CLONE_NEWTIME in clone_args->flags
    fails with -EINVAL. This is because CLONE_NEWTIME intersects with
    CSIGNAL. However, CSIGNAL was deprecated when clone3 was introduced in
    commit 7f192e3cd316 ("fork: add clone3"), allowing re-use of that part
    of clone flags.
    
    Fix this by explicitly allowing CLONE_NEWTIME in clone3_args_valid. This
    is also in line with the respective check in check_unshare_flags which
    allow CLONE_NEWTIME for unshare().
    
    Fixes: 769071ac9f20 ("ns: Introduce Time Namespace")
    Cc: Andrey Vagin <avagin@openvz.org>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
    Reviewed-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fs: dlm: add midcomms init/start functions [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Nov 17 17:11:46 2022 -0500

    fs: dlm: add midcomms init/start functions
    
    [ Upstream commit 8b0188b0d60b6f6183b48380bac49fe080c5ded9 ]
    
    This patch introduces leftovers of init, start, stop and exit
    functionality. The dlm application layer should always call the midcomms
    layer which getting aware of such event and redirect it to the lowcomms
    layer. Some functionality which is currently handled inside the start
    functionality of midcomms and lowcomms should be handled in the init
    functionality as it only need to be initialized once when dlm is loaded.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Stable-dep-of: aad633dc0cf9 ("fs: dlm: start midcomms before scand")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: dlm: be sure to call dlm_send_queue_flush() [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Jan 12 17:10:33 2023 -0500

    fs: dlm: be sure to call dlm_send_queue_flush()
    
    [ Upstream commit 7354fa4ef697191effedc2ae9a8293427708bbf5 ]
    
    If we release a midcomms node structure, there should be nothing left
    inside the dlm midcomms send queue. However, sometimes this is not true
    because I believe some DLM_FIN message was not acked... if we run
    into a shutdown timeout, then we should be sure there is no pending send
    dlm message inside this queue when releasing midcomms node structure.
    
    Cc: stable@vger.kernel.org
    Fixes: 489d8e559c65 ("fs: dlm: add reliable connection if reconnect")
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: dlm: fix log of lowcomms vs midcomms [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Oct 27 16:45:26 2022 -0400

    fs: dlm: fix log of lowcomms vs midcomms
    
    [ Upstream commit 3e54c9e80e68b765d8877023d93f1eea1b9d1c54 ]
    
    This patch will fix a small issue when printing out that
    dlm_midcomms_start() failed to start and it was printing out that the
    dlm subcomponent lowcomms was failed but lowcomms is behind the midcomms
    layer.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Stable-dep-of: aad633dc0cf9 ("fs: dlm: start midcomms before scand")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: dlm: fix race setting stop tx flag [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Jan 12 17:10:34 2023 -0500

    fs: dlm: fix race setting stop tx flag
    
    [ Upstream commit 164272113b685927126c938b4a9cbd2075eb15ee ]
    
    This patch sets the stop tx flag before we commit the dlm message.
    This flag will report about unexpected transmissions after we
    send the DLM_FIN message out, which should be the last message sent.
    When we commit the dlm fin message, it could be that we already
    got an ack back and the CLOSED state change already happened.
    We should not set this flag when we are in CLOSED state. To avoid this
    race we simply set the tx flag before the state change can be in
    progress by moving it before dlm_midcomms_commit_mhandle().
    
    Cc: stable@vger.kernel.org
    Fixes: 489d8e559c65 ("fs: dlm: add reliable connection if reconnect")
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: dlm: fix use after free in midcomms commit [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Jan 12 17:10:32 2023 -0500

    fs: dlm: fix use after free in midcomms commit
    
    [ Upstream commit 724b6bab0d75f1dc01fdfbf7fe8d4217a5cb90ba ]
    
    While working on processing dlm message in softirq context I experienced
    the following KASAN use-after-free warning:
    
    [  151.760477] ==================================================================
    [  151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0
    [  151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347
    
    [  151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828
    [  151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014
    [  151.768726] Call Trace:
    [  151.769277]  <TASK>
    [  151.769748]  dump_stack_lvl+0x5b/0x86
    [  151.770556]  print_report+0x180/0x4c8
    [  151.771378]  ? kasan_complete_mode_report_info+0x7c/0x1e0
    [  151.772241]  ? dlm_midcomms_commit_mhandle+0x19d/0x4b0
    [  151.773069]  kasan_report+0x93/0x1a0
    [  151.773668]  ? dlm_midcomms_commit_mhandle+0x19d/0x4b0
    [  151.774514]  __asan_load4+0x7e/0xa0
    [  151.775089]  dlm_midcomms_commit_mhandle+0x19d/0x4b0
    [  151.775890]  ? create_message.isra.29.constprop.64+0x57/0xc0
    [  151.776770]  send_common+0x19f/0x1b0
    [  151.777342]  ? remove_from_waiters+0x60/0x60
    [  151.778017]  ? lock_downgrade+0x410/0x410
    [  151.778648]  ? __this_cpu_preempt_check+0x13/0x20
    [  151.779421]  ? rcu_lockdep_current_cpu_online+0x88/0xc0
    [  151.780292]  _convert_lock+0x46/0x150
    [  151.780893]  convert_lock+0x7b/0xc0
    [  151.781459]  dlm_lock+0x3ac/0x580
    [  151.781993]  ? 0xffffffffc0540000
    [  151.782522]  ? torture_stop+0x120/0x120 [dlm_locktorture]
    [  151.783379]  ? dlm_scan_rsbs+0xa70/0xa70
    [  151.784003]  ? preempt_count_sub+0xd6/0x130
    [  151.784661]  ? is_module_address+0x47/0x70
    [  151.785309]  ? torture_stop+0x120/0x120 [dlm_locktorture]
    [  151.786166]  ? 0xffffffffc0540000
    [  151.786693]  ? lockdep_init_map_type+0xc3/0x360
    [  151.787414]  ? 0xffffffffc0540000
    [  151.787947]  torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture]
    [  151.789004]  ? torture_stop+0x120/0x120 [dlm_locktorture]
    [  151.789858]  ? 0xffffffffc0540000
    [  151.790392]  ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture]
    [  151.791347]  ? delay_tsc+0x94/0xc0
    [  151.791898]  torture_ex_iter+0xc3/0xea [dlm_locktorture]
    [  151.792735]  ? torture_start+0x30/0x30 [dlm_locktorture]
    [  151.793606]  lock_torture+0x177/0x270 [dlm_locktorture]
    [  151.794448]  ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture]
    [  151.795539]  ? lock_torture_stats+0x80/0x80 [dlm_locktorture]
    [  151.796476]  ? do_raw_spin_lock+0x11e/0x1e0
    [  151.797152]  ? mark_held_locks+0x34/0xb0
    [  151.797784]  ? _raw_spin_unlock_irqrestore+0x30/0x70
    [  151.798581]  ? __kthread_parkme+0x79/0x110
    [  151.799246]  ? trace_preempt_on+0x2a/0xf0
    [  151.799902]  ? __kthread_parkme+0x79/0x110
    [  151.800579]  ? preempt_count_sub+0xd6/0x130
    [  151.801271]  ? __kasan_check_read+0x11/0x20
    [  151.801963]  ? __kthread_parkme+0xec/0x110
    [  151.802630]  ? lock_torture_stats+0x80/0x80 [dlm_locktorture]
    [  151.803569]  kthread+0x192/0x1d0
    [  151.804104]  ? kthread_complete_and_exit+0x30/0x30
    [  151.804881]  ret_from_fork+0x1f/0x30
    [  151.805480]  </TASK>
    
    [  151.806111] Allocated by task 1347:
    [  151.806681]  kasan_save_stack+0x26/0x50
    [  151.807308]  kasan_set_track+0x25/0x30
    [  151.807920]  kasan_save_alloc_info+0x1e/0x30
    [  151.808609]  __kasan_slab_alloc+0x63/0x80
    [  151.809263]  kmem_cache_alloc+0x1ad/0x830
    [  151.809916]  dlm_allocate_mhandle+0x17/0x20
    [  151.810590]  dlm_midcomms_get_mhandle+0x96/0x260
    [  151.811344]  _create_message+0x95/0x180
    [  151.811994]  create_message.isra.29.constprop.64+0x57/0xc0
    [  151.812880]  send_common+0x129/0x1b0
    [  151.813467]  _convert_lock+0x46/0x150
    [  151.814074]  convert_lock+0x7b/0xc0
    [  151.814648]  dlm_lock+0x3ac/0x580
    [  151.815199]  torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture]
    [  151.816258]  torture_ex_iter+0xc3/0xea [dlm_locktorture]
    [  151.817129]  lock_torture+0x177/0x270 [dlm_locktorture]
    [  151.817986]  kthread+0x192/0x1d0
    [  151.818518]  ret_from_fork+0x1f/0x30
    
    [  151.819369] Freed by task 1336:
    [  151.819890]  kasan_save_stack+0x26/0x50
    [  151.820514]  kasan_set_track+0x25/0x30
    [  151.821128]  kasan_save_free_info+0x2e/0x50
    [  151.821812]  __kasan_slab_free+0x107/0x1a0
    [  151.822483]  kmem_cache_free+0x204/0x5e0
    [  151.823152]  dlm_free_mhandle+0x18/0x20
    [  151.823781]  dlm_mhandle_release+0x2e/0x40
    [  151.824454]  rcu_core+0x583/0x1330
    [  151.825047]  rcu_core_si+0xe/0x20
    [  151.825594]  __do_softirq+0xf4/0x5c2
    
    [  151.826450] Last potentially related work creation:
    [  151.827238]  kasan_save_stack+0x26/0x50
    [  151.827870]  __kasan_record_aux_stack+0xa2/0xc0
    [  151.828609]  kasan_record_aux_stack_noalloc+0xb/0x20
    [  151.829415]  call_rcu+0x4c/0x760
    [  151.829954]  dlm_mhandle_delete+0x97/0xb0
    [  151.830718]  dlm_process_incoming_buffer+0x2fc/0xb30
    [  151.831524]  process_dlm_messages+0x16e/0x470
    [  151.832245]  process_one_work+0x505/0xa10
    [  151.832905]  worker_thread+0x67/0x650
    [  151.833507]  kthread+0x192/0x1d0
    [  151.834046]  ret_from_fork+0x1f/0x30
    
    [  151.834900] The buggy address belongs to the object at ffff88811a980c30
                    which belongs to the cache dlm_mhandle of size 88
    [  151.836894] The buggy address is located 48 bytes inside of
                    88-byte region [ffff88811a980c30, ffff88811a980c88)
    
    [  151.839007] The buggy address belongs to the physical page:
    [  151.839904] page:0000000076cf5d62 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11a980
    [  151.841378] flags: 0x8000000000000200(slab|zone=2)
    [  151.842141] raw: 8000000000000200 0000000000000000 dead000000000122 ffff8881089b43c0
    [  151.843401] raw: 0000000000000000 0000000000220022 00000001ffffffff 0000000000000000
    [  151.844640] page dumped because: kasan: bad access detected
    
    [  151.845822] Memory state around the buggy address:
    [  151.846602]  ffff88811a980b00: fb fb fb fb fc fc fc fc fa fb fb fb fb fb fb fb
    [  151.847761]  ffff88811a980b80: fb fb fb fc fc fc fc fa fb fb fb fb fb fb fb fb
    [  151.848921] >ffff88811a980c00: fb fb fc fc fc fc fa fb fb fb fb fb fb fb fb fb
    [  151.850076]                                                        ^
    [  151.851085]  ffff88811a980c80: fb fc fc fc fc fa fb fb fb fb fb fb fb fb fb fb
    [  151.852269]  ffff88811a980d00: fc fc fc fc fa fb fb fb fb fb fb fb fb fb fb fc
    [  151.853428] ==================================================================
    [  151.855618] Disabling lock debugging due to kernel taint
    
    It is accessing a mhandle in dlm_midcomms_commit_mhandle() and the mhandle
    was freed by a call_rcu() call in dlm_process_incoming_buffer(),
    dlm_mhandle_delete(). It looks like it was freed because an ack of
    this message was received. There is a short race between committing the
    dlm message to be transmitted and getting an ack back. If the ack is
    faster than returning from dlm_midcomms_commit_msg_3_2(), then we run
    into a use-after free because we still need to reference the mhandle when
    calling srcu_read_unlock().
    
    To avoid that, we don't allow that mhandle to be freed between
    dlm_midcomms_commit_msg_3_2() and srcu_read_unlock() by using rcu read
    lock. We can do that because mhandle is protected by rcu handling.
    
    Cc: stable@vger.kernel.org
    Fixes: 489d8e559c65 ("fs: dlm: add reliable connection if reconnect")
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: dlm: remove send repeat remove handling [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Oct 27 16:45:13 2022 -0400

    fs: dlm: remove send repeat remove handling
    
    [ Upstream commit 57a5724ef0b332eb6e78250157910a006b01bf6e ]
    
    This patch removes the send repeat remove handling. This handling is
    there to repeatingly DLM_MSG_REMOVE messages in cases the dlm stack
    thinks it was not received at the first time. In cases of message drops
    this functionality is necessary, but since the DLM midcomms layer
    guarantees there are no messages drops between cluster nodes this
    feature became not strict necessary anymore. Due message
    delays/processing it could be that two send_repeat_remove() are sent out
    while the other should be still on it's way. We remove the repeat remove
    handling because we are sure that the message cannot be dropped due
    communication errors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Stable-dep-of: 724b6bab0d75 ("fs: dlm: fix use after free in midcomms commit")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: dlm: start midcomms before scand [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Jan 12 17:10:31 2023 -0500

    fs: dlm: start midcomms before scand
    
    [ Upstream commit aad633dc0cf90093998b1ae0ba9f19b5f1dab644 ]
    
    The scand kthread can send dlm messages out, especially dlm remove
    messages to free memory for unused rsb on other nodes. To send out dlm
    messages, midcomms must be initialized. This patch moves the midcomms
    start before scand is started.
    
    Cc: stable@vger.kernel.org
    Fixes: e7fd41792fc0 ("[DLM] The core of the DLM for GFS2/CLVM")
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: dlm: use packet in dlm_mhandle [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Oct 27 16:45:14 2022 -0400

    fs: dlm: use packet in dlm_mhandle
    
    [ Upstream commit 5b787667e87a373a2f8f70e6be2b5d99c408462f ]
    
    To allow more than just dereferencing the inner header we directly point
    to the inner dlm packet which allows us to dereference the header, rcom
    or message structure.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Stable-dep-of: 724b6bab0d75 ("fs: dlm: fix use after free in midcomms commit")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: dlm: use WARN_ON_ONCE() instead of WARN_ON() [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Oct 27 16:45:27 2022 -0400

    fs: dlm: use WARN_ON_ONCE() instead of WARN_ON()
    
    [ Upstream commit 775af207464bd28a2086f8399c0b2a3f1f40c7ae ]
    
    To not get the console spammed about WARN_ON() of invalid states in the
    dlm midcomms hot path handling we switch to WARN_ON_ONCE() to get it
    only once that there might be an issue with the midcomms state handling.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Stable-dep-of: 7354fa4ef697 ("fs: dlm: be sure to call dlm_send_queue_flush()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: prevent out-of-bounds array speculation when closing a file descriptor [+ + +]
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Mon Mar 6 13:54:50 2023 -0500

    fs: prevent out-of-bounds array speculation when closing a file descriptor
    
    commit 609d54441493c99f21c1823dfd66fa7f4c512ff4 upstream.
    
    Google-Bug-Id: 114199369
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
HID: core: Provide new max_buffer_size attribute to over-ride the default [+ + +]
Author: Lee Jones <lee@kernel.org>
Date:   Mon Jan 23 12:39:11 2023 +0000

    HID: core: Provide new max_buffer_size attribute to over-ride the default
    
    commit b1a37ed00d7908a991c1d0f18a8cba3c2aa99bdc upstream.
    
    Presently, when a report is processed, its proposed size, provided by
    the user of the API (as Report Size * Report Count) is compared against
    the subsystem default HID_MAX_BUFFER_SIZE (16k).  However, some
    low-level HID drivers allocate a reduced amount of memory to their
    buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
    this check inadequate in some cases.
    
    In these circumstances, if the received report ends up being smaller
    than the proposed report size, the remainder of the buffer is zeroed.
    That is, the space between sizeof(csize) (size of the current report)
    and the rsize (size proposed i.e. Report Size * Report Count), which can
    be handled up to HID_MAX_BUFFER_SIZE (16k).  Meaning that memset()
    shoots straight past the end of the buffer boundary and starts zeroing
    out in-use values, often resulting in calamity.
    
    This patch introduces a new variable into 'struct hid_ll_driver' where
    individual low-level drivers can over-ride the default maximum value of
    HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
    interface.
    
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: uhid: Over-ride the default maximum data buffer value with our own [+ + +]
Author: Lee Jones <lee@kernel.org>
Date:   Mon Jan 23 12:39:12 2023 +0000

    HID: uhid: Over-ride the default maximum data buffer value with our own
    
    commit 1c5d4221240a233df2440fe75c881465cdf8da07 upstream.
    
    The default maximum data buffer size for this interface is UHID_DATA_MAX
    (4k).  When data buffers are being processed, ensure this value is used
    when ensuring the sanity, rather than a value between the user provided
    value and HID_MAX_BUFFER_SIZE (16k).
    
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ice: copy last block omitted in ice_get_module_eeprom() [+ + +]
Author: Petr Oros <poros@redhat.com>
Date:   Wed Mar 1 21:47:07 2023 +0100

    ice: copy last block omitted in ice_get_module_eeprom()
    
    [ Upstream commit 84cba1840e68430325ac133a11be06bfb2f7acd8 ]
    
    ice_get_module_eeprom() is broken since commit e9c9692c8a81 ("ice:
    Reimplement module reads used by ethtool") In this refactor,
    ice_get_module_eeprom() reads the eeprom in blocks of size 8.
    But the condition that should protect the buffer overflow
    ignores the last block. The last block always contains zeros.
    
    Bug uncovered by ethtool upstream commit 9538f384b535
    ("netlink: eeprom: Defer page requests to individual parsers")
    After this commit, ethtool reads a block with length = 1;
    to read the SFF-8024 identifier value.
    
    unpatched driver:
    $ ethtool -m enp65s0f0np0 offset 0x90 length 8
    Offset          Values
    ------          ------
    0x0090:         00 00 00 00 00 00 00 00
    $ ethtool -m enp65s0f0np0 offset 0x90 length 12
    Offset          Values
    ------          ------
    0x0090:         00 00 01 a0 4d 65 6c 6c 00 00 00 00
    $
    
    $ ethtool -m enp65s0f0np0
    Offset          Values
    ------          ------
    0x0000:         11 06 06 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0010:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0020:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0030:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0040:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0050:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0060:         00 00 00 00 00 00 00 00 00 00 00 00 00 01 08 00
    0x0070:         00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
    patched driver:
    $ ethtool -m enp65s0f0np0 offset 0x90 length 8
    Offset          Values
    ------          ------
    0x0090:         00 00 01 a0 4d 65 6c 6c
    $ ethtool -m enp65s0f0np0 offset 0x90 length 12
    Offset          Values
    ------          ------
    0x0090:         00 00 01 a0 4d 65 6c 6c 61 6e 6f 78
    $ ethtool -m enp65s0f0np0
        Identifier                                : 0x11 (QSFP28)
        Extended identifier                       : 0x00
        Extended identifier description           : 1.5W max. Power consumption
        Extended identifier description           : No CDR in TX, No CDR in RX
        Extended identifier description           : High Power Class (> 3.5 W) not enabled
        Connector                                 : 0x23 (No separable connector)
        Transceiver codes                         : 0x88 0x00 0x00 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : 40G Ethernet: 40G Base-CR4
        Transceiver type                          : 25G Ethernet: 25G Base-CR CA-N
        Encoding                                  : 0x05 (64B/66B)
        BR, Nominal                               : 25500Mbps
        Rate identifier                           : 0x00
        Length (SMF,km)                           : 0km
        Length (OM3 50um)                         : 0m
        Length (OM2 50um)                         : 0m
        Length (OM1 62.5um)                       : 0m
        Length (Copper or Active cable)           : 1m
        Transmitter technology                    : 0xa0 (Copper cable unequalized)
        Attenuation at 2.5GHz                     : 4db
        Attenuation at 5.0GHz                     : 5db
        Attenuation at 7.0GHz                     : 7db
        Attenuation at 12.9GHz                    : 10db
        ........
        ....
    
    Fixes: e9c9692c8a81 ("ice: Reimplement module reads used by ethtool")
    Signed-off-by: Petr Oros <poros@redhat.com>
    Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Tested-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: Fix DSCP PFC TLV creation [+ + +]
Author: Dave Ertman <david.m.ertman@intel.com>
Date:   Fri Jan 27 14:24:10 2023 +0100

    ice: Fix DSCP PFC TLV creation
    
    [ Upstream commit fef3f92e8a4214652d8f33f50330dc5a92efbf11 ]
    
    When creating the TLV to send to the FW for configuring DSCP mode PFC,the
    PFCENABLE field was being masked with a 4 bit mask (0xF), but this is an 8
    bit bitmask for enabled classes for PFC.  This means that traffic classes
    4-7 could not be enabled for PFC.
    
    Remove the mask completely, as it is not necessary, as we are assigning 8
    bits to an 8 bit field.
    
    Fixes: 2a87bd73e50d ("ice: Add DSCP support")
    Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
    Signed-off-by: Karen Ostrowska <karen.ostrowska@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>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Feb 27 15:30:24 2023 +0000

    ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()
    
    [ Upstream commit 693aa2c0d9b6d5b1f2745d31b6e70d09dbbaf06e ]
    
    ila_xlat_nl_cmd_get_mapping() generates an empty skb,
    triggerring a recent sanity check [1].
    
    Instead, return an error code, so that user space
    can get it.
    
    [1]
    skb_assert_len
    WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline]
    WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
    Modules linked in:
    CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023
    pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : skb_assert_len include/linux/skbuff.h:2527 [inline]
    pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
    lr : skb_assert_len include/linux/skbuff.h:2527 [inline]
    lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
    sp : ffff80001e0d6c40
    x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0
    x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00
    x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10
    x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0
    x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000
    x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001
    x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600
    x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001
    x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744
    x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000e
    Call trace:
    skb_assert_len include/linux/skbuff.h:2527 [inline]
    __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
    dev_queue_xmit include/linux/netdevice.h:3033 [inline]
    __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline]
    __netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325
    netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338
    __netlink_sendskb net/netlink/af_netlink.c:1283 [inline]
    netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292
    netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380
    nlmsg_unicast include/net/netlink.h:1099 [inline]
    genlmsg_unicast include/net/genetlink.h:433 [inline]
    genlmsg_reply include/net/genetlink.h:443 [inline]
    ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493
    genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]
    genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]
    genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065
    netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574
    genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076
    netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
    netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365
    netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg net/socket.c:734 [inline]
    ____sys_sendmsg+0x558/0x844 net/socket.c:2479
    ___sys_sendmsg net/socket.c:2533 [inline]
    __sys_sendmsg+0x26c/0x33c net/socket.c:2562
    __do_sys_sendmsg net/socket.c:2571 [inline]
    __se_sys_sendmsg net/socket.c:2569 [inline]
    __arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569
    __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
    invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
    el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142
    do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193
    el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637
    el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
    el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
    irq event stamp: 136484
    hardirqs last enabled at (136483): [<ffff800008350244>] __up_console_sem+0x60/0xb4 kernel/printk/printk.c:345
    hardirqs last disabled at (136484): [<ffff800012358d60>] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:405
    softirqs last enabled at (136418): [<ffff800008020ea8>] softirq_handle_end kernel/softirq.c:414 [inline]
    softirqs last enabled at (136418): [<ffff800008020ea8>] __do_softirq+0xd4c/0xfa4 kernel/softirq.c:600
    softirqs last disabled at (136371): [<ffff80000802b4a4>] ____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:80
    ---[ end trace 0000000000000000 ]---
    skb len=0 headroom=0 headlen=0 tailroom=192
    mac=(0,0) net=(0,-1) trans=-1
    shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
    csum(0x0 ip_summed=0 complete_sw=0 valid=0 level=0)
    hash(0x0 sw=0 l4=0) proto=0x0010 pkttype=6 iif=0
    dev name=nlmon0 feat=0x0000000000005861
    
    Fixes: 7f00feaf1076 ("ila: Add generic ILA translation facility")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: exc3000 - properly stop timer on shutdown [+ + +]
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Feb 3 16:43:29 2023 -0800

    Input: exc3000 - properly stop timer on shutdown
    
    [ Upstream commit 79c81d137d36f9635bbcbc3916c0cccb418a61dd ]
    
    We need to stop the timer on driver unbind or probe failures, otherwise
    we get UAF/Oops.
    
    Fixes: 7e577a17f2ee ("Input: add I2C attached EETI EXC3000 multi touch driver")
    Reported-by: "Stahl, Michael" <mstahl@moba.de>
    Link: https://lore.kernel.org/r/Y9dK57BFqtlf8NmN@google.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring/uring_cmd: ensure that device supports IOPOLL [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Mar 8 09:26:13 2023 -0700

    io_uring/uring_cmd: ensure that device supports IOPOLL
    
    commit 03b3d6be73e81ddb7c2930d942cdd17f4cfd5ba5 upstream.
    
    It's possible for a file type to support uring commands, but not
    pollable ones. Hence before issuing one of those, we should check
    that it is supported and error out upfront if it isn't.
    
    Cc: stable@vger.kernel.org
    Fixes: 5756a3a7e713 ("io_uring: add iopoll infrastructure for io_uring_cmd")
    Link: https://github.com/axboe/liburing/issues/816
    Reviewed-by: Kanchan Joshi <joshi.k@samsung.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: ipmi:ssif: Add a timer between request retries [+ + +]
Author: Corey Minyard <cminyard@mvista.com>
Date:   Wed Jan 25 10:34:47 2023 -0600

    ipmi:ssif: Add a timer between request retries
    
    [ Upstream commit 00bb7e763ec9f384cb382455cb6ba5588b5375cf ]
    
    The IPMI spec has a time (T6) specified between request retries.  Add
    the handling for that.
    
    Reported by: Tony Camuso <tcamuso@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Linux: ipmi:ssif: Increase the message retry time [+ + +]
Author: Corey Minyard <cminyard@mvista.com>
Date:   Thu Nov 3 15:03:11 2022 -0500

    ipmi:ssif: Increase the message retry time
    
    [ Upstream commit 39721d62bbc16ebc9bb2bdc2c163658f33da3b0b ]
    
    The spec states that the minimum message retry time is 60ms, but it was
    set to 20ms.  Correct it.
    
    Reported by: Tony Camuso <tcamuso@redhat.com>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Stable-dep-of: 00bb7e763ec9 ("ipmi:ssif: Add a timer between request retries")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Linux: ipmi:ssif: Remove rtc_us_timer [+ + +]
Author: Corey Minyard <cminyard@mvista.com>
Date:   Wed Jan 25 10:41:48 2023 -0600

    ipmi:ssif: Remove rtc_us_timer
    
    [ Upstream commit 9e8b89926fb87e5625bdde6fd5de2c31fb1d83bf ]
    
    It was cruft left over from older handling of run to completion.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Wed Nov 30 23:08:58 2022 +0000

    KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace
    
    [ Upstream commit e32b120071ea114efc0b4ddd439547750b85f618 ]
    
    Call kvm_init() only after _all_ setup is complete, as kvm_init() exposes
    /dev/kvm to userspace and thus allows userspace to create VMs (and call
    other ioctls).  E.g. KVM will encounter a NULL pointer when attempting to
    add a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able to
    create a VM before vmx_init() configures said list.
    
     BUG: kernel NULL pointer dereference, address: 0000000000000008
     #PF: supervisor write access in kernel mode
     #PF: error_code(0x0002) - not-present page
     PGD 0 P4D 0
     Oops: 0002 [#1] SMP
     CPU: 6 PID: 1143 Comm: stable Not tainted 6.0.0-rc7+ #988
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
     RIP: 0010:vmx_vcpu_load_vmcs+0x68/0x230 [kvm_intel]
      <TASK>
      vmx_vcpu_load+0x16/0x60 [kvm_intel]
      kvm_arch_vcpu_load+0x32/0x1f0 [kvm]
      vcpu_load+0x2f/0x40 [kvm]
      kvm_arch_vcpu_create+0x231/0x310 [kvm]
      kvm_vm_ioctl+0x79f/0xe10 [kvm]
      ? handle_mm_fault+0xb1/0x220
      __x64_sys_ioctl+0x80/0xb0
      do_syscall_64+0x2b/0x50
      entry_SYSCALL_64_after_hwframe+0x46/0xb0
     RIP: 0033:0x7f5a6b05743b
      </TASK>
     Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel(+) kvm irqbypass
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20221130230934.1014142-15-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: VMX: Don't bother disabling eVMCS static key on module exit [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Wed Nov 30 23:08:55 2022 +0000

    KVM: VMX: Don't bother disabling eVMCS static key on module exit
    
    [ Upstream commit da66de44b01e9b7fa09731057593850394bf32e4 ]
    
    Don't disable the eVMCS static key on module exit, kvm_intel.ko owns the
    key so there can't possibly be users after the kvm_intel.ko is unloaded,
    at least not without much bigger issues.
    
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20221130230934.1014142-12-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Stable-dep-of: e32b120071ea ("KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: VMX: Reset eVMCS controls in VP assist page during hardware disabling [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Wed Nov 30 23:08:54 2022 +0000

    KVM: VMX: Reset eVMCS controls in VP assist page during hardware disabling
    
    [ Upstream commit 2916b70fc342719f570640de07251b7f91feebdb ]
    
    Reset the eVMCS controls in the per-CPU VP assist page during hardware
    disabling instead of waiting until kvm-intel's module exit.  The controls
    are activated if and only if KVM creates a VM, i.e. don't need to be
    reset if hardware is never enabled.
    
    Doing the reset during hardware disabling will naturally fix a potential
    NULL pointer deref bug once KVM disables CPU hotplug while enabling and
    disabling hardware (which is necessary to fix a variety of bugs).  If the
    kernel is running as the root partition, the VP assist page is unmapped
    during CPU hot unplug, and so KVM's clearing of the eVMCS controls needs
    to occur with CPU hot(un)plug disabled, otherwise KVM could attempt to
    write to a CPU's VP assist page after it's unmapped.
    
    Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Message-Id: <20221130230934.1014142-11-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Stable-dep-of: e32b120071ea ("KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: x86: Move guts of kvm_arch_init() to standalone helper [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Wed Nov 30 23:08:57 2022 +0000

    KVM: x86: Move guts of kvm_arch_init() to standalone helper
    
    [ Upstream commit 4f8396b96a9fc672964842fe7adbe8ddca8a3adf ]
    
    Move the guts of kvm_arch_init() to a new helper, kvm_x86_vendor_init(),
    so that VMX can do _all_ arch and vendor initialization before calling
    kvm_init().  Calling kvm_init() must be the _very_ last step during init,
    as kvm_init() exposes /dev/kvm to userspace, i.e. allows creating VMs.
    
    No functional change intended.
    
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20221130230934.1014142-14-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Stable-dep-of: e32b120071ea ("KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 6.1.20 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Mar 17 08:50:33 2023 +0100

    Linux 6.1.20
    
    Link: https://lore.kernel.org/r/20230315115740.429574234@linuxfoundation.org
    Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>
    Tested-by: Markus Reichelt <lkt+2023@mareichelt.com>
    Tested-by: Conor Dooley <conor.dooley@microchip.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Link: https://lore.kernel.org/r/20230316083444.336870717@linuxfoundation.org
    Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>
    Tested-by: Markus Reichelt <lkt+2023@mareichelt.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
m68k: mm: Move initrd phys_to_virt handling after paging_init() [+ + +]
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Mon Feb 27 21:14:13 2023 +0100

    m68k: mm: Move initrd phys_to_virt handling after paging_init()
    
    [ Upstream commit d4b97925e87eb133e400fe4a482d750c74ce392f ]
    
    When booting with an initial ramdisk on platforms where physical memory
    does not start at address zero (e.g. on Amiga):
    
        initrd: 0ef0602c - 0f800000
        Zone ranges:
          DMA      [mem 0x0000000008000000-0x000000f7ffffffff]
          Normal   empty
        Movable zone start for each node
        Early memory node ranges
          node   0: [mem 0x0000000008000000-0x000000000f7fffff]
        Initmem setup node 0 [mem 0x0000000008000000-0x000000000f7fffff]
        Unable to handle kernel access at virtual address (ptrval)
        Oops: 00000000
        Modules linked in:
        PC: [<00201d3c>] memcmp+0x28/0x56
    
    As phys_to_virt() relies on m68k_memoffset and module_fixup(), it must
    not be called before paging_init().  Hence postpone the phys_to_virt
    handling for the initial ramdisk until after calling paging_init().
    
    While at it, reduce #ifdef clutter by using IS_ENABLED() instead.
    
    Fixes: 376e3fdecb0dcae2 ("m68k: Enable memtest functionality")
    Reported-by: Stephen Walsh <vk3heg@vk3heg.net>
    Link: https://lists.debian.org/debian-68k/2022/09/msg00007.html
    Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Link: https://lore.kernel.org/r/4f45f05f377bf3f5baf88dbd5c3c8aeac59d94f0.camel@physik.fu-berlin.de
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Finn Thain <fthain@linux-m68k.org>
    Link: https://lore.kernel.org/r/dff216da09ab7a60217c3fc2147e671ae07d636f.1677528627.git.geert@linux-m68k.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
macintosh: windfarm: Use unsigned type for 1-bit bitfields [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Feb 15 10:12:12 2023 -0700

    macintosh: windfarm: Use unsigned type for 1-bit bitfields
    
    [ Upstream commit 748ea32d2dbd813d3bd958117bde5191182f909a ]
    
    Clang warns:
    
      drivers/macintosh/windfarm_lm75_sensor.c:63:14: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
                      lm->inited = 1;
                                 ^ ~
    
      drivers/macintosh/windfarm_smu_sensors.c:356:19: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
                      pow->fake_volts = 1;
                                      ^ ~
      drivers/macintosh/windfarm_smu_sensors.c:368:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
                      pow->quadratic = 1;
                                     ^ ~
    
    There is no bug here since no code checks the actual value of these
    fields, just whether or not they are zero (boolean context), but this
    can be easily fixed by switching to an unsigned type.
    
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230215-windfarm-wsingle-bit-bitfield-constant-conversion-v1-1-26415072e855@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
media: ov5640: Fix analogue gain control [+ + +]
Author: Paul Elder <paul.elder@ideasonboard.com>
Date:   Mon Nov 28 09:02:01 2022 +0100

    media: ov5640: Fix analogue gain control
    
    [ Upstream commit afa4805799c1d332980ad23339fdb07b5e0cf7e0 ]
    
    Gain control is badly documented in publicly available (including
    leaked) documentation.
    
    There is an AGC pre-gain in register 0x3a13, expressed as a 6-bit value
    (plus an enable bit in bit 6). The driver hardcodes it to 0x43, which
    one application note states is equal to x1.047. The documentation also
    states that 0x40 is equel to x1.000. The pre-gain thus seems to be
    expressed as in 1/64 increments, and thus ranges from x1.00 to x1.984.
    What the pre-gain does is however unspecified.
    
    There is then an AGC gain limit, in registers 0x3a18 and 0x3a19,
    expressed as a 10-bit "real gain format" value. One application note
    sets it to 0x00f8 and states it is equal to x15.5, so it appears to be
    expressed in 1/16 increments, up to x63.9375.
    
    The manual gain is stored in registers 0x350a and 0x350b, also as a
    10-bit "real gain format" value. It is documented in the application
    note as a Q6.4 values, up to x63.9375.
    
    One version of the datasheet indicates that the sensor supports a
    digital gain:
    
      The OV5640 supports 1/2/4 digital gain. Normally, the gain is
      controlled automatically by the automatic gain control (AGC) block.
    
    It isn't clear how that would be controlled manually.
    
    There appears to be no indication regarding whether the gain controlled
    through registers 0x350a and 0x350b is an analogue gain only or also
    includes digital gain. The words "real gain" don't necessarily mean
    "combined analogue and digital gains". Some OmniVision sensors (such as
    the OV8858) are documented as supoprting different formats for the gain
    values, selectable through a register bit, and they are called "real
    gain format" and "sensor gain format". For that sensor, we have (one of)
    the gain registers documented as
    
      0x3503[2]=0, gain[7:0] is real gain format, where low 4 bits are
      fraction bits, for example, 0x10 is 1x gain, 0x28 is 2.5x gain
    
      If 0x3503[2]=1, gain[7:0] is sensor gain format, gain[7:4] is coarse
      gain, 00000: 1x, 00001: 2x, 00011: 4x, 00111: 8x, gain[7] is 1,
      gain[3:0] is fine gain. For example, 0x10 is 1x gain, 0x30 is 2x gain,
      0x70 is 4x gain
    
    (The second part of the text makes little sense)
    
    "Real gain" may thus refer to the combination of the coarse and fine
    analogue gains as a single value.
    
    The OV5640 0x350a and 0x350b registers thus appear to control analogue
    gain. The driver incorrectly uses V4L2_CID_GAIN as V4L2 has a specific
    control for analogue gain, V4L2_CID_ANALOGUE_GAIN. Use it.
    
    If registers 0x350a and 0x350b are later found to control digital gain
    as well, the driver could then restrict the range of the analogue gain
    control value to lower than x64 and add a separate digital gain control.
    
    Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
    Reviewed-by: Jai Luthra <j-luthra@ti.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: rc: gpio-ir-recv: add remove function [+ + +]
Author: Li Jun <jun.li@nxp.com>
Date:   Wed Jan 11 10:39:21 2023 +0100

    media: rc: gpio-ir-recv: add remove function
    
    [ Upstream commit 30040818b338b8ebc956ce0ebd198f8d593586a6 ]
    
    In case runtime PM is enabled, do runtime PM clean up to remove
    cpu latency qos request, otherwise driver removal may have below
    kernel dump:
    
    [   19.463299] Unable to handle kernel NULL pointer dereference at
    virtual address 0000000000000048
    [   19.472161] Mem abort info:
    [   19.474985]   ESR = 0x0000000096000004
    [   19.478754]   EC = 0x25: DABT (current EL), IL = 32 bits
    [   19.484081]   SET = 0, FnV = 0
    [   19.487149]   EA = 0, S1PTW = 0
    [   19.490361]   FSC = 0x04: level 0 translation fault
    [   19.495256] Data abort info:
    [   19.498149]   ISV = 0, ISS = 0x00000004
    [   19.501997]   CM = 0, WnR = 0
    [   19.504977] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000049f81000
    [   19.511432] [0000000000000048] pgd=0000000000000000,
    p4d=0000000000000000
    [   19.518245] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
    [   19.524520] Modules linked in: gpio_ir_recv(+) rc_core [last
    unloaded: rc_core]
    [   19.531845] CPU: 0 PID: 445 Comm: insmod Not tainted
    6.2.0-rc1-00028-g2c397a46d47c #72
    [   19.531854] Hardware name: FSL i.MX8MM EVK board (DT)
    [   19.531859] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS
    BTYPE=--)
    [   19.551777] pc : cpu_latency_qos_remove_request+0x20/0x110
    [   19.557277] lr : gpio_ir_recv_runtime_suspend+0x18/0x30
    [gpio_ir_recv]
    [   19.557294] sp : ffff800008ce3740
    [   19.557297] x29: ffff800008ce3740 x28: 0000000000000000 x27:
    ffff800008ce3d50
    [   19.574270] x26: ffffc7e3e9cea100 x25: 00000000000f4240 x24:
    ffffc7e3f9ef0e30
    [   19.574284] x23: 0000000000000000 x22: ffff0061803820f4 x21:
    0000000000000008
    [   19.574296] x20: ffffc7e3fa75df30 x19: 0000000000000020 x18:
    ffffffffffffffff
    [   19.588570] x17: 0000000000000000 x16: ffffc7e3f9efab70 x15:
    ffffffffffffffff
    [   19.595712] x14: ffff800008ce37b8 x13: ffff800008ce37aa x12:
    0000000000000001
    [   19.602853] x11: 0000000000000001 x10: ffffcbe3ec0dff87 x9 :
    0000000000000008
    [   19.609991] x8 : 0101010101010101 x7 : 0000000000000000 x6 :
    000000000f0bfe9f
    [   19.624261] x5 : 00ffffffffffffff x4 : 0025ab8e00000000 x3 :
    ffff006180382010
    [   19.631405] x2 : ffffc7e3e9ce8030 x1 : ffffc7e3fc3eb810 x0 :
    0000000000000020
    [   19.638548] Call trace:
    [   19.640995]  cpu_latency_qos_remove_request+0x20/0x110
    [   19.646142]  gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv]
    [   19.652339]  pm_generic_runtime_suspend+0x2c/0x44
    [   19.657055]  __rpm_callback+0x48/0x1dc
    [   19.660807]  rpm_callback+0x6c/0x80
    [   19.664301]  rpm_suspend+0x10c/0x640
    [   19.667880]  rpm_idle+0x250/0x2d0
    [   19.671198]  update_autosuspend+0x38/0xe0
    [   19.675213]  pm_runtime_set_autosuspend_delay+0x40/0x60
    [   19.680442]  gpio_ir_recv_probe+0x1b4/0x21c [gpio_ir_recv]
    [   19.685941]  platform_probe+0x68/0xc0
    [   19.689610]  really_probe+0xc0/0x3dc
    [   19.693189]  __driver_probe_device+0x7c/0x190
    [   19.697550]  driver_probe_device+0x3c/0x110
    [   19.701739]  __driver_attach+0xf4/0x200
    [   19.705578]  bus_for_each_dev+0x70/0xd0
    [   19.709417]  driver_attach+0x24/0x30
    [   19.712998]  bus_add_driver+0x17c/0x240
    [   19.716834]  driver_register+0x78/0x130
    [   19.720676]  __platform_driver_register+0x28/0x34
    [   19.725386]  gpio_ir_recv_driver_init+0x20/0x1000 [gpio_ir_recv]
    [   19.731404]  do_one_initcall+0x44/0x2ac
    [   19.735243]  do_init_module+0x48/0x1d0
    [   19.739003]  load_module+0x19fc/0x2034
    [   19.742759]  __do_sys_finit_module+0xac/0x12c
    [   19.747124]  __arm64_sys_finit_module+0x20/0x30
    [   19.751664]  invoke_syscall+0x48/0x114
    [   19.755420]  el0_svc_common.constprop.0+0xcc/0xec
    [   19.760132]  do_el0_svc+0x38/0xb0
    [   19.763456]  el0_svc+0x2c/0x84
    [   19.766516]  el0t_64_sync_handler+0xf4/0x120
    [   19.770789]  el0t_64_sync+0x190/0x194
    [   19.774460] Code: 910003fd a90153f3 aa0003f3 91204021 (f9401400)
    [   19.780556] ---[ end trace 0000000000000000 ]---
    
    Signed-off-by: Li Jun <jun.li@nxp.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
MIPS: Fix a compilation issue [+ + +]
Author: xurui <xurui@kylinos.cn>
Date:   Wed Jan 18 16:59:12 2023 +0800

    MIPS: Fix a compilation issue
    
    [ Upstream commit 109d587a4b4d7ccca2200ab1f808f43ae23e2585 ]
    
    arch/mips/include/asm/mach-rc32434/pci.h:377:
    cc1: error: result of ‘-117440512 << 16’ requires 44 bits to represent, but ‘int’ only has 32 bits [-Werror=shift-overflow=]
    
    All bits in KORINA_STAT are already at the correct position, so there is
    no addtional shift needed.
    
    Signed-off-by: xurui <xurui@kylinos.cn>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/smc: fix fallback failed while sendmsg with fastopen [+ + +]
Author: D. Wythe <alibuda@linux.alibaba.com>
Date:   Tue Mar 7 11:23:46 2023 +0800

    net/smc: fix fallback failed while sendmsg with fastopen
    
    [ Upstream commit ce7ca794712f186da99719e8b4e97bd5ddbb04c3 ]
    
    Before determining whether the msg has unsupported options, it has been
    prematurely terminated by the wrong status check.
    
    For the application, the general usages of MSG_FASTOPEN likes
    
    fd = socket(...)
    /* rather than connect */
    sendto(fd, data, len, MSG_FASTOPEN)
    
    Hence, We need to check the flag before state check, because the sock
    state here is always SMC_INIT when applications tries MSG_FASTOPEN.
    Once we found unsupported options, fallback it to TCP.
    
    Fixes: ee9dfbef02d1 ("net/smc: handle sockopts forcing fallback")
    Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
    Signed-off-by: Simon Horman <simon.horman@corigine.com>
    
    v2 -> v1: Optimize code style
    Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: caif: Fix use-after-free in cfusbl_device_notify() [+ + +]
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Thu Mar 2 01:39:13 2023 +0900

    net: caif: Fix use-after-free in cfusbl_device_notify()
    
    [ Upstream commit 9781e98a97110f5e76999058368b4be76a788484 ]
    
    syzbot reported use-after-free in cfusbl_device_notify() [1].  This
    causes a stack trace like below:
    
    BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138
    Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214
    
    CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: netns cleanup_net
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
     print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313
     print_report mm/kasan/report.c:429 [inline]
     kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491
     cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138
     notifier_call_chain+0xb5/0x200 kernel/notifier.c:87
     call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945
     call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]
     call_netdevice_notifiers net/core/dev.c:1997 [inline]
     netdev_wait_allrefs_any net/core/dev.c:10227 [inline]
     netdev_run_todo+0xbc0/0x10f0 net/core/dev.c:10341
     default_device_exit_batch+0x44e/0x590 net/core/dev.c:11334
     ops_exit_list+0x125/0x170 net/core/net_namespace.c:167
     cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594
     process_one_work+0x996/0x1610 kernel/workqueue.c:2289
     worker_thread+0x665/0x1080 kernel/workqueue.c:2436
     kthread+0x2e9/0x3a0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
     </TASK>
    
    When unregistering a net device, unregister_netdevice_many_notify()
    sets the device's reg_state to NETREG_UNREGISTERING, calls notifiers
    with NETDEV_UNREGISTER, and adds the device to the todo list.
    
    Later on, devices in the todo list are processed by netdev_run_todo().
    netdev_run_todo() waits devices' reference count become 1 while
    rebdoadcasting NETDEV_UNREGISTER notification.
    
    When cfusbl_device_notify() is called with NETDEV_UNREGISTER multiple
    times, the parent device might be freed.  This could cause UAF.
    Processing NETDEV_UNREGISTER multiple times also causes inbalance of
    reference count for the module.
    
    This patch fixes the issue by accepting only first NETDEV_UNREGISTER
    notification.
    
    Fixes: 7ad65bf68d70 ("caif: Add support for CAIF over CDC NCM USB interface")
    CC: sjur.brandeland@stericsson.com <sjur.brandeland@stericsson.com>
    Reported-by: syzbot+b563d33852b893653a9e@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?id=c3bfd8e2450adab3bffe4d80821fbbced600407f [1]
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Link: https://lore.kernel.org/r/20230301163913.391304-1-syoshida@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: mt7530: permit port 5 to work without port 6 on MT7621 SoC [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Mar 7 17:54:11 2023 +0200

    net: dsa: mt7530: permit port 5 to work without port 6 on MT7621 SoC
    
    [ Upstream commit c8b8a3c601f2cfad25ab5ce5b04df700048aef6e ]
    
    The MT7530 switch from the MT7621 SoC has 2 ports which can be set up as
    internal: port 5 and 6. Arınç reports that the GMAC1 attached to port 5
    receives corrupted frames, unless port 6 (attached to GMAC0) has been
    brought up by the driver. This is true regardless of whether port 5 is
    used as a user port or as a CPU port (carrying DSA tags).
    
    Offline debugging (blind for me) which began in the linked thread showed
    experimentally that the configuration done by the driver for port 6
    contains a step which is needed by port 5 as well - the write to
    CORE_GSWPLL_GRP2 (note that I've no idea as to what it does, apart from
    the comment "Set core clock into 500Mhz"). Prints put by Arınç show that
    the reset value of CORE_GSWPLL_GRP2 is RG_GSWPLL_POSDIV_500M(1) |
    RG_GSWPLL_FBKDIV_500M(40) (0x128), both on the MCM MT7530 from the
    MT7621 SoC, as well as on the standalone MT7530 from MT7623NI Bananapi
    BPI-R2. Apparently, port 5 on the standalone MT7530 can work under both
    values of the register, while on the MT7621 SoC it cannot.
    
    The call path that triggers the register write is:
    
    mt753x_phylink_mac_config() for port 6
    -> mt753x_pad_setup()
       -> mt7530_pad_clk_setup()
    
    so this fully explains the behavior noticed by Arınç, that bringing port
    6 up is necessary.
    
    The simplest fix for the problem is to extract the register writes which
    are needed for both port 5 and 6 into a common mt7530_pll_setup()
    function, which is called at mt7530_setup() time, immediately after
    switch reset. We can argue that this mirrors the code layout introduced
    in mt7531_setup() by commit 42bc4fafe359 ("net: mt7531: only do PLL once
    after the reset"), in that the PLL setup has the exact same positioning,
    and further work to consolidate the separate setup() functions is not
    hindered.
    
    Testing confirms that:
    
    - the slight reordering of writes to MT7530_P6ECR and to
      CORE_GSWPLL_GRP1 / CORE_GSWPLL_GRP2 introduced by this change does not
      appear to cause problems for the operation of port 6 on MT7621 and on
      MT7623 (where port 5 also always worked)
    
    - packets sent through port 5 are not corrupted anymore, regardless of
      whether port 6 is enabled by phylink or not (or even present in the
      device tree)
    
    My algorithm for determining the Fixes: tag is as follows. Testing shows
    that some logic from mt7530_pad_clk_setup() is needed even for port 5.
    Prior to commit ca366d6c889b ("net: dsa: mt7530: Convert to PHYLINK
    API"), a call did exist for all phy_is_pseudo_fixed_link() ports - so
    port 5 included. That commit replaced it with a temporary "Port 5 is not
    supported!" comment, and the following commit 38f790a80560 ("net: dsa:
    mt7530: Add support for port 5") replaced that comment with a
    configuration procedure in mt7530_setup_port5() which was insufficient
    for port 5 to work. I'm laying the blame on the patch that claimed
    support for port 5, although one would have also needed the change from
    commit c3b8e07909db ("net: dsa: mt7530: setup core clock even in TRGMII
    mode") for the write to be performed completely independently from port
    6's configuration.
    
    Thanks go to Arınç for describing the problem, for debugging and for
    testing.
    
    Reported-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Link: https://lore.kernel.org/netdev/f297c2c4-6e7c-57ac-2394-f6025d309b9d@arinc9.com/
    Fixes: 38f790a80560 ("net: dsa: mt7530: Add support for port 5")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/20230307155411.868573-1-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: mtk_eth_soc: fix RX data corruption issue [+ + +]
Author: Daniel Golle <daniel@makrotopia.org>
Date:   Sat Mar 4 13:43:20 2023 +0000

    net: ethernet: mtk_eth_soc: fix RX data corruption issue
    
    [ Upstream commit 193250ace270fecd586dd2d0dfbd9cbd2ade977f ]
    
    Fix data corruption issue with SerDes connected PHYs operating at 1.25
    Gbps speed where we could previously observe about 30% packet loss while
    the bad packet counter was increasing.
    
    As almost all boards with MediaTek MT7622 or MT7986 use either the MT7531
    switch IC operating at 3.125Gbps SerDes rate or single-port PHYs using
    rate-adaptation to 2500Base-X mode, this issue only got exposed now when
    we started trying to use SFP modules operating with 1.25 Gbps with the
    BananaPi R3 board.
    
    The fix is to set bit 12 which disables the RX FIFO clear function when
    setting up MAC MCR, MediaTek SDK did the same change stating:
    "If without this patch, kernel might receive invalid packets that are
    corrupted by GMAC."[1]
    
    [1]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/d8a2975939a12686c4a95c40db21efdc3f821f63
    
    Fixes: 42c03844e93d ("net-next: mediatek: add support for MediaTek MT7622 SoC")
    Tested-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Daniel Golle <daniel@makrotopia.org>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/138da2735f92c8b6f8578ec2e5a794ee515b665f.1677937317.git.daniel@makrotopia.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: lan78xx: fix accessing the LAN7800's internal phy specific registers from the MAC driver [+ + +]
Author: Yuiko Oshino <yuiko.oshino@microchip.com>
Date:   Wed Mar 1 08:43:07 2023 -0700

    net: lan78xx: fix accessing the LAN7800's internal phy specific registers from the MAC driver
    
    [ Upstream commit e57cf3639c323eeed05d3725fd82f91b349adca8 ]
    
    Move the LAN7800 internal phy (phy ID  0x0007c132) specific register
    accesses to the phy driver (microchip.c).
    
    Fix the error reported by Enguerrand de Ribaucourt in December 2022,
    "Some operations during the cable switch workaround modify the register
    LAN88XX_INT_MASK of the PHY. However, this register is specific to the
    LAN8835 PHY. For instance, if a DP8322I PHY is connected to the LAN7801,
    that register (0x19), corresponds to the LED and MAC address
    configuration, resulting in unapropriate behavior."
    
    I did not test with the DP8322I PHY, but I tested with an EVB-LAN7800
    with the internal PHY.
    
    Fixes: 14437e3fa284 ("lan78xx: workaround of forced 100 Full/Half duplex mode error")
    Signed-off-by: Yuiko Oshino <yuiko.oshino@microchip.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20230301154307.30438-1-yuiko.oshino@microchip.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: lan966x: Fix port police support using tc-matchall [+ + +]
Author: Horatiu Vultur <horatiu.vultur@microchip.com>
Date:   Tue Feb 28 21:47:42 2023 +0100

    net: lan966x: Fix port police support using tc-matchall
    
    [ Upstream commit 81563d8548b0478075c720666be348d4199b8591 ]
    
    When the police was removed from the port, then it was trying to
    remove the police from the police id and not from the actual
    police index.
    The police id represents the id of the police and police index
    represents the position in HW where the police is situated.
    The port police id can be any number while the port police index
    is a number based on the port chip port.
    Fix this by deleting the police from HW that is situated at the
    police index and not police id.
    
    Fixes: 5390334b59a3 ("net: lan966x: Add port police support using tc-matchall")
    Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: smsc: fix link up detection in forced irq mode [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sat Mar 4 11:52:44 2023 +0100

    net: phy: smsc: fix link up detection in forced irq mode
    
    [ Upstream commit 58aac3a2ef414fea6d7fdf823ea177744a087d13 ]
    
    Currently link up can't be detected in forced mode if polling
    isn't used. Only link up interrupt source we have is aneg
    complete which isn't applicable in forced mode. Therefore we
    have to use energy-on as link up indicator.
    
    Fixes: 7365494550f6 ("net: phy: smsc: skip ENERGYON interrupt if disabled")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phylib: get rid of unnecessary locking [+ + +]
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Fri Mar 3 16:37:54 2023 +0000

    net: phylib: get rid of unnecessary locking
    
    [ Upstream commit f4b47a2e9463950df3e7c8b70e017877c1d4eb11 ]
    
    The locking in phy_probe() and phy_remove() does very little to prevent
    any races with e.g. phy_attach_direct(), but instead causes lockdep ABBA
    warnings. Remove it.
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.2.0-dirty #1108 Tainted: G        W   E
    ------------------------------------------------------
    ip/415 is trying to acquire lock:
    ffff5c268f81ef50 (&dev->lock){+.+.}-{3:3}, at: phy_attach_direct+0x17c/0x3a0 [libphy]
    
    but task is already holding lock:
    ffffaef6496cb518 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x154/0x560
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (rtnl_mutex){+.+.}-{3:3}:
           __lock_acquire+0x35c/0x6c0
           lock_acquire.part.0+0xcc/0x220
           lock_acquire+0x68/0x84
           __mutex_lock+0x8c/0x414
           mutex_lock_nested+0x34/0x40
           rtnl_lock+0x24/0x30
           sfp_bus_add_upstream+0x34/0x150
           phy_sfp_probe+0x4c/0x94 [libphy]
           mv3310_probe+0x148/0x184 [marvell10g]
           phy_probe+0x8c/0x200 [libphy]
           call_driver_probe+0xbc/0x15c
           really_probe+0xc0/0x320
           __driver_probe_device+0x84/0x120
           driver_probe_device+0x44/0x120
           __device_attach_driver+0xc4/0x160
           bus_for_each_drv+0x80/0xe0
           __device_attach+0xb0/0x1f0
           device_initial_probe+0x1c/0x2c
           bus_probe_device+0xa4/0xb0
           device_add+0x360/0x53c
           phy_device_register+0x60/0xa4 [libphy]
           fwnode_mdiobus_phy_device_register+0xc0/0x190 [fwnode_mdio]
           fwnode_mdiobus_register_phy+0x160/0xd80 [fwnode_mdio]
           of_mdiobus_register+0x140/0x340 [of_mdio]
           orion_mdio_probe+0x298/0x3c0 [mvmdio]
           platform_probe+0x70/0xe0
           call_driver_probe+0x34/0x15c
           really_probe+0xc0/0x320
           __driver_probe_device+0x84/0x120
           driver_probe_device+0x44/0x120
           __driver_attach+0x104/0x210
           bus_for_each_dev+0x78/0xdc
           driver_attach+0x2c/0x3c
           bus_add_driver+0x184/0x240
           driver_register+0x80/0x13c
           __platform_driver_register+0x30/0x3c
           xt_compat_calc_jump+0x28/0xa4 [x_tables]
           do_one_initcall+0x50/0x1b0
           do_init_module+0x50/0x1fc
           load_module+0x684/0x744
           __do_sys_finit_module+0xc4/0x140
           __arm64_sys_finit_module+0x28/0x34
           invoke_syscall+0x50/0x120
           el0_svc_common.constprop.0+0x6c/0x1b0
           do_el0_svc+0x34/0x44
           el0_svc+0x48/0xf0
           el0t_64_sync_handler+0xb8/0xc0
           el0t_64_sync+0x1a0/0x1a4
    
    -> #0 (&dev->lock){+.+.}-{3:3}:
           check_prev_add+0xb4/0xc80
           validate_chain+0x414/0x47c
           __lock_acquire+0x35c/0x6c0
           lock_acquire.part.0+0xcc/0x220
           lock_acquire+0x68/0x84
           __mutex_lock+0x8c/0x414
           mutex_lock_nested+0x34/0x40
           phy_attach_direct+0x17c/0x3a0 [libphy]
           phylink_fwnode_phy_connect.part.0+0x70/0xe4 [phylink]
           phylink_fwnode_phy_connect+0x48/0x60 [phylink]
           mvpp2_open+0xec/0x2e0 [mvpp2]
           __dev_open+0x104/0x214
           __dev_change_flags+0x1d4/0x254
           dev_change_flags+0x2c/0x7c
           do_setlink+0x254/0xa50
           __rtnl_newlink+0x430/0x514
           rtnl_newlink+0x58/0x8c
           rtnetlink_rcv_msg+0x17c/0x560
           netlink_rcv_skb+0x64/0x150
           rtnetlink_rcv+0x20/0x30
           netlink_unicast+0x1d4/0x2b4
           netlink_sendmsg+0x1a4/0x400
           ____sys_sendmsg+0x228/0x290
           ___sys_sendmsg+0x88/0xec
           __sys_sendmsg+0x70/0xd0
           __arm64_sys_sendmsg+0x2c/0x40
           invoke_syscall+0x50/0x120
           el0_svc_common.constprop.0+0x6c/0x1b0
           do_el0_svc+0x34/0x44
           el0_svc+0x48/0xf0
           el0t_64_sync_handler+0xb8/0xc0
           el0t_64_sync+0x1a0/0x1a4
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(rtnl_mutex);
                                   lock(&dev->lock);
                                   lock(rtnl_mutex);
      lock(&dev->lock);
    
     *** DEADLOCK ***
    
    Fixes: 298e54fa810e ("net: phy: add core phylib sfp support")
    Reported-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: add to set device wake up flag when stmmac init phy [+ + +]
Author: Rongguang Wei <weirongguang@kylinos.cn>
Date:   Thu Mar 2 14:21:43 2023 +0800

    net: stmmac: add to set device wake up flag when stmmac init phy
    
    [ Upstream commit a9334b702a03b693f54ebd3b98f67bf722b74870 ]
    
    When MAC is not support PMT, driver will check PHY's WoL capability
    and set device wakeup capability in stmmac_init_phy(). We can enable
    the WoL through ethtool, the driver would enable the device wake up
    flag. Now the device_may_wakeup() return true.
    
    But if there is a way which enable the PHY's WoL capability derectly,
    like in BIOS. The driver would not know the enable thing and would not
    set the device wake up flag. The phy_suspend may failed like this:
    
    [   32.409063] PM: dpm_run_callback(): mdio_bus_phy_suspend+0x0/0x50 returns -16
    [   32.409065] PM: Device stmmac-1:00 failed to suspend: error -16
    [   32.409067] PM: Some devices failed to suspend, or early wake event detected
    
    Add to set the device wakeup enable flag according to the get_wol
    function result in PHY can fix the error in this scene.
    
    v2: add a Fixes tag.
    
    Fixes: 1d8e5b0f3f2c ("net: stmmac: Support WOL with phy")
    Signed-off-by: Rongguang Wei <weirongguang@kylinos.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: tls: fix device-offloaded sendpage straddling records [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Sat Mar 4 11:26:10 2023 -0800

    net: tls: fix device-offloaded sendpage straddling records
    
    [ Upstream commit e539a105f947b9db470fec39fe91d85fe737a432 ]
    
    Adrien reports that incorrect data is transmitted when a single
    page straddles multiple records. We would transmit the same
    data in all iterations of the loop.
    
    Reported-by: Adrien Moulin <amoulin@corp.free.fr>
    Link: https://lore.kernel.org/all/61481278.42813558.1677845235112.JavaMail.zimbra@corp.free.fr
    Fixes: c1318b39c7d3 ("tls: Add opt-in zerocopy mode of sendfile()")
    Tested-by: Adrien Moulin <amoulin@corp.free.fr>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Acked-by: Maxim Mikityanskiy <maxtram95@gmail.com>
    Link: https://lore.kernel.org/r/20230304192610.3818098-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: tls: fix possible race condition between do_tls_getsockopt_conf() and do_tls_setsockopt_conf() [+ + +]
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Tue Feb 28 10:33:44 2023 +0800

    net: tls: fix possible race condition between do_tls_getsockopt_conf() and do_tls_setsockopt_conf()
    
    [ Upstream commit 49c47cc21b5b7a3d8deb18fc57b0aa2ab1286962 ]
    
    ctx->crypto_send.info is not protected by lock_sock in
    do_tls_getsockopt_conf(). A race condition between do_tls_getsockopt_conf()
    and error paths of do_tls_setsockopt_conf() may lead to a use-after-free
    or null-deref.
    
    More discussion:  https://lore.kernel.org/all/Y/ht6gQL+u6fj3dG@hog/
    
    Fixes: 3c4d7559159b ("tls: kernel TLS support")
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Link: https://lore.kernel.org/r/20230228023344.9623-1-hbh25y@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: use indirect calls helpers for sk_exit_memory_pressure() [+ + +]
Author: Brian Vazquez <brianvv@google.com>
Date:   Wed Mar 1 13:32:47 2023 +0000

    net: use indirect calls helpers for sk_exit_memory_pressure()
    
    [ Upstream commit 5c1ebbfabcd61142a4551bfc0e51840f9bdae7af ]
    
    Florian reported a regression and sent a patch with the following
    changelog:
    
    <quote>
     There is a noticeable tcp performance regression (loopback or cross-netns),
     seen with iperf3 -Z (sendfile mode) when generic retpolines are needed.
    
     With SK_RECLAIM_THRESHOLD checks gone number of calls to enter/leave
     memory pressure happen much more often. For TCP indirect calls are
     used.
    
     We can't remove the if-set-return short-circuit check in
     tcp_enter_memory_pressure because there are callers other than
     sk_enter_memory_pressure.  Doing a check in the sk wrapper too
     reduces the indirect calls enough to recover some performance.
    
     Before,
     0.00-60.00  sec   322 GBytes  46.1 Gbits/sec                  receiver
    
     After:
     0.00-60.04  sec   359 GBytes  51.4 Gbits/sec                  receiver
    
     "iperf3 -c $peer -t 60 -Z -f g", connected via veth in another netns.
    </quote>
    
    It seems we forgot to upstream this indirect call mitigation we
    had for years, lets do this instead.
    
    [edumazet] - It seems we forgot to upstream this indirect call
                 mitigation we had for years, let's do this instead.
               - Changed to INDIRECT_CALL_INET_1() to avoid bots reports.
    
    Fixes: 4890b686f408 ("net: keep sk->sk_forward_alloc as small as possible")
    Reported-by: Florian Westphal <fw@strlen.de>
    Link: https://lore.kernel.org/netdev/20230227152741.4a53634b@kernel.org/T/
    Signed-off-by: Brian Vazquez <brianvv@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20230301133247.2346111-1-edumazet@google.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: conntrack: adopt safer max chain length [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Mar 7 05:22:54 2023 +0000

    netfilter: conntrack: adopt safer max chain length
    
    [ Upstream commit c77737b736ceb50fdf150434347dbd81ec76dbb1 ]
    
    Customers using GKE 1.25 and 1.26 are facing conntrack issues
    root caused to commit c9c3b6811f74 ("netfilter: conntrack: make
    max chain length random").
    
    Even if we assume Uniform Hashing, a bucket often reachs 8 chained
    items while the load factor of the hash table is smaller than 0.5
    
    With a limit of 16, we reach load factors of 3.
    With a limit of 32, we reach load factors of 11.
    With a limit of 40, we reach load factors of 15.
    With a limit of 50, we reach load factors of 24.
    
    This patch changes MIN_CHAINLEN to 50, to minimize risks.
    
    Ideally, we could in the future add a cushion based on expected
    load factor (2 * nf_conntrack_max / nf_conntrack_buckets),
    because some setups might expect unusual values.
    
    Fixes: c9c3b6811f74 ("netfilter: conntrack: make max chain length random")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: ctnetlink: revert to dumping mark regardless of event type [+ + +]
Author: Ivan Delalande <colona@arista.com>
Date:   Thu Mar 2 17:48:31 2023 -0800

    netfilter: ctnetlink: revert to dumping mark regardless of event type
    
    [ Upstream commit 9f7dd42f0db1dc6915a52d4a8a96ca18dd8cc34e ]
    
    It seems that change was unintentional, we have userspace code that
    needs the mark while listening for events like REPLY, DESTROY, etc.
    Also include 0-marks in requested dumps, as they were before that fix.
    
    Fixes: 1feeae071507 ("netfilter: ctnetlink: fix compilation warning after data race fixes in ct mark")
    Signed-off-by: Ivan Delalande <colona@arista.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_last: copy content when cloning expression [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Feb 28 17:09:03 2023 +0100

    netfilter: nft_last: copy content when cloning expression
    
    [ Upstream commit 860e874290fb3be08e966c9c8ffc510c5b0f2bd8 ]
    
    If the ruleset contains last timestamps, restore them accordingly.
    Otherwise, listing after restoration shows never used items.
    
    Fixes: 33a24de37e81 ("netfilter: nft_last: move stateful fields out of expression data")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_quota: copy content when cloning expression [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Feb 28 20:43:02 2023 +0100

    netfilter: nft_quota: copy content when cloning expression
    
    [ Upstream commit aabef97a35160461e9c576848ded737558d89055 ]
    
    If the ruleset contains consumed quota, restore them accordingly.
    Otherwise, listing after restoration shows never used items.
    
    Restore the user-defined quota and flags too.
    
    Fixes: ed0a0c60f0e5 ("netfilter: nft_quota: move stateful fields out of expression data")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: tproxy: fix deadlock due to missing BH disable [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Mar 3 10:58:56 2023 +0100

    netfilter: tproxy: fix deadlock due to missing BH disable
    
    [ Upstream commit 4a02426787bf024dafdb79b362285ee325de3f5e ]
    
    The xtables packet traverser performs an unconditional local_bh_disable(),
    but the nf_tables evaluation loop does not.
    
    Functions that are called from either xtables or nftables must assume
    that they can be called in process context.
    
    inet_twsk_deschedule_put() assumes that no softirq interrupt can occur.
    If tproxy is used from nf_tables its possible that we'll deadlock
    trying to aquire a lock already held in process context.
    
    Add a small helper that takes care of this and use it.
    
    Link: https://lore.kernel.org/netfilter-devel/401bd6ed-314a-a196-1cdc-e13c720cc8f2@balasys.hu/
    Fixes: 4ed8eb6570a4 ("netfilter: nf_tables: Add native tproxy support")
    Reported-and-tested-by: Major Dávid <major.david@balasys.hu>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfc: change order inside nfc_se_io error path [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Tue Mar 7 00:26:50 2023 +0300

    nfc: change order inside nfc_se_io error path
    
    commit 7d834b4d1ab66c48e8c0810fdeadaabb80fa2c81 upstream.
    
    cb_context should be freed on the error path in nfc_se_io as stated by
    commit 25ff6f8a5a3b ("nfc: fix memory leak of se_io context in
    nfc_genl_se_io").
    
    Make the error path in nfc_se_io unwind everything in reverse order, i.e.
    free the cb_context after unlocking the device.
    
    Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20230306212650.230322-1-pchelkin@ispras.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties [+ + +]
Author: Kang Chen <void0red@gmail.com>
Date:   Mon Feb 27 17:30:37 2023 +0800

    nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties
    
    [ Upstream commit 11f180a5d62a51b484e9648f9b310e1bd50b1a57 ]
    
    devm_kmalloc_array may fails, *fw_vsc_cfg might be null and cause
    out-of-bounds write in device_property_read_u8_array later.
    
    Fixes: a06347c04c13 ("NFC: Add Intel Fields Peak NFC solution driver")
    Signed-off-by: Kang Chen <void0red@gmail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/20230227093037.907654-1-void0red@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSD: Protect against filesystem freezing [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Mar 6 10:43:47 2023 -0500

    NFSD: Protect against filesystem freezing
    
    [ Upstream commit fd9a2e1d513823e840960cb3bc26d8b7749d4ac2 ]
    
    Flole observes this WARNING on occasion:
    
    [1210423.486503] WARNING: CPU: 8 PID: 1524732 at fs/ext4/ext4_jbd2.c:75 ext4_journal_check_start+0x68/0xb0
    
    Reported-by: <flole@flole.de>
    Suggested-by: Jan Kara <jack@suse.cz>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217123
    Fixes: 73da852e3831 ("nfsd: use vfs_iter_read/write")
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-af: Unlock contexts in the queue context cache in case of fault detection [+ + +]
Author: Suman Ghosh <sumang@marvell.com>
Date:   Tue Mar 7 16:19:08 2023 +0530

    octeontx2-af: Unlock contexts in the queue context cache in case of fault detection
    
    [ Upstream commit ea9dd2e5c6d12c8b65ce7514c8359a70eeaa0e70 ]
    
    NDC caches contexts of frequently used queue's (Rx and Tx queues)
    contexts. Due to a HW errata when NDC detects fault/poision while
    accessing contexts it could go into an illegal state where a cache
    line could get locked forever. To makesure all cache lines in NDC
    are available for optimum performance upon fault/lockerror/posion
    errors scan through all cache lines in NDC and clear the lock bit.
    
    Fixes: 4a3581cd5995 ("octeontx2-af: NPA AQ instruction enqueue support")
    Signed-off-by: Suman Ghosh <sumang@marvell.com>
    Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
    Signed-off-by: Sai Krishna <saikrishnag@marvell.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI: Add SolidRun vendor ID [+ + +]
Author: Alvaro Karsz <alvaro.karsz@solid-run.com>
Date:   Tue Jan 10 18:56:36 2023 +0200

    PCI: Add SolidRun vendor ID
    
    [ Upstream commit db6c4dee4c104f50ed163af71c53bfdb878a8318 ]
    
    Add SolidRun vendor ID to pci_ids.h
    
    The vendor ID is used in 2 different source files, the SNET vDPA driver
    and PCI quirks.
    
    Signed-off-by: Alvaro Karsz <alvaro.karsz@solid-run.com>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Message-Id: <20230110165638.123745-2-alvaro.karsz@solid-run.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf inject: Fix --buildid-all not to eat up MMAP2 [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Wed Feb 22 23:01:55 2023 -0800

    perf inject: Fix --buildid-all not to eat up MMAP2
    
    commit ce9f1c05d2edfa6cdf2c1a510495d333e11810a8 upstream.
    
    When MMAP2 has the PERF_RECORD_MISC_MMAP_BUILD_ID flag, it means the
    record already has the build-id info.  So it marks the DSO as hit, to
    skip if the same DSO is not processed if it happens to miss the build-id
    later.
    
    But it missed to copy the MMAP2 record itself so it'd fail to symbolize
    samples for those regions.
    
    For example, the following generates 249 MMAP2 events.
    
      $ perf record --buildid-mmap -o- true | perf report --stat -i- | grep MMAP2
               MMAP2 events:        249  (86.8%)
    
    Adding perf inject should not change the number of events like this
    
      $ perf record --buildid-mmap -o- true | perf inject -b | \
      > perf report --stat -i- | grep MMAP2
               MMAP2 events:        249  (86.5%)
    
    But when --buildid-all is used, it eats most of the MMAP2 events.
    
      $ perf record --buildid-mmap -o- true | perf inject -b --buildid-all | \
      > perf report --stat -i- | grep MMAP2
               MMAP2 events:          1  ( 2.5%)
    
    With this patch, it shows the original number now.
    
      $ perf record --buildid-mmap -o- true | perf inject -b --buildid-all | \
      > perf report --stat -i- | grep MMAP2
               MMAP2 events:        249  (86.5%)
    
    Committer testing:
    
    Before:
    
      $ perf record --buildid-mmap -o- perf stat --null sleep 1 2> /dev/null | perf inject -b | perf report --stat -i- | grep MMAP2
               MMAP2 events:         58  (36.2%)
      $ perf record --buildid-mmap -o- perf stat --null sleep 1 2> /dev/null | perf report --stat -i- | grep MMAP2
               MMAP2 events:         58  (36.2%)
      $ perf record --buildid-mmap -o- perf stat --null sleep 1 2> /dev/null | perf inject -b --buildid-all | perf report --stat -i- | grep MMAP2
               MMAP2 events:          2  ( 1.9%)
      $
    
    After:
    
      $ perf record --buildid-mmap -o- perf stat --null sleep 1 2> /dev/null | perf inject -b | perf report --stat -i- | grep MMAP2
               MMAP2 events:         58  (29.3%)
      $ perf record --buildid-mmap -o- perf stat --null sleep 1 2> /dev/null | perf report --stat -i- | grep MMAP2
               MMAP2 events:         58  (34.3%)
      $ perf record --buildid-mmap -o- perf stat --null sleep 1 2> /dev/null | perf inject -b --buildid-all | perf report --stat -i- | grep MMAP2
               MMAP2 events:         58  (38.4%)
      $
    
    Fixes: f7fc0d1c915a74ff ("perf inject: Do not inject BUILD_ID record if MMAP2 has it")
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230223070155.54251-1-namhyung@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf stat: Fix counting when initial delay configured [+ + +]
Author: Changbin Du <changbin.du@huawei.com>
Date:   Thu Mar 2 11:11:44 2023 +0800

    perf stat: Fix counting when initial delay configured
    
    [ Upstream commit 25f69c69bc3ca8c781a94473f28d443d745768e3 ]
    
    When creating counters with initial delay configured, the enable_on_exec
    field is not set. So we need to enable the counters later. The problem
    is, when a workload is specified the target__none() is true. So we also
    need to check stat_config.initial_delay.
    
    In this change, we add a new field 'initial_delay' for struct target
    which could be shared by other subcommands. And define
    target__enable_on_exec() which returns whether enable_on_exec should be
    set on normal cases.
    
    Before this fix the event is not counted:
    
      $ ./perf stat -e instructions -D 100 sleep 2
      Events disabled
      Events enabled
    
       Performance counter stats for 'sleep 2':
    
           <not counted>      instructions
    
             1.901661124 seconds time elapsed
    
             0.001602000 seconds user
             0.000000000 seconds sys
    
    After fix it works:
    
      $ ./perf stat -e instructions -D 100 sleep 2
      Events disabled
      Events enabled
    
       Performance counter stats for 'sleep 2':
    
                 404,214      instructions
    
             1.901743475 seconds time elapsed
    
             0.001617000 seconds user
             0.000000000 seconds sys
    
    Fixes: c587e77e100fa40e ("perf stat: Do not delay the workload with --delay")
    Signed-off-by: Changbin Du <changbin.du@huawei.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Hui Wang <hw.huiwang@huawei.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20230302031146.2801588-2-changbin.du@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform: mellanox: select REGMAP instead of depending on it [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Feb 25 21:39:50 2023 -0800

    platform: mellanox: select REGMAP instead of depending on it
    
    [ Upstream commit 03f5eb300ad1241f854269a3e521b119189a4493 ]
    
    REGMAP is a hidden (not user visible) symbol. Users cannot set it
    directly thru "make *config", so drivers should select it instead of
    depending on it if they need it.
    
    Consistently using "select" or "depends on" can also help reduce
    Kconfig circular dependency issues.
    
    Therefore, change the use of "depends on REGMAP" to "select REGMAP".
    
    For NVSW_SN2201, select REGMAP_I2C instead of depending on it.
    
    Fixes: c6acad68eb2d ("platform/mellanox: mlxreg-hotplug: Modify to use a regmap interface")
    Fixes: 5ec4a8ace06c ("platform/mellanox: Introduce support for Mellanox register access driver")
    Fixes: 62f9529b8d5c ("platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devices")
    Fixes: 662f24826f95 ("platform/mellanox: Add support for new SN2201 system")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Darren Hart <dvhart@infradead.org>
    Cc: Hans de Goede <hdegoede@redhat.com>
    Cc: Michael Shych <michaelsh@nvidia.com>
    Cc: Mark Gross <markgross@kernel.org>
    Cc: Vadim Pasternak <vadimp@nvidia.com>
    Cc: platform-driver-x86@vger.kernel.org
    Link: https://lore.kernel.org/r/20230226053953.4681-6-rdunlap@infradead.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform: x86: MLX_PLATFORM: select REGMAP instead of depending on it [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Feb 25 21:39:51 2023 -0800

    platform: x86: MLX_PLATFORM: select REGMAP instead of depending on it
    
    [ Upstream commit 7e7e1541c91615e9950d0b96bcd1806d297e970e ]
    
    REGMAP is a hidden (not user visible) symbol. Users cannot set it
    directly thru "make *config", so drivers should select it instead of
    depending on it if they need it.
    
    Consistently using "select" or "depends on" can also help reduce
    Kconfig circular dependency issues.
    
    Therefore, change the use of "depends on REGMAP" to "select REGMAP".
    
    Fixes: ef0f62264b2a ("platform/x86: mlx-platform: Add physical bus number auto detection")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Vadim Pasternak <vadimp@mellanox.com>
    Cc: Darren Hart <dvhart@infradead.org>
    Cc: Hans de Goede <hdegoede@redhat.com>
    Cc: Mark Gross <markgross@kernel.org>
    Cc: platform-driver-x86@vger.kernel.org
    Link: https://lore.kernel.org/r/20230226053953.4681-7-rdunlap@infradead.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/64: Don't recurse irq replay [+ + +]
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Sat Jan 21 20:26:18 2023 +1000

    powerpc/64: Don't recurse irq replay
    
    [ Upstream commit 5746ca131e2496ccd5bb4d7a0244d6c38070cbf5 ]
    
    Interrupt handlers called by soft-pending irq replay code can run
    softirqs, softirq replay enables and disables local irqs, which allows
    interrupts to come in including soft-masked interrupts, and it can
    cause pending irqs to be replayed again. That makes the soft irq replay
    state machine and possible races more complicated and fragile than it
    needs to be.
    
    Use irq_enter/irq_exit around irq replay to prevent softirqs running
    while interrupts are being replayed. Softirqs will now be run at the
    irq_exit() call after all the irq replaying is done. This prevents irqs
    being replayed while irqs are being replayed, and should hopefully make
    things simpler and easier to think about and debug.
    
    A new PACA_IRQ_REPLAYING is added to prevent asynchronous interrupt
    handlers hard-enabling EE while pending irqs are being replayed, because
    that causes new pending irqs to arrive which is also a complexity. This
    means pending irqs won't be profiled quite so well because perf irqs
    can't be taken.
    
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230121102618.2824429-1-npiggin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/64: Fix task_cpu in early boot when booting non-zero cpuid [+ + +]
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Fri Dec 16 21:59:28 2022 +1000

    powerpc/64: Fix task_cpu in early boot when booting non-zero cpuid
    
    [ Upstream commit 9fa24404f5044967753a6cd3e5e36f57686bec6e ]
    
    powerpc/64 can boot on a non-zero SMP processor id. Initially, the boot
    CPU is said to be "assumed to be 0" until early_init_devtree() discovers
    the id from the device tree. That is not a good description because the
    assumption can be wrong and that has to be handled, the better
    description is that 0 is used as a placeholder, and things are fixed
    after the real id is discovered.
    
    smp_processor_id() is set to the boot cpuid, but task_cpu(current) is
    not, which causes the smp_processor_id() == task_cpu(current) invariant
    to be broken until init_idle() in sched_init().
    
    This is quite fragile and could lead to subtle bugs in future. One bug
    is that validate_sp_size uses task_cpu() to get the process stack, so
    any stack trace from the booting CPU between early_init_devtree()
    and sched_init() will have problems. Early on paca_ptrs[0] will be
    poisoned, so that can cause machine checks dereferencing that memory
    in real mode. Later, validating the current stack pointer against the
    idle task of a different secondary will probably cause no stack trace
    to be printed.
    
    Fix this by setting thread_info->cpu right after smp_processor_id() is
    set to the boot cpuid.
    
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    [mpe: Fix SMP=n build as reported by sfr]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20221216115930.2667772-3-npiggin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/64: Move paca allocation to early_setup() [+ + +]
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Fri Dec 16 21:59:29 2022 +1000

    powerpc/64: Move paca allocation to early_setup()
    
    [ Upstream commit dc222fa7737212fe0da513e5b8937c156d02225d ]
    
    The early paca and boot cpuid dance is complicated and currently does
    not quite work as expected for boot cpuid != 0 cases.
    
    early_init_devtree() currently allocates the paca_ptrs and boot cpuid
    paca, but until that returns and early_setup() calls setup_paca(), this
    thread is currently still executing with smp_processor_id() == 0.
    
    One problem this causes is the paca_ptrs[smp_processor_id()] pointer is
    poisoned, so valid_emergency_stack() (any backtrace) and any similar
    users will crash.
    
    Another is that the hardware id which is set here will not be returned
    by get_hard_smp_processor_id(smp_processor_id()), but it would work
    correctly for boot_cpuid == 0, which could lead to difficult to
    reproduce or find bugs. The hard id does not seem to be used by the rest
    of early_init_devtree(), it just looks like all this code might have
    been put here to allocate somewhere to store boot CPU hardware id while
    scanning the devtree.
    
    Rearrange things so the hwid is put in a global variable like
    boot_cpuid, and do all the paca allocation and boot paca setup in the
    64-bit early_setup() after we have everything ready to go.
    
    The paca_ptrs[0] re-poisoning code in early_setup does not seem to have
    ever worked, because paca_ptrs[0] was never not-poisoned when boot_cpuid
    is not 0.
    
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    [mpe: Fix build error on 32-bit]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20221216115930.2667772-4-npiggin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/bpf/32: Only set a stack frame when necessary [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Wed Feb 1 11:04:25 2023 +0100

    powerpc/bpf/32: Only set a stack frame when necessary
    
    [ Upstream commit d084dcf256bc4565b4b1af9b00297ac7b51c7049 ]
    
    Until now a stack frame was set at all time due to the need
    to keep tail call counter in the stack.
    
    But since commit 89d21e259a94 ("powerpc/bpf/32: Fix Oops on tail call
    tests") the tail call counter is passed via register r4. It is therefore
    not necessary anymore to have a stack frame for that.
    
    Just like PPC64, implement bpf_has_stack_frame() and only sets the frame
    when needed.
    
    The difference with PPC64 is that PPC32 doesn't have a redzone, so
    the stack is required as soon as non volatile registers are used or
    when tail call count is set up.
    
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    [mpe: Fix commit reference in change log]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/62d7b654a3cfe73d998697cb29bbc5ffd89bfdb1.1675245773.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/iommu: fix memory leak with using debugfs_lookup() [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 2 15:19:19 2023 +0100

    powerpc/iommu: fix memory leak with using debugfs_lookup()
    
    [ Upstream commit b505063910c134778202dfad9332dfcecb76bab3 ]
    
    When calling debugfs_lookup() the result must have dput() called on it,
    otherwise the memory will leak over time.  To make things simpler, just
    call debugfs_lookup_and_remove() instead which handles all of the logic
    at once.
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230202141919.2298821-1-gregkh@linuxfoundation.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/kcsan: Exclude udelay to prevent recursive instrumentation [+ + +]
Author: Rohan McLure <rmclure@linux.ibm.com>
Date:   Mon Feb 6 13:17:58 2023 +1100

    powerpc/kcsan: Exclude udelay to prevent recursive instrumentation
    
    [ Upstream commit 2a7ce82dc46c591c9244057d89a6591c9639b9b9 ]
    
    In order for KCSAN to increase its likelihood of observing a data race,
    it sets a watchpoint on memory accesses and stalls, allowing for
    detection of conflicting accesses by other kernel threads or interrupts.
    
    Stalls are implemented by injecting a call to udelay in instrumented code.
    To prevent recursive instrumentation, exclude udelay from being instrumented.
    
    Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230206021801.105268-3-rmclure@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc: dts: t1040rdb: fix compatible string for Rev A boards [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Fri Feb 24 17:59:39 2023 +0200

    powerpc: dts: t1040rdb: fix compatible string for Rev A boards
    
    [ Upstream commit ae44f1c9d1fc54aeceb335fedb1e73b2c3ee4561 ]
    
    It looks like U-Boot fails to start the kernel properly when the
    compatible string of the board isn't fsl,T1040RDB, so stop overriding it
    from the rev-a.dts.
    
    Fixes: 5ebb74749202 ("powerpc: dts: t1040rdb: fix ports names for Seville Ethernet switch")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "bpf, test_run: fix &xdp_frame misplacement for LIVE_FRAMES" [+ + +]
Author: Martin KaFai Lau <martin.lau@kernel.org>
Date:   Fri Feb 17 12:13:09 2023 -0800

    Revert "bpf, test_run: fix &xdp_frame misplacement for LIVE_FRAMES"
    
    commit 181127fb76e62d06ab17a75fd610129688612343 upstream.
    
    This reverts commit 6c20822fada1b8adb77fa450d03a0d449686a4a9.
    
    build bot failed on arch with different cache line size:
    https://lore.kernel.org/bpf/50c35055-afa9-d01e-9a05-ea5351280e4f@intel.com/
    
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RISC-V: Don't check text_mutex during stop_machine [+ + +]
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Fri Mar 3 14:37:55 2023 +0000

    RISC-V: Don't check text_mutex during stop_machine
    
    [ Upstream commit 2a8db5ec4a28a0fce822d10224db9471a44b6925 ]
    
    We're currently using stop_machine() to update ftrace & kprobes, which
    means that the thread that takes text_mutex during may not be the same
    as the thread that eventually patches the code.  This isn't actually a
    race because the lock is still held (preventing any other concurrent
    accesses) and there is only one thread running during stop_machine(),
    but it does trigger a lockdep failure.
    
    This patch just elides the lockdep check during stop_machine.
    
    Fixes: c15ac4fd60d5 ("riscv/ftrace: Add dynamic function tracer support")
    Suggested-by: Steven Rostedt <rostedt@goodmis.org>
    Reported-by: Changbin Du <changbin.du@gmail.com>
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Link: https://lore.kernel.org/r/20230303143754.4005217-1-conor.dooley@microchip.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RISC-V: Stop emitting attributes [+ + +]
Author: Palmer Dabbelt <palmer@rivosinc.com>
Date:   Thu Feb 23 14:46:05 2023 -0800

    RISC-V: Stop emitting attributes
    
    commit e18048da9bc3f87acef4eb67a11b4fc55fe15424 upstream.
    
    The RISC-V ELF attributes don't contain any useful information.  New
    toolchains ignore them, but they frequently trip up various older/mixed
    toolchains.  So just turn them off.
    
    Tested-by: Conor Dooley <conor.dooley@microchip.com>
    Link: https://lore.kernel.org/r/20230223224605.6995-1-palmer@rivosinc.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
riscv: Add header include guards to insn.h [+ + +]
Author: Liao Chang <liaochang1@huawei.com>
Date:   Sun Jan 29 17:42:42 2023 +0800

    riscv: Add header include guards to insn.h
    
    [ Upstream commit 8ac6e619d9d51b3eb5bae817db8aa94e780a0db4 ]
    
    Add header include guards to insn.h to prevent repeating declaration of
    any identifiers in insn.h.
    
    Fixes: edde5584c7ab ("riscv: Add SW single-step support for KDB")
    Signed-off-by: Liao Chang <liaochang1@huawei.com>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Fixes: c9c1af3f186a ("RISC-V: rename parse_asm.h to insn.h")
    Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
    Link: https://lore.kernel.org/r/20230129094242.282620-1-liaochang1@huawei.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack mode [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Wed Mar 8 10:16:39 2023 +0100

    riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack mode
    
    [ Upstream commit 76950340cf03b149412fe0d5f0810e52ac1df8cb ]
    
    When CONFIG_FRAME_POINTER is unset, the stack unwinding function
    walk_stackframe randomly reads the stack and then, when KASAN is enabled,
    it can lead to the following backtrace:
    
    [    0.000000] ==================================================================
    [    0.000000] BUG: KASAN: stack-out-of-bounds in walk_stackframe+0xa6/0x11a
    [    0.000000] Read of size 8 at addr ffffffff81807c40 by task swapper/0
    [    0.000000]
    [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.2.0-12919-g24203e6db61f #43
    [    0.000000] Hardware name: riscv-virtio,qemu (DT)
    [    0.000000] Call Trace:
    [    0.000000] [<ffffffff80007ba8>] walk_stackframe+0x0/0x11a
    [    0.000000] [<ffffffff80099ecc>] init_param_lock+0x26/0x2a
    [    0.000000] [<ffffffff80007c4a>] walk_stackframe+0xa2/0x11a
    [    0.000000] [<ffffffff80c49c80>] dump_stack_lvl+0x22/0x36
    [    0.000000] [<ffffffff80c3783e>] print_report+0x198/0x4a8
    [    0.000000] [<ffffffff80099ecc>] init_param_lock+0x26/0x2a
    [    0.000000] [<ffffffff80007c4a>] walk_stackframe+0xa2/0x11a
    [    0.000000] [<ffffffff8015f68a>] kasan_report+0x9a/0xc8
    [    0.000000] [<ffffffff80007c4a>] walk_stackframe+0xa2/0x11a
    [    0.000000] [<ffffffff80007c4a>] walk_stackframe+0xa2/0x11a
    [    0.000000] [<ffffffff8006e99c>] desc_make_final+0x80/0x84
    [    0.000000] [<ffffffff8009a04e>] stack_trace_save+0x88/0xa6
    [    0.000000] [<ffffffff80099fc2>] filter_irq_stacks+0x72/0x76
    [    0.000000] [<ffffffff8006b95e>] devkmsg_read+0x32a/0x32e
    [    0.000000] [<ffffffff8015ec16>] kasan_save_stack+0x28/0x52
    [    0.000000] [<ffffffff8006e998>] desc_make_final+0x7c/0x84
    [    0.000000] [<ffffffff8009a04a>] stack_trace_save+0x84/0xa6
    [    0.000000] [<ffffffff8015ec52>] kasan_set_track+0x12/0x20
    [    0.000000] [<ffffffff8015f22e>] __kasan_slab_alloc+0x58/0x5e
    [    0.000000] [<ffffffff8015e7ea>] __kmem_cache_create+0x21e/0x39a
    [    0.000000] [<ffffffff80e133ac>] create_boot_cache+0x70/0x9c
    [    0.000000] [<ffffffff80e17ab2>] kmem_cache_init+0x6c/0x11e
    [    0.000000] [<ffffffff80e00fd6>] mm_init+0xd8/0xfe
    [    0.000000] [<ffffffff80e011d8>] start_kernel+0x190/0x3ca
    [    0.000000]
    [    0.000000] The buggy address belongs to stack of task swapper/0
    [    0.000000]  and is located at offset 0 in frame:
    [    0.000000]  stack_trace_save+0x0/0xa6
    [    0.000000]
    [    0.000000] This frame has 1 object:
    [    0.000000]  [32, 56) 'c'
    [    0.000000]
    [    0.000000] The buggy address belongs to the physical page:
    [    0.000000] page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81a07
    [    0.000000] flags: 0x1000(reserved|zone=0)
    [    0.000000] raw: 0000000000001000 ff600003f1e3d150 ff600003f1e3d150 0000000000000000
    [    0.000000] raw: 0000000000000000 0000000000000000 00000001ffffffff
    [    0.000000] page dumped because: kasan: bad access detected
    [    0.000000]
    [    0.000000] Memory state around the buggy address:
    [    0.000000]  ffffffff81807b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [    0.000000]  ffffffff81807b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [    0.000000] >ffffffff81807c00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f3
    [    0.000000]                                            ^
    [    0.000000]  ffffffff81807c80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
    [    0.000000]  ffffffff81807d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [    0.000000] ==================================================================
    
    Fix that by using READ_ONCE_NOCHECK when reading the stack in imprecise
    mode.
    
    Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
    Reported-by: Chathura Rajapaksha <chathura.abeyrathne.lk@gmail.com>
    Link: https://lore.kernel.org/all/CAD7mqryDQCYyJ1gAmtMm8SASMWAQ4i103ptTb0f6Oda=tPY2=A@mail.gmail.com/
    Suggested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Link: https://lore.kernel.org/r/20230308091639.602024-1-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scripts: handle BrokenPipeError for python scripts [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu Jan 12 11:30:06 2023 +0900

    scripts: handle BrokenPipeError for python scripts
    
    [ Upstream commit 87c7ee67deb7fce9951a5f9d80641138694aad17 ]
    
    In the follow-up of commit fb3041d61f68 ("kbuild: fix SIGPIPE error
    message for AR=gcc-ar and AR=llvm-ar"), Kees Cook pointed out that
    tools should _not_ catch their own SIGPIPEs [1] [2].
    
    Based on his feedback, LLVM was fixed [3].
    
    However, Python's default behavior is to show noisy bracktrace when
    SIGPIPE is sent. So, scripts written in Python are basically in the
    same situation as the buggy llvm tools.
    
    Example:
    
      $ make -s allnoconfig
      $ make -s allmodconfig
      $ scripts/diffconfig .config.old .config | head -n1
      -ALIX n
      Traceback (most recent call last):
        File "/home/masahiro/linux/scripts/diffconfig", line 132, in <module>
          main()
        File "/home/masahiro/linux/scripts/diffconfig", line 130, in main
          print_config("+", config, None, b[config])
        File "/home/masahiro/linux/scripts/diffconfig", line 64, in print_config
          print("+%s %s" % (config, new_value))
      BrokenPipeError: [Errno 32] Broken pipe
    
    Python documentation [4] notes how to make scripts die immediately and
    silently:
    
      """
      Piping output of your program to tools like head(1) will cause a
      SIGPIPE signal to be sent to your process when the receiver of its
      standard output closes early. This results in an exception like
      BrokenPipeError: [Errno 32] Broken pipe. To handle this case,
      wrap your entry point to catch this exception as follows:
    
        import os
        import sys
    
        def main():
            try:
                # simulate large output (your code replaces this loop)
                for x in range(10000):
                    print("y")
                # flush output here to force SIGPIPE to be triggered
                # while inside this try block.
                sys.stdout.flush()
            except BrokenPipeError:
                # Python flushes standard streams on exit; redirect remaining output
                # to devnull to avoid another BrokenPipeError at shutdown
                devnull = os.open(os.devnull, os.O_WRONLY)
                os.dup2(devnull, sys.stdout.fileno())
                sys.exit(1)  # Python exits with error code 1 on EPIPE
    
        if __name__ == '__main__':
            main()
    
      Do not set SIGPIPE’s disposition to SIG_DFL in order to avoid
      BrokenPipeError. Doing that would cause your program to exit
      unexpectedly whenever any socket connection is interrupted while
      your program is still writing to it.
      """
    
    Currently, tools/perf/scripts/python/intel-pt-events.py seems to be the
    only script that fixes the issue that way.
    
    tools/perf/scripts/python/compaction-times.py uses another approach
    signal.signal(signal.SIGPIPE, signal.SIG_DFL) but the Python
    documentation clearly says "Don't do it".
    
    I cannot fix all Python scripts since there are so many.
    I fixed some in the scripts/ directory.
    
    [1]: https://lore.kernel.org/all/202211161056.1B9611A@keescook/
    [2]: https://github.com/llvm/llvm-project/issues/59037
    [3]: https://github.com/llvm/llvm-project/commit/4787efa38066adb51e2c049499d25b3610c0877b
    [4]: https://docs.python.org/3/library/signal.html#note-on-sigpipe
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: core: Remove the /proc/scsi/${proc_name} directory earlier [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Fri Feb 10 12:52:00 2023 -0800

    scsi: core: Remove the /proc/scsi/${proc_name} directory earlier
    
    [ Upstream commit fc663711b94468f4e1427ebe289c9f05669699c9 ]
    
    Remove the /proc/scsi/${proc_name} directory earlier to fix a race
    condition between unloading and reloading kernel modules. This fixes a bug
    introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in
    the SCSI core").
    
    Fix the following kernel warning:
    
    proc_dir_entry 'scsi/scsi_debug' already registered
    WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0
    Call Trace:
     proc_mkdir+0xb5/0xe0
     scsi_proc_hostdir_add+0xb5/0x170
     scsi_host_alloc+0x683/0x6c0
     sdebug_driver_probe+0x6b/0x2d0 [scsi_debug]
     really_probe+0x159/0x540
     __driver_probe_device+0xdc/0x230
     driver_probe_device+0x4f/0x120
     __device_attach_driver+0xef/0x180
     bus_for_each_drv+0xe5/0x130
     __device_attach+0x127/0x290
     device_initial_probe+0x17/0x20
     bus_probe_device+0x110/0x130
     device_add+0x673/0xc80
     device_register+0x1e/0x30
     sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug]
     scsi_debug_init+0x64f/0x1000 [scsi_debug]
     do_one_initcall+0xd7/0x470
     do_init_module+0xe7/0x330
     load_module+0x122a/0x12c0
     __do_sys_finit_module+0x124/0x1a0
     __x64_sys_finit_module+0x46/0x50
     do_syscall_64+0x38/0x80
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Link: https://lore.kernel.org/r/20230210205200.36973-3-bvanassche@acm.org
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Yi Zhang <yi.zhang@redhat.com>
    Cc: stable@vger.kernel.org
    Fixes: 77c019768f06 ("[SCSI] fix /proc memory leak in the SCSI core")
    Reported-by: Yi Zhang <yi.zhang@redhat.com>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: megaraid_sas: Update max supported LD IDs to 240 [+ + +]
Author: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Date:   Thu Mar 2 16:23:40 2023 +0530

    scsi: megaraid_sas: Update max supported LD IDs to 240
    
    [ Upstream commit bfa659177dcba48cf13f2bd88c1972f12a60bf1c ]
    
    The firmware only supports Logical Disk IDs up to 240 and LD ID 255 (0xFF)
    is reserved for deleted LDs. However, in some cases, firmware was assigning
    LD ID 254 (0xFE) to deleted LDs and this was causing the driver to mark the
    wrong disk as deleted. This in turn caused the wrong disk device to be
    taken offline by the SCSI midlayer.
    
    To address this issue, limit the LD ID range from 255 to 240. This ensures
    the deleted LD ID is properly identified and removed by the driver without
    accidently deleting any valid LDs.
    
    Fixes: ae6874ba4b43 ("scsi: megaraid_sas: Early detection of VD deletion through RaidMap update")
    Reported-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
    Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
    Link: https://lore.kernel.org/r/20230302105342.34933-2-chandrakanth.patil@broadcom.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: sd: Fix wrong zone_write_granularity value during revalidate [+ + +]
Author: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Date:   Mon Mar 6 15:30:24 2023 +0900

    scsi: sd: Fix wrong zone_write_granularity value during revalidate
    
    [ Upstream commit 288b3271d920c9ba949c3bab0f749f4cecc70e09 ]
    
    When the sd driver revalidates host-managed SMR disks, it calls
    disk_set_zoned() which changes the zone_write_granularity attribute value
    to the logical block size regardless of the device type. After that, the sd
    driver overwrites the value in sd_zbc_read_zone() with the physical block
    size, since ZBC/ZAC requires this for host-managed disks. Between the calls
    to disk_set_zoned() and sd_zbc_read_zone(), there exists a window where the
    attribute shows the logical block size as the zone_write_granularity value,
    which is wrong for host-managed disks. The duration of the window is from
    20ms to 200ms, depending on report zone command execution time.
    
    To avoid the wrong zone_write_granularity value between disk_set_zoned()
    and sd_zbc_read_zone(), modify the value not in sd_zbc_read_zone() but
    just after disk_set_zoned() call.
    
    Fixes: a805a4fa4fa3 ("block: introduce zone_write_granularity limit")
    Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Link: https://lore.kernel.org/r/20230306063024.3376959-1-shinichiro.kawasaki@wdc.com
    Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: nft_nat: ensuring the listening side is up before starting the client [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Mon Feb 27 17:36:46 2023 +0800

    selftests: nft_nat: ensuring the listening side is up before starting the client
    
    [ Upstream commit 2067e7a00aa604b94de31d64f29b8893b1696f26 ]
    
    The test_local_dnat_portonly() function initiates the client-side as
    soon as it sets the listening side to the background. This could lead to
    a race condition where the server may not be ready to listen. To ensure
    that the server-side is up and running before initiating the
    client-side, a delay is introduced to the test_local_dnat_portonly()
    function.
    
    Before the fix:
      # ./nft_nat.sh
      PASS: netns routing/connectivity: ns0-rthlYrBU can reach ns1-rthlYrBU and ns2-rthlYrBU
      PASS: ping to ns1-rthlYrBU was ip NATted to ns2-rthlYrBU
      PASS: ping to ns1-rthlYrBU OK after ip nat output chain flush
      PASS: ipv6 ping to ns1-rthlYrBU was ip6 NATted to ns2-rthlYrBU
      2023/02/27 04:11:03 socat[6055] E connect(5, AF=2 10.0.1.99:2000, 16): Connection refused
      ERROR: inet port rewrite
    
    After the fix:
      # ./nft_nat.sh
      PASS: netns routing/connectivity: ns0-9sPJV6JJ can reach ns1-9sPJV6JJ and ns2-9sPJV6JJ
      PASS: ping to ns1-9sPJV6JJ was ip NATted to ns2-9sPJV6JJ
      PASS: ping to ns1-9sPJV6JJ OK after ip nat output chain flush
      PASS: ipv6 ping to ns1-9sPJV6JJ was ip6 NATted to ns2-9sPJV6JJ
      PASS: inet port rewrite without l3 address
    
    Fixes: 282e5f8fe907 ("netfilter: nat: really support inet nat without l3 address")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spi: intel: Check number of chip selects after reading the descriptor [+ + +]
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Wed Feb 15 13:00:40 2023 +0200

    spi: intel: Check number of chip selects after reading the descriptor
    
    [ Upstream commit 574fbb95cd9d88bdc9c9c4c64223a38a61d7de9a ]
    
    The flash decriptor contains the number of flash components that we use
    to figure out how many flash chips there are connected. Therefore we
    need to read it first before deciding how many chip selects the
    controller has.
    
    Reported-by: Marcin Witkowski <marcin.witkowski@intel.com>
    Fixes: 3f03c618bebb ("spi: intel: Add support for second flash chip")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Link: https://lore.kernel.org/r/20230215110040.42186-1-mika.westerberg@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
staging: rtl8723bs: Fix key-store index handling [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Mar 6 16:35:11 2023 +0100

    staging: rtl8723bs: Fix key-store index handling
    
    commit 05cbcc415c9b8c8bc4f9a09f8e03610a89042f03 upstream.
    
    There are 2 issues with the key-store index handling
    
    1. The non WEP key stores can store keys with indexes 0 - BIP_MAX_KEYID,
       this means that they should be an array with BIP_MAX_KEYID + 1
       entries. But some of the arrays where just BIP_MAX_KEYID entries
       big. While one other array was hardcoded to a size of 6 entries,
       instead of using the BIP_MAX_KEYID define.
    
    2. The rtw_cfg80211_set_encryption() and wpa_set_encryption() functions
       index check where checking that the passed in key-index would fit
       inside both the WEP key store (which only has 4 entries) as well as
       in the non WEP key stores. This breaks any attempts to set non WEP
       keys with index 4 or 5.
    
    Issue 2. specifically breaks wifi connection with some access points
    which advertise PMF support. Without this fix connecting to these
    access points fails with the following wpa_supplicant messages:
    
     nl80211: kernel reports: key addition failed
     wlan0: WPA: Failed to configure IGTK to the driver
     wlan0: RSN: Failed to configure IGTK
     wlan0: CTRL-EVENT-DISCONNECTED bssid=... reason=1 locally_generated=1
    
    Fix 1. by using the right size for the key-stores. After this 2. can
    safely be fixed by checking the right max-index value depending on the
    used algorithm, fixing wifi not working with some PMF capable APs.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20230306153512.162104-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: rtl8723bs: Pass correct parameters to cfg80211_get_bss() [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Mar 6 16:35:12 2023 +0100

    staging: rtl8723bs: Pass correct parameters to cfg80211_get_bss()
    
    commit d17789edd6a8270c38459e592ee536a84c6202db upstream.
    
    To last 2 parameters to cfg80211_get_bss() should be of
    the enum ieee80211_bss_type resp. enum ieee80211_privacy types,
    which WLAN_CAPABILITY_ESS very much is not.
    
    Fix both cfg80211_get_bss() calls in ioctl_cfg80211.c to pass
    the right parameters.
    
    Note that the second call was already somewhat fixed by commenting
    out WLAN_CAPABILITY_ESS and passing in 0 instead. This was still
    not entirely correct though since that would limit returned
    BSS-es to ESS type BSS-es with privacy on.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20230306153512.162104-2-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
SUNRPC: Fix a server shutdown leak [+ + +]
Author: Benjamin Coddington <bcodding@redhat.com>
Date:   Fri Mar 3 16:08:32 2023 -0500

    SUNRPC: Fix a server shutdown leak
    
    [ Upstream commit 9ca6705d9d609441d34f8b853e1e4a6369b3b171 ]
    
    Fix a race where kthread_stop() may prevent the threadfn from ever getting
    called.  If that happens the svc_rqst will not be cleaned up.
    
    Fixes: ed6473ddc704 ("NFSv4: Fix callback server shutdown")
    Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tls: rx: fix return value for async crypto [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Mon Feb 27 10:12:01 2023 -0800

    tls: rx: fix return value for async crypto
    
    [ Upstream commit 4d42cd6bc2ac1b9be50ade13771daec90c9d18b1 ]
    
    Gaurav reports that TLS Rx is broken with async crypto
    accelerators. The commit under fixes missed updating
    the retval byte counting logic when updating how records
    are stored. Even tho both before and after the change
    'decrypted' was updated inside the main loop, it was
    completely overwritten when processing the async
    completions. Now that the rx_list only holds
    non-zero-copy records we need to add, not overwrite.
    
    Reported-and-bisected-by: Gaurav Jain <gaurav.jain@nxp.com>
    Fixes: cbbdee9918a2 ("tls: rx: async: don't put async zc on the list")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217064
    Tested-by: Gaurav Jain <gaurav.jain@nxp.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/20230227181201.1793772-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tpm/eventlog: Don't abort tpm_read_log on faulty ACPI address [+ + +]
Author: Morten Linderud <morten@linderud.pw>
Date:   Wed Feb 15 10:25:52 2023 +0100

    tpm/eventlog: Don't abort tpm_read_log on faulty ACPI address
    
    [ Upstream commit 80a6c216b16d7f5c584d2148c2e4345ea4eb06ce ]
    
    tpm_read_log_acpi() should return -ENODEV when no eventlog from the ACPI
    table is found. If the firmware vendor includes an invalid log address
    we are unable to map from the ACPI memory and tpm_read_log() returns -EIO
    which would abort discovery of the eventlog.
    
    Change the return value from -EIO to -ENODEV when acpi_os_map_iomem()
    fails to map the event log.
    
    The following hardware was used to test this issue:
        Framework Laptop (Pre-production)
        BIOS: INSYDE Corp, Revision: 3.2
        TPM Device: NTC, Firmware Revision: 7.2
    
    Dump of the faulty ACPI TPM2 table:
        [000h 0000   4]                    Signature : "TPM2"    [Trusted Platform Module hardware interface Table]
        [004h 0004   4]                 Table Length : 0000004C
        [008h 0008   1]                     Revision : 04
        [009h 0009   1]                     Checksum : 2B
        [00Ah 0010   6]                       Oem ID : "INSYDE"
        [010h 0016   8]                 Oem Table ID : "TGL-ULT"
        [018h 0024   4]                 Oem Revision : 00000002
        [01Ch 0028   4]              Asl Compiler ID : "ACPI"
        [020h 0032   4]        Asl Compiler Revision : 00040000
    
        [024h 0036   2]               Platform Class : 0000
        [026h 0038   2]                     Reserved : 0000
        [028h 0040   8]              Control Address : 0000000000000000
        [030h 0048   4]                 Start Method : 06 [Memory Mapped I/O]
    
        [034h 0052  12]            Method Parameters : 00 00 00 00 00 00 00 00 00 00 00 00
        [040h 0064   4]           Minimum Log Length : 00010000
        [044h 0068   8]                  Log Address : 000000004053D000
    
    Fixes: 0cf577a03f21 ("tpm: Fix handling of missing event log")
    Tested-by: Erkki Eilonen <erkki@bearmetal.eu>
    Signed-off-by: Morten Linderud <morten@linderud.pw>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
udf: Fix off-by-one error when discarding preallocation [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jan 23 14:29:15 2023 +0100

    udf: Fix off-by-one error when discarding preallocation
    
    [ Upstream commit f54aa97fb7e5329a373f9df4e5e213ced4fc8759 ]
    
    The condition determining whether the preallocation can be used had
    an off-by-one error so we didn't discard preallocation when new
    allocation was just following it. This can then confuse code in
    inode_getblk().
    
    CC: stable@vger.kernel.org
    Fixes: 16d055656814 ("udf: Discard preallocation before extending file with a hole")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
UML: define RUNTIME_DISCARD_EXIT [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Wed Feb 8 01:41:56 2023 +0900

    UML: define RUNTIME_DISCARD_EXIT
    
    commit b99ddbe8336ee680257c8ab479f75051eaa49dcf upstream.
    
    With CONFIG_VIRTIO_UML=y, GNU ld < 2.36 fails to link UML vmlinux
    (w/wo CONFIG_LD_SCRIPT_STATIC).
    
      `.exit.text' referenced in section `.uml.exitcall.exit' of arch/um/drivers/virtio_uml.o: defined in discarded section `.exit.text' of arch/um/drivers/virtio_uml.o
      collect2: error: ld returned 1 exit status
    
    This fix is similar to the following commits:
    
    - 4b9880dbf3bd ("powerpc/vmlinux.lds: Define RUNTIME_DISCARD_EXIT")
    - a494398bde27 ("s390: define RUNTIME_DISCARD_EXIT to fix link error
      with GNU ld < 2.36")
    - c1c551bebf92 ("sh: define RUNTIME_DISCARD_EXIT")
    
    Fixes: 99cb0d917ffa ("arch: fix broken BuildID for arm64 and riscv")
    Reported-by: SeongJae Park <sj@kernel.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Tested-by: SeongJae Park <sj@kernel.org>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
watch_queue: fix IOC_WATCH_QUEUE_SET_SIZE alloc error paths [+ + +]
Author: David Disseldorp <ddiss@suse.de>
Date:   Tue Mar 7 16:21:06 2023 +0100

    watch_queue: fix IOC_WATCH_QUEUE_SET_SIZE alloc error paths
    
    [ Upstream commit 03e1d60e177eedbd302b77af4ea5e21b5a7ade31 ]
    
    The watch_queue_set_size() allocation error paths return the ret value
    set via the prior pipe_resize_ring() call, which will always be zero.
    
    As a result, IOC_WATCH_QUEUE_SET_SIZE callers such as "keyctl watch"
    fail to detect kernel wqueue->notes allocation failures and proceed to
    KEYCTL_WATCH_KEY, with any notifications subsequently lost.
    
    Fixes: c73be61cede58 ("pipe: Add general notification queue support")
    Signed-off-by: David Disseldorp <ddiss@suse.de>
    Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/CPU/AMD: Disable XSAVES on AMD family 0x17 [+ + +]
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Tue Mar 7 17:46:43 2023 +0000

    x86/CPU/AMD: Disable XSAVES on AMD family 0x17
    
    commit b0563468eeac88ebc70559d52a0b66efc37e4e9d upstream.
    
    AMD Erratum 1386 is summarised as:
    
      XSAVES Instruction May Fail to Save XMM Registers to the Provided
      State Save Area
    
    This piece of accidental chronomancy causes the %xmm registers to
    occasionally reset back to an older value.
    
    Ignore the XSAVES feature on all AMD Zen1/2 hardware.  The XSAVEC
    instruction (which works fine) is equivalent on affected parts.
    
      [ bp: Typos, move it into the F17h-specific function. ]
    
    Reported-by: Tavis Ormandy <taviso@gmail.com>
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: <stable@kernel.org>
    Link: https://lore.kernel.org/r/20230307174643.1240184-1-andrew.cooper3@citrix.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>