Linux 6.1.65

 
ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CVA [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Nov 15 19:02:22 2023 +0100

    ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CVA
    
    commit bd911485294a6f0596e4592ed442438015cffc8a upstream.
    
    Like various other ASUS ExpertBook-s, the ASUS ExpertBook B1402CVA
    has an ACPI DSDT table that describes IRQ 1 as ActiveLow while
    the kernel overrides it to EdgeHigh.
    
    This prevents the keyboard from working. To fix this issue, add this laptop
    to the skip_override_table so that the kernel does not override IRQ 1.
    
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218114
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
afs: Fix afs_server_list to be cleaned up with RCU [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Thu Nov 2 16:26:59 2023 +0000

    afs: Fix afs_server_list to be cleaned up with RCU
    
    [ Upstream commit e6bace7313d61e31f2b16fa3d774fd8cb3cb869e ]
    
    afs_server_list is accessed with the rcu_read_lock() held from
    volume->servers, so it needs to be cleaned up correctly.
    
    Fix this by using kfree_rcu() instead of kfree().
    
    Fixes: 8a070a964877 ("afs: Detect cell aliases 1 - Cells with root volumes")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>
afs: Fix file locking on R/O volumes to operate in local mode [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Wed Nov 1 22:03:28 2023 +0000

    afs: Fix file locking on R/O volumes to operate in local mode
    
    [ Upstream commit b590eb41be766c5a63acc7e8896a042f7a4e8293 ]
    
    AFS doesn't really do locking on R/O volumes as fileservers don't maintain
    state with each other and thus a lock on a R/O volume file on one
    fileserver will not be be visible to someone looking at the same file on
    another fileserver.
    
    Further, the server may return an error if you try it.
    
    Fix this by doing what other AFS clients do and handle filelocking on R/O
    volume files entirely within the client and don't touch the server.
    
    Fixes: 6c6c1d63c243 ("afs: Provide mount-time configurable byte-range file locking emulation")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

afs: Make error on cell lookup failure consistent with OpenAFS [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Thu Jun 8 09:43:54 2023 +0100

    afs: Make error on cell lookup failure consistent with OpenAFS
    
    [ Upstream commit 2a4ca1b4b77850544408595e2433f5d7811a9daa ]
    
    When kafs tries to look up a cell in the DNS or the local config, it will
    translate a lookup failure into EDESTADDRREQ whereas OpenAFS translates it
    into ENOENT.  Applications such as West expect the latter behaviour and
    fail if they see the former.
    
    This can be seen by trying to mount an unknown cell:
    
       # mount -t afs %example.com:cell.root /mnt
       mount: /mnt: mount(2) system call failed: Destination address required.
    
    Fixes: 4d673da14533 ("afs: Support the AFS dynamic root")
    Reported-by: Markus Suvanto <markus.suvanto@gmail.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216637
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

afs: Return ENOENT if no cell DNS record can be found [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Thu Oct 26 01:25:07 2023 +0100

    afs: Return ENOENT if no cell DNS record can be found
    
    [ Upstream commit 0167236e7d66c5e1e85d902a6abc2529b7544539 ]
    
    Make AFS return error ENOENT if no cell SRV or AFSDB DNS record (or
    cellservdb config file record) can be found rather than returning
    EDESTADDRREQ.
    
    Also add cell name lookup info to the cursor dump.
    
    Fixes: d5c32c89b208 ("afs: Fix cell DNS lookup")
    Reported-by: Markus Suvanto <markus.suvanto@gmail.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216637
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
amd-xgbe: handle corner-case during sfp hotplug [+ + +]
Author: Raju Rangoju <Raju.Rangoju@amd.com>
Date:   Wed Nov 22 00:44:33 2023 +0530

    amd-xgbe: handle corner-case during sfp hotplug
    
    [ Upstream commit 676ec53844cbdf2f47e68a076cdff7f0ec6cbe3f ]
    
    Force the mode change for SFI in Fixed PHY configurations. Fixed PHY
    configurations needs PLL to be enabled while doing mode set. When the
    SFP module isn't connected during boot, driver assumes AN is ON and
    attempts auto-negotiation. However, if the connected SFP comes up in
    Fixed PHY configuration the link will not come up as PLL isn't enabled
    while the initial mode set command is issued. So, force the mode change
    for SFI in Fixed PHY configuration to fix link issues.
    
    Fixes: e57f7a3feaef ("amd-xgbe: Prepare for working with more than one type of phy")
    Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

amd-xgbe: handle the corner-case during tx completion [+ + +]
Author: Raju Rangoju <Raju.Rangoju@amd.com>
Date:   Wed Nov 22 00:44:34 2023 +0530

    amd-xgbe: handle the corner-case during tx completion
    
    [ Upstream commit 7121205d5330c6a3cb3379348886d47c77b78d06 ]
    
    The existing implementation uses software logic to accumulate tx
    completions until the specified time (1ms) is met and then poll them.
    However, there exists a tiny gap which leads to a race between
    resetting and checking the tx_activate flag. Due to this the tx
    completions are not reported to upper layer and tx queue timeout
    kicks-in restarting the device.
    
    To address this, introduce a tx cleanup mechanism as part of the
    periodic maintenance process.
    
    Fixes: c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver")
    Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

amd-xgbe: propagate the correct speed and duplex status [+ + +]
Author: Raju Rangoju <Raju.Rangoju@amd.com>
Date:   Wed Nov 22 00:44:35 2023 +0530

    amd-xgbe: propagate the correct speed and duplex status
    
    [ Upstream commit 7a2323ac24a50311f64a3a9b54ed5bef5821ecae ]
    
    xgbe_get_link_ksettings() does not propagate correct speed and duplex
    information to ethtool during cable unplug. Due to which ethtool reports
    incorrect values for speed and duplex.
    
    Address this by propagating correct information.
    
    Fixes: 7c12aa08779c ("amd-xgbe: Move the PHY support into amd-xgbe")
    Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm/xen: fix xen_vcpu_info allocation alignment [+ + +]
Author: Stefano Stabellini <sstabellini@kernel.org>
Date:   Wed Nov 22 15:07:41 2023 -0800

    arm/xen: fix xen_vcpu_info allocation alignment
    
    [ Upstream commit 7bf9a6b46549852a37e6d07e52c601c3c706b562 ]
    
    xen_vcpu_info is a percpu area than needs to be mapped by Xen.
    Currently, it could cross a page boundary resulting in Xen being unable
    to map it:
    
    [    0.567318] kernel BUG at arch/arm64/xen/../../arm/xen/enlighten.c:164!
    [    0.574002] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
    
    Fix the issue by using __alloc_percpu and requesting alignment for the
    memory allocation.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
    
    Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2311221501340.2053963@ubuntu-linux-20-04-desktop
    Fixes: 24d5373dda7c ("arm/xen: Use alloc_percpu rather than __alloc_percpu")
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: imx8mn-var-som: add 20ms delay to ethernet regulator enable [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Mon May 29 15:33:12 2023 -0400

    arm64: dts: imx8mn-var-som: add 20ms delay to ethernet regulator enable
    
    commit 26ca44bdbd13edbe6cbe0dc63327c3316ce01bae upstream.
    
    This commit is taken from Variscite linux kernel public git repository.
    Original patch author: Nate Drude <nate.d@variscite.com>
    See: https://github.com/varigit/linux-imx/blob/5.15-2.0.x-imx_var01/drivers/net/ethernet/freescale/fec_main.c#L3993-L4050
    
    The ethernet phy reset was moved from the fec controller to the
    mdio bus, see for example: 0e825b32c033e1998d0ebaf247f5dab3c340e3bf
    
    When the fec driver managed the reset, the regulator had time to
    settle during the fec phy reset before calling of_mdiobus_register,
    which probes the mii bus for the phy id to match the correct driver.
    
    Now that the mdio bus controls the reset, the fec driver no longer has
    any delay between enabling the regulator and calling of_mdiobus_register.
    If the regulator voltage has not settled, the phy id will not be read
    correctly and the generic phy driver will be used.
    
    The following call tree explains in more detail:
    
    fec_probe
      fec_reset_phy                               <- no longer introduces delay after migration to mdio reset
      fec_enet_mii_init
        of_mdiobus_register
          of_mdiobus_register_phy
            fwnode_mdiobus_register_phy
              get_phy_device                      <- mii probe for phy id to match driver happens here
              ...
              fwnode_mdiobus_phy_device_register
                phy_device_register
                  mdiobus_register_device
                    mdio_device_reset             <- mdio reset assert / deassert delay happens here
    
    Add a 20ms enable delay to the regulator to fix the issue.
    
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: mm: Fix "rodata=on" when CONFIG_RODATA_FULL_DEFAULT_ENABLED=y [+ + +]
Author: Will Deacon <will@kernel.org>
Date:   Fri Nov 17 13:14:22 2023 +0000

    arm64: mm: Fix "rodata=on" when CONFIG_RODATA_FULL_DEFAULT_ENABLED=y
    
    [ Upstream commit acfa60dbe03802d6afd28401aa47801270e82021 ]
    
    When CONFIG_RODATA_FULL_DEFAULT_ENABLED=y, passing "rodata=on" on the
    kernel command-line (rather than "rodata=full") should turn off the
    "full" behaviour, leaving writable linear aliases of read-only kernel
    memory. Unfortunately, the option has no effect in this situation and
    the only way to disable the "rodata=full" behaviour is to disable rodata
    protection entirely by passing "rodata=off".
    
    Fix this by parsing the "on" and "off" options in the arch code,
    additionally enforcing that 'rodata_full' cannot be set without also
    setting 'rodata_enabled', allowing us to simplify a couple of checks
    in the process.
    
    Fixes: 2e8cff0a0eee ("arm64: fix rodata=full")
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Reviewed-by: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Link: https://lore.kernel.org/r/20231117131422.29663-1-will@kernel.org
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ata: pata_isapnp: Add missing error check for devm_ioport_map() [+ + +]
Author: Chen Ni <nichen@iscas.ac.cn>
Date:   Tue Oct 31 04:00:07 2023 +0000

    ata: pata_isapnp: Add missing error check for devm_ioport_map()
    
    [ Upstream commit a6925165ea82b7765269ddd8dcad57c731aa00de ]
    
    Add missing error return check for devm_ioport_map() and return the
    error if this function call fails.
    
    Fixes: 0d5ff566779f ("libata: convert to iomap")
    Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bcache: check return value from btree_node_alloc_replacement() [+ + +]
Author: Coly Li <colyli@suse.de>
Date:   Mon Nov 20 13:24:55 2023 +0800

    bcache: check return value from btree_node_alloc_replacement()
    
    commit 777967e7e9f6f5f3e153abffb562bffaf4430d26 upstream.
    
    In btree_gc_rewrite_node(), pointer 'n' is not checked after it returns
    from btree_gc_rewrite_node(). There is potential possibility that 'n' is
    a non NULL ERR_PTR(), referencing such error code is not permitted in
    following code. Therefore a return value checking is necessary after 'n'
    is back from btree_node_alloc_replacement().
    
    Signed-off-by: Coly Li <colyli@suse.de>
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Cc:  <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20231120052503.6122-3-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcache: fixup init dirty data errors [+ + +]
Author: Mingzhe Zou <mingzhe.zou@easystack.cn>
Date:   Mon Nov 20 13:24:58 2023 +0800

    bcache: fixup init dirty data errors
    
    commit 7cc47e64d3d69786a2711a4767e26b26ba63d7ed upstream.
    
    We found that after long run, the dirty_data of the bcache device
    will have errors. This error cannot be eliminated unless re-register.
    
    We also found that reattach after detach, this error can accumulate.
    
    In bch_sectors_dirty_init(), all inode <= d->id keys will be recounted
    again. This is wrong, we only need to count the keys of the current
    device.
    
    Fixes: b144e45fc576 ("bcache: make bch_sectors_dirty_init() to be multithreaded")
    Signed-off-by: Mingzhe Zou <mingzhe.zou@easystack.cn>
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Coly Li <colyli@suse.de>
    Link: https://lore.kernel.org/r/20231120052503.6122-6-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcache: fixup lock c->root error [+ + +]
Author: Mingzhe Zou <mingzhe.zou@easystack.cn>
Date:   Mon Nov 20 13:24:59 2023 +0800

    bcache: fixup lock c->root error
    
    commit e34820f984512b433ee1fc291417e60c47d56727 upstream.
    
    We had a problem with io hung because it was waiting for c->root to
    release the lock.
    
    crash> cache_set.root -l cache_set.list ffffa03fde4c0050
      root = 0xffff802ef454c800
    crash> btree -o 0xffff802ef454c800 | grep rw_semaphore
      [ffff802ef454c858] struct rw_semaphore lock;
    crash> struct rw_semaphore ffff802ef454c858
    struct rw_semaphore {
      count = {
        counter = -4294967297
      },
      wait_list = {
        next = 0xffff00006786fc28,
        prev = 0xffff00005d0efac8
      },
      wait_lock = {
        raw_lock = {
          {
            val = {
              counter = 0
            },
            {
              locked = 0 '\000',
              pending = 0 '\000'
            },
            {
              locked_pending = 0,
              tail = 0
            }
          }
        }
      },
      osq = {
        tail = {
          counter = 0
        }
      },
      owner = 0xffffa03fdc586603
    }
    
    The "counter = -4294967297" means that lock count is -1 and a write lock
    is being attempted. Then, we found that there is a btree with a counter
    of 1 in btree_cache_freeable.
    
    crash> cache_set -l cache_set.list ffffa03fde4c0050 -o|grep btree_cache
      [ffffa03fde4c1140] struct list_head btree_cache;
      [ffffa03fde4c1150] struct list_head btree_cache_freeable;
      [ffffa03fde4c1160] struct list_head btree_cache_freed;
      [ffffa03fde4c1170] unsigned int btree_cache_used;
      [ffffa03fde4c1178] wait_queue_head_t btree_cache_wait;
      [ffffa03fde4c1190] struct task_struct *btree_cache_alloc_lock;
    crash> list -H ffffa03fde4c1140|wc -l
    973
    crash> list -H ffffa03fde4c1150|wc -l
    1123
    crash> cache_set.btree_cache_used -l cache_set.list ffffa03fde4c0050
      btree_cache_used = 2097
    crash> list -s btree -l btree.list -H ffffa03fde4c1140|grep -E -A2 "^  lock = {" > btree_cache.txt
    crash> list -s btree -l btree.list -H ffffa03fde4c1150|grep -E -A2 "^  lock = {" > btree_cache_freeable.txt
    [root@node-3 127.0.0.1-2023-08-04-16:40:28]# pwd
    /var/crash/127.0.0.1-2023-08-04-16:40:28
    [root@node-3 127.0.0.1-2023-08-04-16:40:28]# cat btree_cache.txt|grep counter|grep -v "counter = 0"
    [root@node-3 127.0.0.1-2023-08-04-16:40:28]# cat btree_cache_freeable.txt|grep counter|grep -v "counter = 0"
          counter = 1
    
    We found that this is a bug in bch_sectors_dirty_init() when locking c->root:
        (1). Thread X has locked c->root(A) write.
        (2). Thread Y failed to lock c->root(A), waiting for the lock(c->root A).
        (3). Thread X bch_btree_set_root() changes c->root from A to B.
        (4). Thread X releases the lock(c->root A).
        (5). Thread Y successfully locks c->root(A).
        (6). Thread Y releases the lock(c->root B).
    
            down_write locked ---(1)----------------------┐
                    |                                     |
                    |   down_read waiting ---(2)----┐     |
                    |           |               ┌-------------┐ ┌-------------┐
            bch_btree_set_root ===(3)========>> | c->root   A | | c->root   B |
                    |           |               └-------------┘ └-------------┘
                up_write ---(4)---------------------┘     |            |
                                |                         |            |
                        down_read locked ---(5)-----------┘            |
                                |                                      |
                            up_read ---(6)-----------------------------┘
    
    Since c->root may change, the correct steps to lock c->root should be
    the same as bch_root_usage(), compare after locking.
    
    static unsigned int bch_root_usage(struct cache_set *c)
    {
            unsigned int bytes = 0;
            struct bkey *k;
            struct btree *b;
            struct btree_iter iter;
    
            goto lock_root;
    
            do {
                    rw_unlock(false, b);
    lock_root:
                    b = c->root;
                    rw_lock(false, b, b->level);
            } while (b != c->root);
    
            for_each_key_filter(&b->keys, k, &iter, bch_ptr_bad)
                    bytes += bkey_bytes(k);
    
            rw_unlock(false, b);
    
            return (bytes * 100) / btree_bytes(c);
    }
    
    Fixes: b144e45fc576 ("bcache: make bch_sectors_dirty_init() to be multithreaded")
    Signed-off-by: Mingzhe Zou <mingzhe.zou@easystack.cn>
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Coly Li <colyli@suse.de>
    Link: https://lore.kernel.org/r/20231120052503.6122-7-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcache: fixup multi-threaded bch_sectors_dirty_init() wake-up race [+ + +]
Author: Mingzhe Zou <mingzhe.zou@easystack.cn>
Date:   Mon Nov 20 13:25:00 2023 +0800

    bcache: fixup multi-threaded bch_sectors_dirty_init() wake-up race
    
    commit 2faac25d7958c4761bb8cec54adb79f806783ad6 upstream.
    
    We get a kernel crash about "unable to handle kernel paging request":
    
    ```dmesg
    [368033.032005] BUG: unable to handle kernel paging request at ffffffffad9ae4b5
    [368033.032007] PGD fc3a0d067 P4D fc3a0d067 PUD fc3a0e063 PMD 8000000fc38000e1
    [368033.032012] Oops: 0003 [#1] SMP PTI
    [368033.032015] CPU: 23 PID: 55090 Comm: bch_dirtcnt[0] Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-147.5.1.es8_24.x86_64 #1
    [368033.032017] Hardware name: Tsinghua Tongfang THTF Chaoqiang Server/072T6D, BIOS 2.4.3 01/17/2017
    [368033.032027] RIP: 0010:native_queued_spin_lock_slowpath+0x183/0x1d0
    [368033.032029] Code: 8b 02 48 85 c0 74 f6 48 89 c1 eb d0 c1 e9 12 83 e0
    03 83 e9 01 48 c1 e0 05 48 63 c9 48 05 c0 3d 02 00 48 03 04 cd 60 68 93
    ad <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 02
    [368033.032031] RSP: 0018:ffffbb48852abe00 EFLAGS: 00010082
    [368033.032032] RAX: ffffffffad9ae4b5 RBX: 0000000000000246 RCX: 0000000000003bf3
    [368033.032033] RDX: ffff97b0ff8e3dc0 RSI: 0000000000600000 RDI: ffffbb4884743c68
    [368033.032034] RBP: 0000000000000001 R08: 0000000000000000 R09: 000007ffffffffff
    [368033.032035] R10: ffffbb486bb01000 R11: 0000000000000001 R12: ffffffffc068da70
    [368033.032036] R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
    [368033.032038] FS:  0000000000000000(0000) GS:ffff97b0ff8c0000(0000) knlGS:0000000000000000
    [368033.032039] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [368033.032040] CR2: ffffffffad9ae4b5 CR3: 0000000fc3a0a002 CR4: 00000000003626e0
    [368033.032042] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [368033.032043] bcache: bch_cached_dev_attach() Caching rbd479 as bcache462 on set 8cff3c36-4a76-4242-afaa-7630206bc70b
    [368033.032045] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [368033.032046] Call Trace:
    [368033.032054]  _raw_spin_lock_irqsave+0x32/0x40
    [368033.032061]  __wake_up_common_lock+0x63/0xc0
    [368033.032073]  ? bch_ptr_invalid+0x10/0x10 [bcache]
    [368033.033502]  bch_dirty_init_thread+0x14c/0x160 [bcache]
    [368033.033511]  ? read_dirty_submit+0x60/0x60 [bcache]
    [368033.033516]  kthread+0x112/0x130
    [368033.033520]  ? kthread_flush_work_fn+0x10/0x10
    [368033.034505]  ret_from_fork+0x35/0x40
    ```
    
    The crash occurred when call wake_up(&state->wait), and then we want
    to look at the value in the state. However, bch_sectors_dirty_init()
    is not found in the stack of any task. Since state is allocated on
    the stack, we guess that bch_sectors_dirty_init() has exited, causing
    bch_dirty_init_thread() to be unable to handle kernel paging request.
    
    In order to verify this idea, we added some printing information during
    wake_up(&state->wait). We find that "wake up" is printed twice, however
    we only expect the last thread to wake up once.
    
    ```dmesg
    [  994.641004] alcache: bch_dirty_init_thread() wake up
    [  994.641018] alcache: bch_dirty_init_thread() wake up
    [  994.641523] alcache: bch_sectors_dirty_init() init exit
    ```
    
    There is a race. If bch_sectors_dirty_init() exits after the first wake
    up, the second wake up will trigger this bug("unable to handle kernel
    paging request").
    
    Proceed as follows:
    
    bch_sectors_dirty_init
        kthread_run ==============> bch_dirty_init_thread(bch_dirtcnt[0])
                ...                         ...
        atomic_inc(&state.started)          ...
                ...                         ...
        atomic_read(&state.enough)          ...
                ...                 atomic_set(&state->enough, 1)
        kthread_run ======================================================> bch_dirty_init_thread(bch_dirtcnt[1])
                ...                 atomic_dec_and_test(&state->started)            ...
        atomic_inc(&state.started)          ...                                     ...
                ...                 wake_up(&state->wait)                           ...
        atomic_read(&state.enough)                                          atomic_dec_and_test(&state->started)
                ...                                                                 ...
        wait_event(state.wait, atomic_read(&state.started) == 0)                    ...
        return                                                                      ...
                                                                            wake_up(&state->wait)
    
    We believe it is very common to wake up twice if there is no dirty, but
    crash is an extremely low probability event. It's hard for us to reproduce
    this issue. We attached and detached continuously for a week, with a total
    of more than one million attaches and only one crash.
    
    Putting atomic_inc(&state.started) before kthread_run() can avoid waking
    up twice.
    
    Fixes: b144e45fc576 ("bcache: make bch_sectors_dirty_init() to be multithreaded")
    Signed-off-by: Mingzhe Zou <mingzhe.zou@easystack.cn>
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Coly Li <colyli@suse.de>
    Link: https://lore.kernel.org/r/20231120052503.6122-8-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcache: prevent potential division by zero error [+ + +]
Author: Rand Deeb <rand.sec96@gmail.com>
Date:   Mon Nov 20 13:24:57 2023 +0800

    bcache: prevent potential division by zero error
    
    commit 2c7f497ac274a14330208b18f6f734000868ebf9 upstream.
    
    In SHOW(), the variable 'n' is of type 'size_t.' While there is a
    conditional check to verify that 'n' is not equal to zero before
    executing the 'do_div' macro, concerns arise regarding potential
    division by zero error in 64-bit environments.
    
    The concern arises when 'n' is 64 bits in size, greater than zero, and
    the lower 32 bits of it are zeros. In such cases, the conditional check
    passes because 'n' is non-zero, but the 'do_div' macro casts 'n' to
    'uint32_t,' effectively truncating it to its lower 32 bits.
    Consequently, the 'n' value becomes zero.
    
    To fix this potential division by zero error and ensure precise
    division handling, this commit replaces the 'do_div' macro with
    div64_u64(). div64_u64() is designed to work with 64-bit operands,
    guaranteeing that division is performed correctly.
    
    This change enhances the robustness of the code, ensuring that division
    operations yield accurate results in all scenarios, eliminating the
    possibility of division by zero, and improving compatibility across
    different 64-bit environments.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Rand Deeb <rand.sec96@gmail.com>
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Coly Li <colyli@suse.de>
    Link: https://lore.kernel.org/r/20231120052503.6122-5-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcache: replace a mistaken IS_ERR() by IS_ERR_OR_NULL() in btree_gc_coalesce() [+ + +]
Author: Coly Li <colyli@suse.de>
Date:   Mon Nov 20 13:25:01 2023 +0800

    bcache: replace a mistaken IS_ERR() by IS_ERR_OR_NULL() in btree_gc_coalesce()
    
    commit f72f4312d4388376fc8a1f6cf37cb21a0d41758b upstream.
    
    Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in
    node allocations") do the following change inside btree_gc_coalesce(),
    
    31 @@ -1340,7 +1340,7 @@ static int btree_gc_coalesce(
    32         memset(new_nodes, 0, sizeof(new_nodes));
    33         closure_init_stack(&cl);
    34
    35 -       while (nodes < GC_MERGE_NODES && !IS_ERR_OR_NULL(r[nodes].b))
    36 +       while (nodes < GC_MERGE_NODES && !IS_ERR(r[nodes].b))
    37                 keys += r[nodes++].keys;
    38
    39         blocks = btree_default_blocks(b->c) * 2 / 3;
    
    At line 35 the original r[nodes].b is not always allocatored from
    __bch_btree_node_alloc(), and possibly initialized as NULL pointer by
    caller of btree_gc_coalesce(). Therefore the change at line 36 is not
    correct.
    
    This patch replaces the mistaken IS_ERR() by IS_ERR_OR_NULL() to avoid
    potential issue.
    
    Fixes: 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations")
    Cc:  <stable@vger.kernel.org> # 6.5+
    Cc: Zheng Wang <zyytlz.wz@163.com>
    Signed-off-by: Coly Li <colyli@suse.de>
    Link: https://lore.kernel.org/r/20231120052503.6122-9-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cifs: account for primary channel in the interface list [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Tue Mar 14 11:14:58 2023 +0000

    cifs: account for primary channel in the interface list
    
    [ Upstream commit fa1d0508bdd4a68c5e40f85f635712af8c12f180 ]
    
    The refcounting of server interfaces should account
    for the primary channel too. Although this is not
    strictly necessary, doing so will account for the primary
    channel in DebugData.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: distribute channels across interfaces based on speed [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Mon Dec 26 11:24:56 2022 +0000

    cifs: distribute channels across interfaces based on speed
    
    [ Upstream commit a6d8fb54a515f0546ffdb7870102b1238917e567 ]
    
    Today, if the server interfaces RSS capable, we simply
    choose the fastest interface to setup a channel. This is not
    a scalable approach, and does not make a lot of attempt to
    distribute the connections.
    
    This change does a weighted distribution of channels across
    all the available server interfaces, where the weight is
    a function of the advertised interface speed.
    
    Also make sure that we don't mix rdma and non-rdma for channels.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Stable-dep-of: fa1d0508bdd4 ("cifs: account for primary channel in the interface list")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: fix leak of iface for primary channel [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Tue Nov 14 04:54:12 2023 +0000

    cifs: fix leak of iface for primary channel
    
    [ Upstream commit 29954d5b1e0d67a4cd61c30c2201030c97e94b1e ]
    
    My last change in this area introduced a change which
    accounted for primary channel in the interface ref count.
    However, it did not reduce this ref count on deallocation
    of the primary channel. i.e. during umount.
    
    Fixing this leak here, by dropping this ref count for
    primary channel while freeing up the session.
    
    Fixes: fa1d0508bdd4 ("cifs: account for primary channel in the interface list")
    Cc: stable@vger.kernel.org
    Reported-by: Paulo Alcantara <pc@manguebit.com>
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: minor cleanup of some headers [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Thu Dec 8 16:11:00 2022 -0600

    cifs: minor cleanup of some headers
    
    [ Upstream commit c19204cbd65c12fdcd34fb8f5d645007238ed5cd ]
    
    checkpatch showed formatting problems with extra spaces,
    and extra semicolon and some missing blank lines in some
    cifs headers.
    
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Reviewed-by: Germano Percossi <germano.percossi@gmail.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Stable-dep-of: de4eceab578e ("smb3: allow dumping session and tcon id to improve stats analysis and debugging")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: print last update time for interface list [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Fri Dec 23 10:41:25 2022 +0000

    cifs: print last update time for interface list
    
    [ Upstream commit 05844bd661d9fd478df1175b6639bf2d9398becb ]
    
    We store the last updated time for interface list while
    parsing the interfaces. This change is to just print that
    info in DebugData.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Stable-dep-of: fa1d0508bdd4 ("cifs: account for primary channel in the interface list")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm-delay: fix a race between delay_presuspend and delay_bio [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Nov 29 13:38:43 2023 -0500

    dm-delay: fix a race between delay_presuspend and delay_bio
    
    [ Upstream commit 6fc45b6ed921dc00dfb264dc08c7d67ee63d2656 ]
    
    In delay_presuspend, we set the atomic variable may_delay and then stop
    the timer and flush pending bios. The intention here is to prevent the
    delay target from re-arming the timer again.
    
    However, this test is racy. Suppose that one thread goes to delay_bio,
    sees that dc->may_delay is one and proceeds; now, another thread executes
    delay_presuspend, it sets dc->may_delay to zero, deletes the timer and
    flushes pending bios. Then, the first thread continues and adds the bio to
    delayed->list despite the fact that dc->may_delay is false.
    
    Fix this bug by changing may_delay's type from atomic_t to bool and
    only access it while holding the delayed_bios_lock mutex. Note that we
    don't have to grab the mutex in delay_resume because there are no bios
    in flight at this point.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915: do not clean GT table on error path [+ + +]
Author: Andrzej Hajda <andrzej.hajda@intel.com>
Date:   Wed Nov 15 11:54:03 2023 +0100

    drm/i915: do not clean GT table on error path
    
    [ Upstream commit 0561794b6b642b84b879bf97061c4b4fa692839e ]
    
    The only task of intel_gt_release_all is to zero gt table. Calling
    it on error path prevents intel_gt_driver_late_release_all (called from
    i915_driver_late_release) to cleanup GTs, causing leakage.
    After i915_driver_late_release GT array is not used anymore so
    it does not need cleaning at all.
    
    Sample leak report:
    
    BUG i915_request (...): Objects remaining in i915_request on __kmem_cache_shutdown()
    ...
    Object 0xffff888113420040 @offset=64
    Allocated in __i915_request_create+0x75/0x610 [i915] age=18339 cpu=1 pid=1454
     kmem_cache_alloc+0x25b/0x270
     __i915_request_create+0x75/0x610 [i915]
     i915_request_create+0x109/0x290 [i915]
     __engines_record_defaults+0xca/0x440 [i915]
     intel_gt_init+0x275/0x430 [i915]
     i915_gem_init+0x135/0x2c0 [i915]
     i915_driver_probe+0x8d1/0xdc0 [i915]
    
    v2: removed whole intel_gt_release_all
    
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8489
    Fixes: bec68cc9ea42 ("drm/i915: Prepare for multiple GTs")
    Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231115-dont_clean_gt_on_error_path-v2-1-54250125470a@intel.com
    (cherry picked from commit e899505533852bf1da133f2f4c9a9655ff77f7e5)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/panel: auo,b101uan08.3: Fine tune the panel power sequence [+ + +]
Author: Xuxin Xiong <xuxinxiong@huaqin.corp-partner.google.com>
Date:   Tue Nov 14 12:42:05 2023 +0800

    drm/panel: auo,b101uan08.3: Fine tune the panel power sequence
    
    [ Upstream commit 6965809e526917b73c8f9178173184dcf13cec4b ]
    
    For "auo,b101uan08.3" this panel, it is stipulated in the panel spec that
    MIPI needs to keep the LP11 state before the lcm_reset pin is pulled high.
    
    Fixes: 56ad624b4cb5 ("drm/panel: support for auo, b101uan08.3 wuxga dsi video mode panel")
    Signed-off-by: Xuxin Xiong <xuxinxiong@huaqin.corp-partner.google.com>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231114044205.613421-1-xuxinxiong@huaqin.corp-partner.google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/panel: boe-tv101wum-nl6: Fine tune the panel power sequence [+ + +]
Author: Shuijing Li <shuijing.li@mediatek.com>
Date:   Mon May 15 17:49:55 2023 +0800

    drm/panel: boe-tv101wum-nl6: Fine tune the panel power sequence
    
    [ Upstream commit 812562b8d881ce6d33fed8052b3a10b718430fb5 ]
    
    For "boe,tv105wum-nw0" this special panel, it is stipulated in
    the panel spec that MIPI needs to keep the LP11 state before
    the lcm_reset pin is pulled high.
    
    Signed-off-by: Shuijing Li <shuijing.li@mediatek.com>
    Signed-off-by: Xinlei Lee <xinlei.lee@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230515094955.15982-3-shuijing.li@mediatek.com
    Stable-dep-of: 6965809e5269 ("drm/panel: auo,b101uan08.3: Fine tune the panel power sequence")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/panel: simple: Fix Innolux G101ICE-L01 bus flags [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Mon Oct 9 00:33:15 2023 +0200

    drm/panel: simple: Fix Innolux G101ICE-L01 bus flags
    
    [ Upstream commit 06fc41b09cfbc02977acd9189473593a37d82d9b ]
    
    Add missing .bus_flags = DRM_BUS_FLAG_DE_HIGH to this panel description,
    ones which match both the datasheet and the panel display_timing flags .
    
    Fixes: 1e29b840af9f ("drm/panel: simple: Add Innolux G101ICE-L01 panel")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231008223315.279215-1-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/panel: simple: Fix Innolux G101ICE-L01 timings [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Mon Oct 9 00:32:56 2023 +0200

    drm/panel: simple: Fix Innolux G101ICE-L01 timings
    
    [ Upstream commit 3f9a91b6c00e655d27bd785dcda1742dbdc31bda ]
    
    The Innolux G101ICE-L01 datasheet [1] page 17 table
    6.1 INPUT SIGNAL TIMING SPECIFICATIONS
    indicates that maximum vertical blanking time is 40 lines.
    Currently the driver uses 29 lines.
    
    Fix it, and since this panel is a DE panel, adjust the timings
    to make them less hostile to controllers which cannot do 1 px
    HSA/VSA, distribute the delays evenly between all three parts.
    
    [1] https://www.data-modul.com/sites/default/files/products/G101ICE-L01-C2-specification-12042389.pdf
    
    Fixes: 1e29b840af9f ("drm/panel: simple: Add Innolux G101ICE-L01 panel")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231008223256.279196-1-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/rockchip: vop: Fix color for RGB888/BGR888 format on VOP full [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Thu Oct 26 19:14:58 2023 +0000

    drm/rockchip: vop: Fix color for RGB888/BGR888 format on VOP full
    
    [ Upstream commit bb0a05acd6121ff0e810b44fdc24dbdfaa46b642 ]
    
    Use of DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888 on e.g. RK3288, RK3328
    and RK3399 result in wrong colors being displayed.
    
    The issue can be observed using modetest:
    
      modetest -s <connector_id>@<crtc_id>:1920x1080-60@RG24
      modetest -s <connector_id>@<crtc_id>:1920x1080-60@BG24
    
    Vendor 4.4 kernel apply an inverted rb swap for these formats on VOP
    full framework (IP version 3.x) compared to VOP little framework (2.x).
    
    Fix colors by applying different rb swap for VOP full framework (3.x)
    and VOP little framework (2.x) similar to vendor 4.4 kernel.
    
    Fixes: 85a359f25388 ("drm/rockchip: Add BGR formats to VOP")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Tested-by: Diederik de Haas <didi.debian@cknow.org>
    Reviewed-by: Christopher Obbard <chris.obbard@collabora.com>
    Tested-by: Christopher Obbard <chris.obbard@collabora.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231026191500.2994225-1-jonas@kwiboo.se
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: add a new helper to check if es must be kept [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Mon Apr 24 11:38:36 2023 +0800

    ext4: add a new helper to check if es must be kept
    
    [ Upstream commit 9649eb18c6288f514cacffdd699d5cd999c2f8f6 ]
    
    In the extent status tree, we have extents which we can just drop without
    issues and extents we must not drop - this depends on the extent's status
    - currently ext4_es_is_delayed() extents must stay, others may be dropped.
    
    A helper function is added to help determine if the current extent can
    be dropped, although only ext4_es_is_delayed() extents cannot be dropped
    currently.
    
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230424033846.4732-3-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 8e387c89e96b ("ext4: make sure allocate pending entry not fail")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: factor out __es_alloc_extent() and __es_free_extent() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Mon Apr 24 11:38:37 2023 +0800

    ext4: factor out __es_alloc_extent() and __es_free_extent()
    
    [ Upstream commit 73a2f033656be11298912201ad50615307b4477a ]
    
    Factor out __es_alloc_extent() and __es_free_extent(), which only allocate
    and free extent_status in these two helpers.
    
    The ext4_es_alloc_extent() function is split into __es_alloc_extent()
    and ext4_es_init_extent(). In __es_alloc_extent() we allocate memory using
    GFP_KERNEL | __GFP_NOFAIL | __GFP_ZERO if the memory allocation cannot
    fail, otherwise we use GFP_ATOMIC. and the ext4_es_init_extent() is used to
    initialize extent_status and update related variables after a successful
    allocation.
    
    This is to prepare for the use of pre-allocated extent_status later.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230424033846.4732-4-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 8e387c89e96b ("ext4: make sure allocate pending entry not fail")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix slab-use-after-free in ext4_es_insert_extent() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Tue Aug 15 15:08:08 2023 +0800

    ext4: fix slab-use-after-free in ext4_es_insert_extent()
    
    [ Upstream commit 768d612f79822d30a1e7d132a4d4b05337ce42ec ]
    
    Yikebaer reported an issue:
    ==================================================================
    BUG: KASAN: slab-use-after-free in ext4_es_insert_extent+0xc68/0xcb0
    fs/ext4/extents_status.c:894
    Read of size 4 at addr ffff888112ecc1a4 by task syz-executor/8438
    
    CPU: 1 PID: 8438 Comm: syz-executor Not tainted 6.5.0-rc5 #1
    Call Trace:
     [...]
     kasan_report+0xba/0xf0 mm/kasan/report.c:588
     ext4_es_insert_extent+0xc68/0xcb0 fs/ext4/extents_status.c:894
     ext4_map_blocks+0x92a/0x16f0 fs/ext4/inode.c:680
     ext4_alloc_file_blocks.isra.0+0x2df/0xb70 fs/ext4/extents.c:4462
     ext4_zero_range fs/ext4/extents.c:4622 [inline]
     ext4_fallocate+0x251c/0x3ce0 fs/ext4/extents.c:4721
     [...]
    
    Allocated by task 8438:
     [...]
     kmem_cache_zalloc include/linux/slab.h:693 [inline]
     __es_alloc_extent fs/ext4/extents_status.c:469 [inline]
     ext4_es_insert_extent+0x672/0xcb0 fs/ext4/extents_status.c:873
     ext4_map_blocks+0x92a/0x16f0 fs/ext4/inode.c:680
     ext4_alloc_file_blocks.isra.0+0x2df/0xb70 fs/ext4/extents.c:4462
     ext4_zero_range fs/ext4/extents.c:4622 [inline]
     ext4_fallocate+0x251c/0x3ce0 fs/ext4/extents.c:4721
     [...]
    
    Freed by task 8438:
     [...]
     kmem_cache_free+0xec/0x490 mm/slub.c:3823
     ext4_es_try_to_merge_right fs/ext4/extents_status.c:593 [inline]
     __es_insert_extent+0x9f4/0x1440 fs/ext4/extents_status.c:802
     ext4_es_insert_extent+0x2ca/0xcb0 fs/ext4/extents_status.c:882
     ext4_map_blocks+0x92a/0x16f0 fs/ext4/inode.c:680
     ext4_alloc_file_blocks.isra.0+0x2df/0xb70 fs/ext4/extents.c:4462
     ext4_zero_range fs/ext4/extents.c:4622 [inline]
     ext4_fallocate+0x251c/0x3ce0 fs/ext4/extents.c:4721
     [...]
    ==================================================================
    
    The flow of issue triggering is as follows:
    1. remove es
          raw es               es  removed  es1
    |-------------------| -> |----|.......|------|
    
    2. insert es
      es   insert   es1      merge with es  es1     merge with es and free es1
    |----|.......|------| -> |------------|------| -> |-------------------|
    
    es merges with newes, then merges with es1, frees es1, then determines
    if es1->es_len is 0 and triggers a UAF.
    
    The code flow is as follows:
    ext4_es_insert_extent
      es1 = __es_alloc_extent(true);
      es2 = __es_alloc_extent(true);
      __es_remove_extent(inode, lblk, end, NULL, es1)
        __es_insert_extent(inode, &newes, es1) ---> insert es1 to es tree
      __es_insert_extent(inode, &newes, es2)
        ext4_es_try_to_merge_right
          ext4_es_free_extent(inode, es1) --->  es1 is freed
      if (es1 && !es1->es_len)
        // Trigger UAF by determining if es1 is used.
    
    We determine whether es1 or es2 is used immediately after calling
    __es_remove_extent() or __es_insert_extent() to avoid triggering a
    UAF if es1 or es2 is freed.
    
    Reported-by: Yikebaer Aizezi <yikebaer61@gmail.com>
    Closes: https://lore.kernel.org/lkml/CALcu4raD4h9coiyEBL4Bm0zjDwxC2CyPiTwsP3zFuhot6y9Beg@mail.gmail.com
    Fixes: 2a69c450083d ("ext4: using nofail preallocation in ext4_es_insert_extent()")
    Cc: stable@kernel.org
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230815070808.3377171-1-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 8e387c89e96b ("ext4: make sure allocate pending entry not fail")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: make sure allocate pending entry not fail [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Thu Aug 24 17:26:05 2023 +0800

    ext4: make sure allocate pending entry not fail
    
    [ Upstream commit 8e387c89e96b9543a339f84043cf9df15fed2632 ]
    
    __insert_pending() allocate memory in atomic context, so the allocation
    could fail, but we are not handling that failure now. It could lead
    ext4_es_remove_extent() to get wrong reserved clusters, and the global
    data blocks reservation count will be incorrect. The same to
    extents_status entry preallocation, preallocate pending entry out of the
    i_es_lock with __GFP_NOFAIL, make sure __insert_pending() and
    __revise_pending() always succeeds.
    
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20230824092619.1327976-3-yi.zhang@huaweicloud.com
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: use pre-allocated es in __es_insert_extent() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Mon Apr 24 11:38:38 2023 +0800

    ext4: use pre-allocated es in __es_insert_extent()
    
    [ Upstream commit 95f0b320339a977cf69872eac107122bf536775d ]
    
    Pass a extent_status pointer prealloc to __es_insert_extent(). If the
    pointer is non-null, it is used directly when a new extent_status is
    needed to avoid memory allocation failures.
    
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230424033846.4732-5-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 8e387c89e96b ("ext4: make sure allocate pending entry not fail")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: use pre-allocated es in __es_remove_extent() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Mon Apr 24 11:38:39 2023 +0800

    ext4: use pre-allocated es in __es_remove_extent()
    
    [ Upstream commit bda3efaf774fb687c2b7a555aaec3006b14a8857 ]
    
    When splitting extent, if the second extent can not be dropped, we return
    -ENOMEM and use GFP_NOFAIL to preallocate an extent_status outside of
    i_es_lock and pass it to __es_remove_extent() to be used as the second
    extent. This ensures that __es_remove_extent() is executed successfully,
    thus ensuring consistency in the extent status tree. If the second extent
    is not undroppable, we simply drop it and return 0. Then retry is no longer
    necessary, remove it.
    
    Now, __es_remove_extent() will always remove what it should, maybe more.
    
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230424033846.4732-6-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 8e387c89e96b ("ext4: make sure allocate pending entry not fail")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: using nofail preallocation in ext4_es_insert_delayed_block() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Mon Apr 24 11:38:41 2023 +0800

    ext4: using nofail preallocation in ext4_es_insert_delayed_block()
    
    [ Upstream commit 4a2d98447b37bcb68a7f06a1078edcb4f7e6ce7e ]
    
    Similar to in ext4_es_remove_extent(), we use a no-fail preallocation
    to avoid inconsistencies, except that here we may have to preallocate
    two extent_status.
    
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230424033846.4732-8-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 8e387c89e96b ("ext4: make sure allocate pending entry not fail")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: using nofail preallocation in ext4_es_insert_extent() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Mon Apr 24 11:38:42 2023 +0800

    ext4: using nofail preallocation in ext4_es_insert_extent()
    
    [ Upstream commit 2a69c450083db164596c75c0f5b4d9c4c0e18eba ]
    
    Similar to in ext4_es_insert_delayed_block(), we use preallocations that
    do not fail to avoid inconsistencies, but we do not care about es that are
    not must be kept, and we return 0 even if such es memory allocation fails.
    
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230424033846.4732-9-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 8e387c89e96b ("ext4: make sure allocate pending entry not fail")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: using nofail preallocation in ext4_es_remove_extent() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Mon Apr 24 11:38:40 2023 +0800

    ext4: using nofail preallocation in ext4_es_remove_extent()
    
    [ Upstream commit e9fe2b882bd5b26b987c9ba110c2222796f72af5 ]
    
    If __es_remove_extent() returns an error it means that when splitting
    extent, allocating an extent that must be kept failed, where returning
    an error directly would cause the extent tree to be inconsistent. So we
    use GFP_NOFAIL to pre-allocate an extent_status and pass it to
    __es_remove_extent() to avoid this problem.
    
    In addition, since the allocated memory is outside the i_es_lock, the
    extent_status tree may change and the pre-allocated extent_status is
    no longer needed, so we release the pre-allocated extent_status when
    es->es_len is not initialized.
    
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230424033846.4732-7-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 8e387c89e96b ("ext4: make sure allocate pending entry not fail")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: fix HID device resource race between HID core and debugging support [+ + +]
Author: Charles Yi <be286@163.com>
Date:   Tue Oct 31 12:32:39 2023 +0800

    HID: fix HID device resource race between HID core and debugging support
    
    [ Upstream commit fc43e9c857b7aa55efba9398419b14d9e35dcc7d ]
    
    hid_debug_events_release releases resources bound to the HID device instance.
    hid_device_release releases the underlying HID device instance potentially
    before hid_debug_events_release has completed releasing debug resources bound
    to the same HID device instance.
    
    Reference count to prevent the HID device instance from being torn down
    preemptively when HID debugging support is used. When count reaches zero,
    release core resources of HID device instance using hiddev_free.
    
    The crash:
    
    [  120.728477][ T4396] kernel BUG at lib/list_debug.c:53!
    [  120.728505][ T4396] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [  120.739806][ T4396] Modules linked in: bcmdhd dhd_static_buf 8822cu pcie_mhi r8168
    [  120.747386][ T4396] CPU: 1 PID: 4396 Comm: hidt_bridge Not tainted 5.10.110 #257
    [  120.754771][ T4396] Hardware name: Rockchip RK3588 EVB4 LP4 V10 Board (DT)
    [  120.761643][ T4396] pstate: 60400089 (nZCv daIf +PAN -UAO -TCO BTYPE=--)
    [  120.768338][ T4396] pc : __list_del_entry_valid+0x98/0xac
    [  120.773730][ T4396] lr : __list_del_entry_valid+0x98/0xac
    [  120.779120][ T4396] sp : ffffffc01e62bb60
    [  120.783126][ T4396] x29: ffffffc01e62bb60 x28: ffffff818ce3a200
    [  120.789126][ T4396] x27: 0000000000000009 x26: 0000000000980000
    [  120.795126][ T4396] x25: ffffffc012431000 x24: ffffff802c6d4e00
    [  120.801125][ T4396] x23: ffffff8005c66f00 x22: ffffffc01183b5b8
    [  120.807125][ T4396] x21: ffffff819df2f100 x20: 0000000000000000
    [  120.813124][ T4396] x19: ffffff802c3f0700 x18: ffffffc01d2cd058
    [  120.819124][ T4396] x17: 0000000000000000 x16: 0000000000000000
    [  120.825124][ T4396] x15: 0000000000000004 x14: 0000000000003fff
    [  120.831123][ T4396] x13: ffffffc012085588 x12: 0000000000000003
    [  120.837123][ T4396] x11: 00000000ffffbfff x10: 0000000000000003
    [  120.843123][ T4396] x9 : 455103d46b329300 x8 : 455103d46b329300
    [  120.849124][ T4396] x7 : 74707572726f6320 x6 : ffffffc0124b8cb5
    [  120.855124][ T4396] x5 : ffffffffffffffff x4 : 0000000000000000
    [  120.861123][ T4396] x3 : ffffffc011cf4f90 x2 : ffffff81fee7b948
    [  120.867122][ T4396] x1 : ffffffc011cf4f90 x0 : 0000000000000054
    [  120.873122][ T4396] Call trace:
    [  120.876259][ T4396]  __list_del_entry_valid+0x98/0xac
    [  120.881304][ T4396]  hid_debug_events_release+0x48/0x12c
    [  120.886617][ T4396]  full_proxy_release+0x50/0xbc
    [  120.891323][ T4396]  __fput+0xdc/0x238
    [  120.895075][ T4396]  ____fput+0x14/0x24
    [  120.898911][ T4396]  task_work_run+0x90/0x148
    [  120.903268][ T4396]  do_exit+0x1bc/0x8a4
    [  120.907193][ T4396]  do_group_exit+0x8c/0xa4
    [  120.911458][ T4396]  get_signal+0x468/0x744
    [  120.915643][ T4396]  do_signal+0x84/0x280
    [  120.919650][ T4396]  do_notify_resume+0xd0/0x218
    [  120.924262][ T4396]  work_pending+0xc/0x3f0
    
    [ Rahul Rameshbabu <sergeantsagara@protonmail.com>: rework changelog ]
    Fixes: cd667ce24796 ("HID: use debugfs for events/reports dumping")
    Signed-off-by: Charles Yi <be286@163.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hv_netvsc: fix race of netvsc and VF register_netdevice [+ + +]
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date:   Sun Nov 19 08:23:41 2023 -0800

    hv_netvsc: fix race of netvsc and VF register_netdevice
    
    commit d30fb712e52964f2cf9a9c14cf67078394044837 upstream.
    
    The rtnl lock also needs to be held before rndis_filter_device_add()
    which advertises nvsp_2_vsc_capability / sriov bit, and triggers
    VF NIC offering and registering. If VF NIC finished register_netdev()
    earlier it may cause name based config failure.
    
    To fix this issue, move the call to rtnl_lock() before
    rndis_filter_device_add(), so VF will be registered later than netvsc
    / synthetic NIC, and gets a name numbered (ethX) after netvsc.
    
    Cc: stable@vger.kernel.org
    Fixes: e04e7a7bbd4b ("hv_netvsc: Fix a deadlock by getting rtnl lock earlier in netvsc_probe()")
    Reported-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

hv_netvsc: Fix race of register_netdevice_notifier and VF register [+ + +]
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date:   Sun Nov 19 08:23:42 2023 -0800

    hv_netvsc: Fix race of register_netdevice_notifier and VF register
    
    commit 85520856466ed6bc3b1ccb013cddac70ceb437db upstream.
    
    If VF NIC is registered earlier, NETDEV_REGISTER event is replayed,
    but NETDEV_POST_INIT is not.
    
    Move register_netdevice_notifier() earlier, so the call back
    function is set before probing.
    
    Cc: stable@vger.kernel.org
    Fixes: e04e7a7bbd4b ("hv_netvsc: Fix a deadlock by getting rtnl lock earlier in netvsc_probe()")
    Reported-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Reviewed-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

hv_netvsc: Mark VF as slave before exposing it to user-mode [+ + +]
Author: Long Li <longli@microsoft.com>
Date:   Sun Nov 19 08:23:43 2023 -0800

    hv_netvsc: Mark VF as slave before exposing it to user-mode
    
    commit c807d6cd089d2f4951baa838081ec5ae3e2360f8 upstream.
    
    When a VF is being exposed form the kernel, it should be marked as "slave"
    before exposing to the user-mode. The VF is not usable without netvsc
    running as master. The user-mode should never see a VF without the "slave"
    flag.
    
    This commit moves the code of setting the slave flag to the time before
    VF is exposed to user-mode.
    
    Cc: stable@vger.kernel.org
    Fixes: 0c195567a8f6 ("netvsc: transparent VF management")
    Signed-off-by: Long Li <longli@microsoft.com>
    Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
    Acked-by: Stephen Hemminger <stephen@networkplumber.org>
    Acked-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
i40e: Fix adding unsupported cloud filters [+ + +]
Author: Ivan Vecera <ivecera@redhat.com>
Date:   Tue Nov 21 13:13:36 2023 -0800

    i40e: Fix adding unsupported cloud filters
    
    [ Upstream commit 4e20655e503e3a478cd1682bf25e3202dd823da8 ]
    
    If a VF tries to add unsupported cloud filter through virtchnl
    then i40e_add_del_cloud_filter(_big_buf) returns -ENOTSUPP but
    this error code is stored in 'ret' instead of 'aq_ret' that
    is used as error code sent back to VF. In this scenario where
    one of the mentioned functions fails the value of 'aq_ret'
    is zero so the VF will incorrectly receive a 'success'.
    
    Use 'aq_ret' to store return value and remove 'ret' local
    variable. Additionally fix the issue when filter allocation
    fails, in this case no notification is sent back to the VF.
    
    Fixes: e284fc280473 ("i40e: Add and delete cloud filter")
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Link: https://lore.kernel.org/r/20231121211338.3348677-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i40e: use ERR_PTR error print in i40e messages [+ + +]
Author: Jan Sokolowski <jan.sokolowski@intel.com>
Date:   Mon Jan 9 15:11:20 2023 +0100

    i40e: use ERR_PTR error print in i40e messages
    
    [ Upstream commit d5ba18423f87709146c120b20e4a1b8a5b528a76 ]
    
    In i40e_status removal patches, i40e_status conversion
    to strings was removed in order to easily refactor
    the code to use standard errornums. This however made it
    more difficult for read error logs.
    
    Use %pe formatter to print error messages in human-readable
    format.
    
    Signed-off-by: Jan Sokolowski <jan.sokolowski@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>
    Stable-dep-of: 4e20655e503e ("i40e: Fix adding unsupported cloud filters")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring/fs: consider link->flags when getting path for LINKAT [+ + +]
Author: Charles Mirabile <cmirabil@redhat.com>
Date:   Mon Nov 20 05:55:45 2023 -0500

    io_uring/fs: consider link->flags when getting path for LINKAT
    
    commit 8479063f1fbee201a8739130e816cc331b675838 upstream.
    
    In order for `AT_EMPTY_PATH` to work as expected, the fact
    that the user wants that behavior needs to make it to `getname_flags`
    or it will return ENOENT.
    
    Fixes: cf30da90bc3a ("io_uring: add support for IORING_OP_LINKAT")
    Cc:  <stable@vger.kernel.org>
    Link: https://github.com/axboe/liburing/issues/995
    Signed-off-by: Charles Mirabile <cmirabil@redhat.com>
    Link: https://lore.kernel.org/r/20231120105545.1209530-1-cmirabil@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
io_uring: fix off-by one bvec index [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Mon Nov 20 14:18:31 2023 -0800

    io_uring: fix off-by one bvec index
    
    commit d6fef34ee4d102be448146f24caf96d7b4a05401 upstream.
    
    If the offset equals the bv_len of the first registered bvec, then the
    request does not include any of that first bvec. Skip it so that drivers
    don't have to deal with a zero length bvec, which was observed to break
    NVMe's PRP list creation.
    
    Cc: stable@vger.kernel.org
    Fixes: bd11b3a391e3 ("io_uring: don't use iov_iter_advance() for fixed buffers")
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Link: https://lore.kernel.org/r/20231120221831.2646460-1-kbusch@meta.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ipv4: Correct/silence an endian warning in __ip_do_redirect [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Sun Nov 19 22:17:59 2023 +0800

    ipv4: Correct/silence an endian warning in __ip_do_redirect
    
    [ Upstream commit c0e2926266af3b5acf28df0a8fc6e4d90effe0bb ]
    
    net/ipv4/route.c:783:46: warning: incorrect type in argument 2 (different base types)
    net/ipv4/route.c:783:46:    expected unsigned int [usertype] key
    net/ipv4/route.c:783:46:    got restricted __be32 [usertype] new_gw
    
    Fixes: 969447f226b4 ("ipv4: use new_gw for redirect neigh lookup")
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Link: https://lore.kernel.org/r/20231119141759.420477-1-chentao@kylinos.cn
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 6.1.65 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Dec 3 07:32:13 2023 +0100

    Linux 6.1.65
    
    Link: https://lore.kernel.org/r/20231130162135.977485944@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Conor Dooley <conor.dooley@microchip.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
lockdep: Fix block chain corruption [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Nov 21 12:41:26 2023 +0100

    lockdep: Fix block chain corruption
    
    [ Upstream commit bca4104b00fec60be330cd32818dd5c70db3d469 ]
    
    Kent reported an occasional KASAN splat in lockdep. Mark then noted:
    
    > I suspect the dodgy access is to chain_block_buckets[-1], which hits the last 4
    > bytes of the redzone and gets (incorrectly/misleadingly) attributed to
    > nr_large_chain_blocks.
    
    That would mean @size == 0, at which point size_to_bucket() returns -1
    and the above happens.
    
    alloc_chain_hlocks() has 'size - req', for the first with the
    precondition 'size >= rq', which allows the 0.
    
    This code is trying to split a block, del_chain_block() takes what we
    need, and add_chain_block() puts back the remainder, except in the
    above case the remainder is 0 sized and things go sideways.
    
    Fixes: 810507fe6fd5 ("locking/lockdep: Reuse freed chain_hlocks entries")
    Reported-by: Kent Overstreet <kent.overstreet@linux.dev>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Kent Overstreet <kent.overstreet@linux.dev>
    Link: https://lkml.kernel.org/r/20231121114126.GH8262@noisy.programming.kicks-ass.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md: fix bi_status reporting in md_end_clone_io [+ + +]
Author: Song Liu <song@kernel.org>
Date:   Fri Nov 17 15:56:30 2023 -0800

    md: fix bi_status reporting in md_end_clone_io
    
    commit 45b478951b2ba5aea70b2850c49c1aa83aedd0d2 upstream.
    
    md_end_clone_io() may overwrite error status in orig_bio->bi_status with
    BLK_STS_OK. This could happen when orig_bio has BIO_CHAIN (split by
    md_submit_bio => bio_split_to_limits, for example). As a result, upper
    layer may miss error reported from md (or the device) and consider the
    failed IO was successful.
    
    Fix this by only update orig_bio->bi_status when current bio reports
    error and orig_bio is BLK_STS_OK. This is the same behavior as
    __bio_chain_endio().
    
    Fixes: 10764815ff47 ("md: add io accounting for raid0 and raid5")
    Cc: stable@vger.kernel.org # v5.14+
    Reported-by: Bhanu Victor DiCara <00bvd0+linux@gmail.com>
    Closes: https://lore.kernel.org/regressions/5727380.DvuYhMxLoT@bvd0/
    Signed-off-by: Song Liu <song@kernel.org>
    Tested-by: Xiao Ni <xni@redhat.com>
    Reviewed-by: Yu Kuai <yukuai3@huawei.com>
    Acked-by: Guoqing Jiang <guoqing.jiang@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: camss: Convert to platform remove callback returning void [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sun Mar 26 16:31:09 2023 +0200

    media: camss: Convert to platform remove callback returning void
    
    [ Upstream commit 428bbf4be4018aefa26e4d6531779fa8925ecaaf ]
    
    The .remove() callback for a platform driver returns an int which makes
    many driver authors wrongly assume it's possible to do error handling by
    returning an error code. However the value returned is (mostly) ignored
    and this typically results in resource leaks. To improve here there is a
    quest to make the remove callback return void. In the first step of this
    quest all drivers are converted to .remove_new() which already returns
    void.
    
    Trivially convert this driver from always returning zero in the remove
    callback to the void returning variant.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Stable-dep-of: f69791c39745 ("media: qcom: camss: Fix genpd cleanup")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: camss: Split power domain management [+ + +]
Author: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Date:   Mon Jul 4 23:15:48 2022 +0100

    media: camss: Split power domain management
    
    [ Upstream commit 46cc031754985ee24034d55687540adb079f8630 ]
    
    There are three cases of power domain management on supported platforms:
    1) CAMSS on MSM8916, where a single VFE power domain is operated outside
       of the camss device driver,
    2) CAMSS on MSM8996 and SDM630/SDM660, where two VFE power domains are
       managed separately by the camss device driver, the power domains are
       linked and unlinked on demand by their functions vfe_pm_domain_on()
       and vfe_pm_domain_off() respectively,
    3) CAMSS on SDM845 and SM8250 platforms, and there are two VFE power
       domains and their parent power domain TITAN_TOP, the latter one
       shall be turned on prior to turning on any of VFE power domains.
    
    Due to a previously missing link between TITAN_TOP and VFEx power domains
    in the latter case, which is now fixed by [1], it was decided always to
    turn on all found VFE power domains and TITAN_TOP power domain, even if
    just one particular VFE is needed to be enabled or none of VFE power
    domains are required, for instance the latter case is when vfe_lite is in
    use. This misusage becomes more incovenient and clumsy, if next generations
    are to be supported, for instance CAMSS on SM8450 has three VFE power
    domains.
    
    The change splits the power management support for platforms with TITAN_TOP
    parent power domain, and, since 'power-domain-names' property is not
    present in camss device tree nodes, the assumption is that the first
    N power domains from the 'power-domains' list correspond to VFE power
    domains, and, if the number of power domains is greater than number of
    non-lite VFEs, then the last power domain from the list is the TITAN_TOP
    power domain.
    
    Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Reviewed-by: Robert Foss <robert.foss@linaro.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Stable-dep-of: f69791c39745 ("media: qcom: camss: Fix genpd cleanup")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: qcom: camss: Fix genpd cleanup [+ + +]
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Wed Aug 30 16:16:08 2023 +0100

    media: qcom: camss: Fix genpd cleanup
    
    [ Upstream commit f69791c39745e64621216fe8919cb73c0065002b ]
    
    Right now we never release the power-domains properly on the error path.
    Add a routine to be reused for this purpose and appropriate jumps in
    probe() to run that routine where necessary.
    
    Fixes: 2f6f8af67203 ("media: camss: Refactor VFE power domain toggling")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: qcom: camss: Fix V4L2 async notifier error path [+ + +]
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Wed Aug 30 16:16:07 2023 +0100

    media: qcom: camss: Fix V4L2 async notifier error path
    
    [ Upstream commit b278080a89f452063915beda0ade6b3ed5ee4271 ]
    
    Previously the jump label err_cleanup was used higher in the probe()
    function to release the async notifier however the async notifier
    registration was moved later in the code rendering the previous four jumps
    redundant.
    
    Rename the label from err_cleanup to err_v4l2_device_unregister to capture
    what the jump does.
    
    Fixes: 51397a4ec75d ("media: qcom: Initialise V4L2 async notifier later")
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    [hverkuil: fix old name in commit log: err_v4l2_device_register -> err_v4l2_device_unregister]
    Stable-dep-of: f69791c39745 ("media: qcom: camss: Fix genpd cleanup")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: qcom: Initialise V4L2 async notifier later [+ + +]
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Thu Mar 30 11:37:02 2023 +0200

    media: qcom: Initialise V4L2 async notifier later
    
    [ Upstream commit 5651bab6890a0c5d126e2559b4aa353bed201e47 ]
    
    Initialise V4L2 async notifier and parse DT for async sub-devices later,
    just before registering the notifier. This way the device can be made
    available to the V4L2 async framework from the notifier init time onwards.
    A subsequent patch will add struct v4l2_device as an argument to
    v4l2_async_nf_init().
    
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Tested-by: Philipp Zabel <p.zabel@pengutronix.de> # imx6qp
    Tested-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> # rcar + adv746x
    Tested-by: Aishwarya Kothari <aishwarya.kothari@toradex.com> # Apalis i.MX6Q with TC358743
    Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # Renesas RZ/G2L SMARC
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Stable-dep-of: f69791c39745 ("media: qcom: camss: Fix genpd cleanup")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
MIPS: KVM: Fix a build warning about variable set but not used [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Tue Oct 10 16:54:34 2023 +0800

    MIPS: KVM: Fix a build warning about variable set but not used
    
    [ Upstream commit 83767a67e7b6a0291cde5681ec7e3708f3f8f877 ]
    
    After commit 411740f5422a ("KVM: MIPS/MMU: Implement KVM_CAP_SYNC_MMU")
    old_pte is no longer used in kvm_mips_map_page(). So remove it to fix a
    build warning about variable set but not used:
    
       arch/mips/kvm/mmu.c: In function 'kvm_mips_map_page':
    >> arch/mips/kvm/mmu.c:701:29: warning: variable 'old_pte' set but not used [-Wunused-but-set-variable]
         701 |         pte_t *ptep, entry, old_pte;
             |                             ^~~~~~~
    
    Cc: stable@vger.kernel.org
    Fixes: 411740f5422a960 ("KVM: MIPS/MMU: Implement KVM_CAP_SYNC_MMU")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202310070530.aARZCSfh-lkp@intel.com/
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm,kfence: decouple kfence from page granularity mapping judgement [+ + +]
Author: Zhenhua Huang <quic_zhenhuah@quicinc.com>
Date:   Fri Mar 17 23:29:34 2023 +0800

    mm,kfence: decouple kfence from page granularity mapping judgement
    
    [ Upstream commit bfa7965b33ab79fc3b2f8adc14704075fe2416cd ]
    
    Kfence only needs its pool to be mapped as page granularity, if it is
    inited early. Previous judgement was a bit over protected. From [1], Mark
    suggested to "just map the KFENCE region a page granularity". So I
    decouple it from judgement and do page granularity mapping for kfence
    pool only. Need to be noticed that late init of kfence pool still requires
    page granularity mapping.
    
    Page granularity mapping in theory cost more(2M per 1GB) memory on arm64
    platform. Like what I've tested on QEMU(emulated 1GB RAM) with
    gki_defconfig, also turning off rodata protection:
    Before:
    [root@liebao ]# cat /proc/meminfo
    MemTotal:         999484 kB
    After:
    [root@liebao ]# cat /proc/meminfo
    MemTotal:        1001480 kB
    
    To implement this, also relocate the kfence pool allocation before the
    linear mapping setting up, arm64_kfence_alloc_pool is to allocate phys
    addr, __kfence_pool is to be set after linear mapping set up.
    
    LINK: [1] https://lore.kernel.org/linux-arm-kernel/Y+IsdrvDNILA59UN@FVFF77S0Q05N/
    Suggested-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Zhenhua Huang <quic_zhenhuah@quicinc.com>
    Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Reviewed-by: Marco Elver <elver@google.com>
    Link: https://lore.kernel.org/r/1679066974-690-1-git-send-email-quic_zhenhuah@quicinc.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Stable-dep-of: acfa60dbe038 ("arm64: mm: Fix "rodata=on" when CONFIG_RODATA_FULL_DEFAULT_ENABLED=y")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/smc: avoid data corruption caused by decline [+ + +]
Author: D. Wythe <alibuda@linux.alibaba.com>
Date:   Wed Nov 22 10:37:05 2023 +0800

    net/smc: avoid data corruption caused by decline
    
    [ Upstream commit e6d71b437abc2f249e3b6a1ae1a7228e09c6e563 ]
    
    We found a data corruption issue during testing of SMC-R on Redis
    applications.
    
    The benchmark has a low probability of reporting a strange error as
    shown below.
    
    "Error: Protocol error, got "\xe2" as reply type byte"
    
    Finally, we found that the retrieved error data was as follows:
    
    0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C
    0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2
    
    It is quite obvious that this is a SMC DECLINE message, which means that
    the applications received SMC protocol message.
    We found that this was caused by the following situations:
    
    client                  server
            ¦  clc proposal
            ------------->
            ¦  clc accept
            <-------------
            ¦  clc confirm
            ------------->
    wait llc confirm
                            send llc confirm
            ¦failed llc confirm
            ¦   x------
    (after 2s)timeout
                            wait llc confirm rsp
    
    wait decline
    
    (after 1s) timeout
                            (after 2s) timeout
            ¦   decline
            -------------->
            ¦   decline
            <--------------
    
    As a result, a decline message was sent in the implementation, and this
    message was read from TCP by the already-fallback connection.
    
    This patch double the client timeout as 2x of the server value,
    With this simple change, the Decline messages should never cross or
    collide (during Confirm link timeout).
    
    This issue requires an immediate solution, since the protocol updates
    involve a more long-term solution.
    
    Fixes: 0fb0b02bd6fd ("net/smc: adapt SMC client code to use the LLC flow")
    Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
    Reviewed-by: Wen Gu <guwen@linux.alibaba.com>
    Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: axienet: Fix check for partial TX checksum [+ + +]
Author: Samuel Holland <samuel.holland@sifive.com>
Date:   Tue Nov 21 16:42:17 2023 -0800

    net: axienet: Fix check for partial TX checksum
    
    [ Upstream commit fd0413bbf8b11f56e8aa842783b0deda0dfe2926 ]
    
    Due to a typo, the code checked the RX checksum feature in the TX path.
    
    Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
    Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
    Link: https://lore.kernel.org/r/20231122004219.3504219-1-samuel.holland@sifive.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: ax88179_178a: fix failed operations during ax88179_reset [+ + +]
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Date:   Mon Nov 20 13:06:29 2023 +0100

    net: usb: ax88179_178a: fix failed operations during ax88179_reset
    
    [ Upstream commit 0739af07d1d947af27c877f797cb82ceee702515 ]
    
    Using generic ASIX Electronics Corp. AX88179 Gigabit Ethernet device,
    the following test cycle has been implemented:
        - power on
        - check logs
        - shutdown
        - after detecting the system shutdown, disconnect power
        - after approximately 60 seconds of sleep, power is restored
    Running some cycles, sometimes error logs like this appear:
        kernel: ax88179_178a 2-9:1.0 (unnamed net_device) (uninitialized): Failed to write reg index 0x0001: -19
        kernel: ax88179_178a 2-9:1.0 (unnamed net_device) (uninitialized): Failed to read reg index 0x0001: -19
        ...
    These failed operation are happening during ax88179_reset execution, so
    the initialization could not be correct.
    
    In order to avoid this, we need to increase the delay after reset and
    clock initial operations. By using these larger values, many cycles
    have been run and no failed operations appear.
    
    It would be better to check some status register to verify when the
    operation has finished, but I do not have found any available information
    (neither in the public datasheets nor in the manufacturer's driver). The
    only available information for the necessary delays is the maufacturer's
    driver (original values) but the proposed values are not enough for the
    tested devices.
    
    Fixes: e2ca90c276e1f ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver")
    Reported-by: Herb Wei <weihao.bj@ieisystem.com>
    Tested-by: Herb Wei <weihao.bj@ieisystem.com>
    Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
    Link: https://lore.kernel.org/r/20231120120642.54334-1-jtornosm@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSD: Fix "start of NFS reply" pointer passed to nfsd_cache_update() [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Nov 28 17:01:30 2023 -0500

    NFSD: Fix "start of NFS reply" pointer passed to nfsd_cache_update()
    
    [ Upstream commit 1caf5f61dd8430ae5a0b4538afe4953ce7517cbb ]
    
    The "statp + 1" pointer that is passed to nfsd_cache_update() is
    supposed to point to the start of the egress NFS Reply header. In
    fact, it does point there for AUTH_SYS and RPCSEC_GSS_KRB5 requests.
    
    But both krb5i and krb5p add fields between the RPC header's
    accept_stat field and the start of the NFS Reply header. In those
    cases, "statp + 1" points at the extra fields instead of the Reply.
    The result is that nfsd_cache_update() caches what looks to the
    client like garbage.
    
    A connection break can occur for a number of reasons, but the most
    common reason when using krb5i/p is a GSS sequence number window
    underrun. When an underrun is detected, the server is obliged to
    drop the RPC and the connection to force a retransmit with a fresh
    GSS sequence number. The client presents the same XID, it hits in
    the server's DRC, and the server returns the garbage cache entry.
    
    The "statp + 1" argument has been used since the oldest changeset
    in the kernel history repo, so it has been in nfsd_dispatch()
    literally since before history began. The problem arose only when
    the server-side GSS implementation was added twenty years ago.
    
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Tested-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

NFSD: Fix checksum mismatches in the duplicate reply cache [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Nov 28 17:01:36 2023 -0500

    NFSD: Fix checksum mismatches in the duplicate reply cache
    
    [ Upstream commit bf51c52a1f3c238d72c64e14d5e7702d3a245b82 ]
    
    nfsd_cache_csum() currently assumes that the server's RPC layer has
    been advancing rq_arg.head[0].iov_base as it decodes an incoming
    request, because that's the way it used to work. On entry, it
    expects that buf->head[0].iov_base points to the start of the NFS
    header, and excludes the already-decoded RPC header.
    
    These days however, head[0].iov_base now points to the start of the
    RPC header during all processing. It no longer points at the NFS
    Call header when execution arrives at nfsd_cache_csum().
    
    In a retransmitted RPC the XID and the NFS header are supposed to
    be the same as the original message, but the contents of the
    retransmitted RPC header can be different. For example, for krb5,
    the GSS sequence number will be different between the two. Thus if
    the RPC header is always included in the DRC checksum computation,
    the checksum of the retransmitted message might not match the
    checksum of the original message, even though the NFS part of these
    messages is identical.
    
    The result is that, even if a matching XID is found in the DRC,
    the checksum mismatch causes the server to execute the
    retransmitted RPC transaction again.
    
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Tested-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nvmet: nul-terminate the NQNs passed in the connect command [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Nov 17 08:13:36 2023 -0500

    nvmet: nul-terminate the NQNs passed in the connect command
    
    [ Upstream commit 1c22e0295a5eb571c27b53c7371f95699ef705ff ]
    
    The host and subsystem NQNs are passed in the connect command payload and
    interpreted as nul-terminated strings.  Ensure they actually are
    nul-terminated before using them.
    
    Fixes: a07b4970f464 "nvmet: add a generic NVMe target")
    Reported-by: Alon Zahavi <zahavi.alon@gmail.com>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-pf: Fix memory leak during interface down [+ + +]
Author: Suman Ghosh <sumang@marvell.com>
Date:   Fri Nov 17 16:10:18 2023 +0530

    octeontx2-pf: Fix memory leak during interface down
    
    [ Upstream commit 5f228d7c8a539714c1e9b7e7534f76bb7979f268 ]
    
    During 'ifconfig <netdev> down' one RSS memory was not getting freed.
    This patch fixes the same.
    
    Fixes: 81a4362016e7 ("octeontx2-pf: Add RSS multi group support")
    Signed-off-by: Suman Ghosh <sumang@marvell.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-pf: Fix ntuple rule creation to direct packet to VF with higher Rx queue than its PF [+ + +]
Author: Suman Ghosh <sumang@marvell.com>
Date:   Tue Nov 21 22:26:24 2023 +0530

    octeontx2-pf: Fix ntuple rule creation to direct packet to VF with higher Rx queue than its PF
    
    [ Upstream commit 4aa1d8f89b10cdc25a231dabf808d8935e0b137a ]
    
    It is possible to add a ntuple rule which would like to direct packet to
    a VF whose number of queues are greater/less than its PF's queue numbers.
    For example a PF can have 2 Rx queues but a VF created on that PF can have
    8 Rx queues. As of today, ntuple rule will reject rule because it is
    checking the requested queue number against PF's number of Rx queues.
    As a part of this fix if the action of a ntuple rule is to move a packet
    to a VF's queue then the check is removed. Also, a debug information is
    printed to aware user that it is user's responsibility to cross check if
    the requested queue number on that VF is a valid one.
    
    Fixes: f0a1913f8a6f ("octeontx2-pf: Add support for ethtool ntuple filters")
    Signed-off-by: Suman Ghosh <sumang@marvell.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20231121165624.3664182-1-sumang@marvell.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/dasd: protect device queue against concurrent access [+ + +]
Author: Jan Höppner <hoeppner@linux.ibm.com>
Date:   Wed Oct 25 15:24:37 2023 +0200

    s390/dasd: protect device queue against concurrent access
    
    commit db46cd1e0426f52999d50fa72cfa97fa39952885 upstream.
    
    In dasd_profile_start() the amount of requests on the device queue are
    counted. The access to the device queue is unprotected against
    concurrent access. With a lot of parallel I/O, especially with alias
    devices enabled, the device queue can change while dasd_profile_start()
    is accessing the queue. In the worst case this leads to a kernel panic
    due to incorrect pointer accesses.
    
    Fix this by taking the device lock before accessing the queue and
    counting the requests. Additionally the check for a valid profile data
    pointer can be done earlier to avoid unnecessary locking in a hot path.
    
    Cc:  <stable@vger.kernel.org>
    Fixes: 4fa52aa7a82f ("[S390] dasd: add enhanced DASD statistics interface")
    Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
    Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Link: https://lore.kernel.org/r/20231025132437.1223363-3-sth@linux.ibm.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smb3: allow dumping session and tcon id to improve stats analysis and debugging [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Thu Nov 9 15:28:12 2023 -0600

    smb3: allow dumping session and tcon id to improve stats analysis and debugging
    
    [ Upstream commit de4eceab578ead12a71e5b5588a57e142bbe8ceb ]
    
    When multiple mounts are to the same share from the same client it was not
    possible to determine which section of /proc/fs/cifs/Stats (and DebugData)
    correspond to that mount.  In some recent examples this turned out to  be
    a significant problem when trying to analyze performance data - since
    there are many cases where unless we know the tree id and session id we
    can't figure out which stats (e.g. number of SMB3.1.1 requests by type,
    the total time they take, which is slowest, how many fail etc.) apply to
    which mount. The only existing loosely related ioctl CIFS_IOC_GET_MNT_INFO
    does not return the information needed to uniquely identify which tcon
    is which mount although it does return various flags and device info.
    
    Add a cifs.ko ioctl CIFS_IOC_GET_TCON_INFO (0x800ccf0c) to return tid,
    session id, tree connect count.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
swiotlb-xen: provide the "max_mapping_size" method [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Mon Nov 6 18:12:30 2023 +0100

    swiotlb-xen: provide the "max_mapping_size" method
    
    commit bff2a2d453a1b683378b4508b86b84389f551a00 upstream.
    
    There's a bug that when using the XEN hypervisor with bios with large
    multi-page bio vectors on NVMe, the kernel deadlocks [1].
    
    The deadlocks are caused by inability to map a large bio vector -
    dma_map_sgtable always returns an error, this gets propagated to the block
    layer as BLK_STS_RESOURCE and the block layer retries the request
    indefinitely.
    
    XEN uses the swiotlb framework to map discontiguous pages into contiguous
    runs that are submitted to the PCIe device. The swiotlb framework has a
    limitation on the length of a mapping - this needs to be announced with
    the max_mapping_size method to make sure that the hardware drivers do not
    create larger mappings.
    
    Without max_mapping_size, the NVMe block driver would create large
    mappings that overrun the maximum mapping size.
    
    Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Link: https://lore.kernel.org/stable/ZTNH0qtmint%2FzLJZ@mail-itl/ [1]
    Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Suggested-by: Christoph Hellwig <hch@lst.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Acked-by: Stefano Stabellini <sstabellini@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/151bef41-e817-aea9-675-a35fdac4ed@redhat.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: cdnsp: Fix deadlock issue during using NCM gadget [+ + +]
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Wed Nov 8 10:31:25 2023 +0100

    usb: cdnsp: Fix deadlock issue during using NCM gadget
    
    commit 58f2fcb3a845fcbbad2f3196bb37d744e0506250 upstream.
    
    The interrupt service routine registered for the gadget is a primary
    handler which mask the interrupt source and a threaded handler which
    handles the source of the interrupt. Since the threaded handler is
    voluntary threaded, the IRQ-core does not disable bottom halves before
    invoke the handler like it does for the forced-threaded handler.
    
    Due to changes in networking it became visible that a network gadget's
    completions handler may schedule a softirq which remains unprocessed.
    The gadget's completion handler is usually invoked either in hard-IRQ or
    soft-IRQ context. In this context it is enough to just raise the softirq
    because the softirq itself will be handled once that context is left.
    In the case of the voluntary threaded handler, there is nothing that
    will process pending softirqs. Which means it remain queued until
    another random interrupt (on this CPU) fires and handles it on its exit
    path or another thread locks and unlocks a lock with the bh suffix.
    Worst case is that the CPU goes idle and the NOHZ complains about
    unhandled softirqs.
    
    Disable bottom halves before acquiring the lock (and disabling
    interrupts) and enable them after dropping the lock. This ensures that
    any pending softirqs will handled right away.
    
    cc: stable@vger.kernel.org
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Acked-by: Peter Chen <peter.chen@kernel.org>
    Link: https://lore.kernel.org/r/20231108093125.224963-1-pawell@cadence.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: dwc2: write HCINT with INTMASK applied [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Nov 15 15:45:07 2023 +0100

    USB: dwc2: write HCINT with INTMASK applied
    
    commit 0583bc776ca5b5a3f5752869fc31cf7322df2b35 upstream.
    
    dwc2_hc_n_intr() writes back INTMASK as read but evaluates it
    with intmask applied. In stress testing this causes spurious
    interrupts like this:
    
    [Mon Aug 14 10:51:07 2023] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but reason is unknown
    [Mon Aug 14 10:51:07 2023] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001
    [Mon Aug 14 10:51:08 2023] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set, but reason is unknown
    [Mon Aug 14 10:51:08 2023] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001
    [Mon Aug 14 10:51:08 2023] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but reason is unknown
    [Mon Aug 14 10:51:08 2023] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001
    [Mon Aug 14 10:51:08 2023] dwc2 3f980000.usb: dwc2_update_urb_state_abn(): trimming xfer length
    
    Applying INTMASK prevents this. The issue exists in all versions of the
    driver.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Tested-by: Ivan Ivanov <ivan.ivanov@suse.com>
    Tested-by: Andrea della Porta <andrea.porta@suse.com>
    Link: https://lore.kernel.org/r/20231115144514.15248-1-oneukum@suse.com
    Cc: stable <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: dwc3: Fix default mode initialization [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Wed Oct 25 11:51:10 2023 +0200

    usb: dwc3: Fix default mode initialization
    
    commit 10d510abd096d620b9fda2dd3e0047c5efc4ad2b upstream.
    
    The default mode, configurable by DT, shall be set before usb role switch
    driver is registered. Otherwise there is a race between default mode
    and mode set by usb role switch driver.
    
    Fixes: 98ed256a4dbad ("usb: dwc3: Add support for role-switch-default-mode binding")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20231025095110.2405281-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: dwc3: qcom: fix ACPI platform device leak [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Nov 17 18:36:50 2023 +0100

    USB: dwc3: qcom: fix ACPI platform device leak
    
    [ Upstream commit 9cf87666fc6e08572341fe08ecd909935998fbbd ]
    
    Make sure to free the "urs" platform device, which is created for some
    ACPI platforms, on probe errors and on driver unbind.
    
    Compile-tested only.
    
    Fixes: c25c210f590e ("usb: dwc3: qcom: add URS Host support for sdm845 ACPI boot")
    Cc: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Acked-by: Andrew Halaney <ahalaney@redhat.com>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Link: https://lore.kernel.org/r/20231117173650.21161-4-johan+linaro@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

USB: dwc3: qcom: fix resource leaks on probe deferral [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Nov 17 18:36:48 2023 +0100

    USB: dwc3: qcom: fix resource leaks on probe deferral
    
    [ Upstream commit 51392a1879ff06dc21b68aef4825f6ef68a7be42 ]
    
    The driver needs to deregister and free the newly allocated dwc3 core
    platform device on ACPI probe errors (e.g. probe deferral) and on driver
    unbind but instead it leaked those resources while erroneously dropping
    a reference to the parent platform device which is still in use.
    
    For OF probing the driver takes a reference to the dwc3 core platform
    device which has also always been leaked.
    
    Fix the broken ACPI tear down and make sure to drop the dwc3 core
    reference for both OF and ACPI.
    
    Fixes: 8fd95da2cfb5 ("usb: dwc3: qcom: Release the correct resources in dwc3_qcom_remove()")
    Fixes: 2bc02355f8ba ("usb: dwc3: qcom: Add support for booting with ACPI")
    Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
    Cc: stable@vger.kernel.org      # 4.18
    Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Cc: Lee Jones <lee@kernel.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Acked-by: Andrew Halaney <ahalaney@redhat.com>
    Link: https://lore.kernel.org/r/20231117173650.21161-2-johan+linaro@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 9cf87666fc6e ("USB: dwc3: qcom: fix ACPI platform device leak")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

USB: dwc3: qcom: fix software node leak on probe errors [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Nov 17 18:36:49 2023 +0100

    USB: dwc3: qcom: fix software node leak on probe errors
    
    commit 9feefbf57d92e8ee293dad67585d351c7d0b6e37 upstream.
    
    Make sure to remove the software node also on (ACPI) probe errors to
    avoid leaking the underlying resources.
    
    Note that the software node is only used for ACPI probe so the driver
    unbind tear down is updated to match probe.
    
    Fixes: 8dc6e6dd1bee ("usb: dwc3: qcom: Constify the software node")
    Cc: stable@vger.kernel.org      # 5.12
    Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Acked-by: Andrew Halaney <ahalaney@redhat.com>
    Link: https://lore.kernel.org/r/20231117173650.21161-3-johan+linaro@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: dwc3: qcom: fix wakeup after probe deferral [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Nov 20 17:16:06 2023 +0100

    USB: dwc3: qcom: fix wakeup after probe deferral
    
    commit 41f5a0973259db9e4e3c9963d36505f80107d1a0 upstream.
    
    The Qualcomm glue driver is overriding the interrupt trigger types
    defined by firmware when requesting the wakeup interrupts during probe.
    
    This can lead to a failure to map the DP/DM wakeup interrupts after a
    probe deferral as the firmware defined trigger types do not match the
    type used for the initial mapping:
    
            irq: type mismatch, failed to map hwirq-14 for interrupt-controller@b220000!
            irq: type mismatch, failed to map hwirq-15 for interrupt-controller@b220000!
    
    Fix this by not overriding the firmware provided trigger types when
    requesting the wakeup interrupts.
    
    Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
    Cc: stable@vger.kernel.org      # 4.18
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
    Link: https://lore.kernel.org/r/20231120161607.7405-3-johan+linaro@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: dwc3: set the dma max_seg_size [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Fri Oct 27 11:28:20 2023 +0000

    usb: dwc3: set the dma max_seg_size
    
    commit 8bbae288a85abed6a1cf7d185d8b9dc2f5dcb12c upstream.
    
    Allow devices to have dma operations beyond 4K, and avoid warnings such
    as:
    
    DMA-API: dwc3 a600000.usb: mapping sg segment longer than device claims to support [len=86016] [max=65536]
    
    Cc: stable@vger.kernel.org
    Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
    Reported-by: Zubin Mithra <zsm@chromium.org>
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20231026-dwc3-v2-1-1d4fd5c3e067@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: serial: option: add Fibocom L7xx modules [+ + +]
Author: Victor Fragoso <victorffs@hotmail.com>
Date:   Tue Nov 21 21:05:56 2023 +0000

    USB: serial: option: add Fibocom L7xx modules
    
    commit e389fe8b68137344562fb6e4d53d8a89ef6212dd upstream.
    
    Add support for Fibocom L716-EU module series.
    
    L716-EU is a Fibocom module based on ZTE's V3E/V3T chipset.
    
    Device creates multiple interfaces when connected to PC as follows:
     - Network Interface: ECM or RNDIS (set by FW or AT Command)
     - ttyUSB0: AT port
     - ttyUSB1: Modem port
     - ttyUSB2: AT2 port
     - ttyUSB3: Trace port for log information
     - ADB: ADB port for debugging. ("Driver=usbfs" when ADB server enabled)
    
    Here are the outputs of lsusb and usb-devices:
    $ ls /dev/ttyUSB*
    /dev/ttyUSB0  /dev/ttyUSB1  /dev/ttyUSB2  /dev/ttyUSB3
    
    usb-devices:
    L716-EU (ECM mode):
    T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 51 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2cb7 ProdID=0001 Rev= 1.00
    S:  Manufacturer=Fibocom,Incorporated
    S:  Product=Fibocom Mobile Boardband
    S:  SerialNumber=1234567890ABCDEF
    C:* #Ifs= 7 Cfg#= 1 Atr=e0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether
    E:  Ad=87(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    L716-EU (RNDIS mode):
    T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 49 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2cb7 ProdID=0001 Rev= 1.00
    S:  Manufacturer=Fibocom,Incorporated
    S:  Product=Fibocom Mobile Boardband
    S:  SerialNumber=1234567890ABCDEF
    C:* #Ifs= 7 Cfg#= 1 Atr=e0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver=rndis_host
    E:  Ad=87(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Victor Fragoso <victorffs@hotmail.com>
    Reviewed-by: Lars Melin <larsm17@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Luat Air72*U series products [+ + +]
Author: Asuna Yang <spriteovo@gmail.com>
Date:   Wed Nov 22 22:18:03 2023 +0800

    USB: serial: option: add Luat Air72*U series products
    
    commit da90e45d5afc4da2de7cd3ea7943d0f1baa47cc2 upstream.
    
    Update the USB serial option driver support for Luat Air72*U series
    products.
    
    ID 1782:4e00 Spreadtrum Communications Inc. UNISOC-8910
    
    T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 13 Spd=480 MxCh= 0
    D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
    P: Vendor=1782 ProdID=4e00 Rev=00.00
    S: Manufacturer=UNISOC
    S: Product=UNISOC-8910
    C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=400mA
    I: If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host
    E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=4096ms
    I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    If#= 2: AT
    If#= 3: PPP + AT
    If#= 4: Debug
    
    Co-developed-by: Yangyu Chen <cyy@cyyself.name>
    Signed-off-by: Yangyu Chen <cyy@cyyself.name>
    Signed-off-by: Asuna Yang <SpriteOvO@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: don't claim interface 4 for ZTE MF290 [+ + +]
Author: Lech Perczak <lech.perczak@gmail.com>
Date:   Sat Nov 18 00:19:17 2023 +0100

    USB: serial: option: don't claim interface 4 for ZTE MF290
    
    commit 8771127e25d6c20d458ad27cf32f7fcfc1755e05 upstream.
    
    Interface 4 is used by for QMI interface in stock firmware of MF28D, the
    router which uses MF290 modem. Free the interface up, to rebind it to
    qmi_wwan driver.
    The proper configuration is:
    
    Interface mapping is:
    0: QCDM, 1: (unknown), 2: AT (PCUI), 2: AT (Modem), 4: QMI
    
    T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  4 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=19d2 ProdID=0189 Rev= 0.00
    S:  Manufacturer=ZTE, Incorporated
    S:  Product=ZTE LTE Technologies MSM
    C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=84(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=86(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    
    Cc: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: fix FM101R-GL defines [+ + +]
Author: Puliang Lu <puliang.lu@fibocom.com>
Date:   Thu Oct 26 20:35:06 2023 +0800

    USB: serial: option: fix FM101R-GL defines
    
    commit a1092619dd28ac0fcf23016160a2fdccd98ef935 upstream.
    
    Modify the definition of the two Fibocom FM101R-GL PID macros, which had
    their PIDs switched.
    
    The correct PIDs are:
    
    - VID:PID 413C:8213, FM101R-GL ESIM are laptop M.2 cards (with
      MBIM interfaces for Linux)
    
    - VID:PID 413C:8215, FM101R-GL are laptop M.2 cards (with
      MBIM interface for Linux)
    
    0x8213: mbim, tty
    0x8215: mbim, tty
    
    Signed-off-by: Puliang Lu <puliang.lu@fibocom.com>
    Fixes: 52480e1f1a25 ("USB: serial: option: add Fibocom to DELL custom modem FM101R-GL")
    Link: https://lore.kernel.org/lkml/TYZPR02MB508845BAD7936A62A105CE5D89DFA@TYZPR02MB5088.apcprd02.prod.outlook.com/
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: typec: tcpm: Skip hard reset when in error recovery [+ + +]
Author: Badhri Jagan Sridharan <badhri@google.com>
Date:   Wed Nov 1 02:19:09 2023 +0000

    usb: typec: tcpm: Skip hard reset when in error recovery
    
    commit a6fe37f428c19dd164c2111157d4a1029bd853aa upstream.
    
    Hard reset queued prior to error recovery (or) received during
    error recovery will make TCPM to prematurely exit error recovery
    sequence. Ignore hard resets received during error recovery (or)
    port reset sequence.
    
    ```
    [46505.459688] state change SNK_READY -> ERROR_RECOVERY [rev3 NONE_AMS]
    [46505.459706] state change ERROR_RECOVERY -> PORT_RESET [rev3 NONE_AMS]
    [46505.460433] disable vbus discharge ret:0
    [46505.461226] Setting usb_comm capable false
    [46505.467244] Setting voltage/current limit 0 mV 0 mA
    [46505.467262] polarity 0
    [46505.470695] Requesting mux state 0, usb-role 0, orientation 0
    [46505.475621] cc:=0
    [46505.476012] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev3 NONE_AMS]
    [46505.476020] Received hard reset
    [46505.476024] state change PORT_RESET -> HARD_RESET_START [rev3 HARD_RESET]
    ```
    
    Cc: stable@vger.kernel.org
    Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
    Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
    Acked-by: Heikki Krogeus <heikki.krogerus@linux.intel.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20231101021909.2962679-1-badhri@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wireguard: use DEV_STATS_INC() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Nov 17 14:17:33 2023 +0000

    wireguard: use DEV_STATS_INC()
    
    [ Upstream commit 93da8d75a66568ba4bb5b14ad2833acd7304cd02 ]
    
    wg_xmit() can be called concurrently, KCSAN reported [1]
    some device stats updates can be lost.
    
    Use DEV_STATS_INC() for this unlikely case.
    
    [1]
    BUG: KCSAN: data-race in wg_xmit / wg_xmit
    
    read-write to 0xffff888104239160 of 8 bytes by task 1375 on cpu 0:
    wg_xmit+0x60f/0x680 drivers/net/wireguard/device.c:231
    __netdev_start_xmit include/linux/netdevice.h:4918 [inline]
    netdev_start_xmit include/linux/netdevice.h:4932 [inline]
    xmit_one net/core/dev.c:3543 [inline]
    dev_hard_start_xmit+0x11b/0x3f0 net/core/dev.c:3559
    ...
    
    read-write to 0xffff888104239160 of 8 bytes by task 1378 on cpu 1:
    wg_xmit+0x60f/0x680 drivers/net/wireguard/device.c:231
    __netdev_start_xmit include/linux/netdevice.h:4918 [inline]
    netdev_start_xmit include/linux/netdevice.h:4932 [inline]
    xmit_one net/core/dev.c:3543 [inline]
    dev_hard_start_xmit+0x11b/0x3f0 net/core/dev.c:3559
    ...
    
    v2: also change wg_packet_consume_data_done() (Hangbin Liu)
        and wg_packet_purge_staged_packets()
    
    Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jason A. Donenfeld <Jason@zx2c4.com>
    Cc: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>