--- /dev/null
+From bf5570590a981d0659d0808d2d4bcda21b27a2a5 Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Tue, 21 Oct 2025 20:38:22 +0100
+Subject: MIPS: Malta: Fix keyboard resource preventing i8042 driver from registering
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit bf5570590a981d0659d0808d2d4bcda21b27a2a5 upstream.
+
+MIPS Malta platform code registers the PCI southbridge legacy port I/O
+PS/2 keyboard range as a standard resource marked as busy. It prevents
+the i8042 driver from registering as it fails to claim the resource in
+a call to i8042_platform_init(). Consequently PS/2 keyboard and mouse
+devices cannot be used with this platform.
+
+Fix the issue by removing the busy marker from the standard reservation,
+making the driver register successfully:
+
+ serio: i8042 KBD port at 0x60,0x64 irq 1
+ serio: i8042 AUX port at 0x60,0x64 irq 12
+
+and the resource show up as expected among the legacy devices:
+
+ 00000000-00ffffff : MSC PCI I/O
+ 00000000-0000001f : dma1
+ 00000020-00000021 : pic1
+ 00000040-0000005f : timer
+ 00000060-0000006f : keyboard
+ 00000060-0000006f : i8042
+ 00000070-00000077 : rtc0
+ 00000080-0000008f : dma page reg
+ 000000a0-000000a1 : pic2
+ 000000c0-000000df : dma2
+ [...]
+
+If the i8042 driver has not been configured, then the standard resource
+will remain there preventing any conflicting dynamic assignment of this
+PCI port I/O address range.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/alpine.DEB.2.21.2510211919240.8377@angie.orcam.me.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/mips/mti-malta/malta-setup.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/mips/mti-malta/malta-setup.c
++++ b/arch/mips/mti-malta/malta-setup.c
+@@ -47,7 +47,7 @@ static struct resource standard_io_resou
+ .name = "keyboard",
+ .start = 0x60,
+ .end = 0x6f,
+- .flags = IORESOURCE_IO | IORESOURCE_BUSY
++ .flags = IORESOURCE_IO
+ },
+ {
+ .name = "dma page reg",
--- /dev/null
+From 10843e1492e474c02b91314963161731fa92af91 Mon Sep 17 00:00:00 2001
+From: Tonghao Zhang <tonghao@bamaicloud.com>
+Date: Tue, 21 Oct 2025 13:09:33 +0800
+Subject: net: bonding: fix possible peer notify event loss or dup issue
+
+From: Tonghao Zhang <tonghao@bamaicloud.com>
+
+commit 10843e1492e474c02b91314963161731fa92af91 upstream.
+
+If the send_peer_notif counter and the peer event notify are not synchronized.
+It may cause problems such as the loss or dup of peer notify event.
+
+Before this patch:
+- If should_notify_peers is true and the lock for send_peer_notif-- fails, peer
+ event may be sent again in next mii_monitor loop, because should_notify_peers
+ is still true.
+- If should_notify_peers is true and the lock for send_peer_notif-- succeeded,
+ but the lock for peer event fails, the peer event will be lost.
+
+This patch locks the RTNL for send_peer_notif, events, and commit simultaneously.
+
+Fixes: 07a4ddec3ce9 ("bonding: add an option to specify a delay between peer notifications")
+Cc: Jay Vosburgh <jv@jvosburgh.net>
+Cc: Andrew Lunn <andrew+netdev@lunn.ch>
+Cc: Eric Dumazet <edumazet@google.com>
+Cc: Jakub Kicinski <kuba@kernel.org>
+Cc: Paolo Abeni <pabeni@redhat.com>
+Cc: Hangbin Liu <liuhangbin@gmail.com>
+Cc: Nikolay Aleksandrov <razor@blackwall.org>
+Cc: Vincent Bernat <vincent@bernat.ch>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Tonghao Zhang <tonghao@bamaicloud.com>
+Acked-by: Jay Vosburgh <jv@jvosburgh.net>
+Link: https://patch.msgid.link/20251021050933.46412-1-tonghao@bamaicloud.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/bonding/bond_main.c | 40 ++++++++++++++++++----------------------
+ 1 file changed, 18 insertions(+), 22 deletions(-)
+
+--- a/drivers/net/bonding/bond_main.c
++++ b/drivers/net/bonding/bond_main.c
+@@ -2734,7 +2734,7 @@ static void bond_mii_monitor(struct work
+ {
+ struct bonding *bond = container_of(work, struct bonding,
+ mii_work.work);
+- bool should_notify_peers = false;
++ bool should_notify_peers;
+ bool commit;
+ unsigned long delay;
+ struct slave *slave;
+@@ -2746,30 +2746,33 @@ static void bond_mii_monitor(struct work
+ goto re_arm;
+
+ rcu_read_lock();
++
+ should_notify_peers = bond_should_notify_peers(bond);
+ commit = !!bond_miimon_inspect(bond);
+- if (bond->send_peer_notif) {
+- rcu_read_unlock();
+- if (rtnl_trylock()) {
+- bond->send_peer_notif--;
+- rtnl_unlock();
+- }
+- } else {
+- rcu_read_unlock();
+- }
+
+- if (commit) {
++ rcu_read_unlock();
++
++ if (commit || bond->send_peer_notif) {
+ /* Race avoidance with bond_close cancel of workqueue */
+ if (!rtnl_trylock()) {
+ delay = 1;
+- should_notify_peers = false;
+ goto re_arm;
+ }
+
+- bond_for_each_slave(bond, slave, iter) {
+- bond_commit_link_state(slave, BOND_SLAVE_NOTIFY_LATER);
++ if (commit) {
++ bond_for_each_slave(bond, slave, iter) {
++ bond_commit_link_state(slave,
++ BOND_SLAVE_NOTIFY_LATER);
++ }
++ bond_miimon_commit(bond);
++ }
++
++ if (bond->send_peer_notif) {
++ bond->send_peer_notif--;
++ if (should_notify_peers)
++ call_netdevice_notifiers(NETDEV_NOTIFY_PEERS,
++ bond->dev);
+ }
+- bond_miimon_commit(bond);
+
+ rtnl_unlock(); /* might sleep, hold no other locks */
+ }
+@@ -2777,13 +2780,6 @@ static void bond_mii_monitor(struct work
+ re_arm:
+ if (bond->params.miimon)
+ queue_delayed_work(bond->wq, &bond->mii_work, delay);
+-
+- if (should_notify_peers) {
+- if (!rtnl_trylock())
+- return;
+- call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, bond->dev);
+- rtnl_unlock();
+- }
+ }
+
+ static int bond_upper_dev_walk(struct net_device *upper,
--- /dev/null
+From 706136c5723626fcde8dd8f598a4dcd251e24927 Mon Sep 17 00:00:00 2001
+From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+Date: Fri, 17 Oct 2025 16:18:30 +0100
+Subject: net: ravb: Ensure memory write completes before ringing TX doorbell
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+commit 706136c5723626fcde8dd8f598a4dcd251e24927 upstream.
+
+Add a final dma_wmb() barrier before triggering the transmit request
+(TCCR_TSRQ) to ensure all descriptor and buffer writes are visible to
+the DMA engine.
+
+According to the hardware manual, a read-back operation is required
+before writing to the doorbell register to guarantee completion of
+previous writes. Instead of performing a dummy read, a dma_wmb() is
+used to both enforce the same ordering semantics on the CPU side and
+also to ensure completion of writes.
+
+Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
+Cc: stable@vger.kernel.org
+Co-developed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
+Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
+Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
+Link: https://patch.msgid.link/20251017151830.171062-5-prabhakar.mahadev-lad.rj@bp.renesas.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/renesas/ravb_main.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/net/ethernet/renesas/ravb_main.c
++++ b/drivers/net/ethernet/renesas/ravb_main.c
+@@ -1672,6 +1672,14 @@ static netdev_tx_t ravb_start_xmit(struc
+ } else {
+ desc->die_dt = DT_FSINGLE;
+ }
++
++ /* Before ringing the doorbell we need to make sure that the latest
++ * writes have been committed to memory, otherwise it could delay
++ * things until the doorbell is rang again.
++ * This is in replacement of the read operation mentioned in the HW
++ * manuals.
++ */
++ dma_wmb();
+ ravb_modify(ndev, TCCR, TCCR_TSRQ0 << q, TCCR_TSRQ0 << q);
+
+ priv->cur_tx[q] += num_tx_desc;
--- /dev/null
+From 75cea9860aa6b2350d90a8d78fed114d27c7eca2 Mon Sep 17 00:00:00 2001
+From: Michal Pecio <michal.pecio@gmail.com>
+Date: Tue, 14 Oct 2025 20:35:28 +0200
+Subject: net: usb: rtl8150: Fix frame padding
+
+From: Michal Pecio <michal.pecio@gmail.com>
+
+commit 75cea9860aa6b2350d90a8d78fed114d27c7eca2 upstream.
+
+TX frames aren't padded and unknown memory is sent into the ether.
+
+Theoretically, it isn't even guaranteed that the extra memory exists
+and can be sent out, which could cause further problems. In practice,
+I found that plenty of tailroom exists in the skb itself (in my test
+with ping at least) and skb_padto() easily succeeds, so use it here.
+
+In the event of -ENOMEM drop the frame like other drivers do.
+
+The use of one more padding byte instead of a USB zero-length packet
+is retained to avoid regression. I have a dodgy Etron xHCI controller
+which doesn't seem to support sending ZLPs at all.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable@vger.kernel.org
+Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20251014203528.3f9783c4.michal.pecio@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/usb/rtl8150.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/usb/rtl8150.c
++++ b/drivers/net/usb/rtl8150.c
+@@ -685,9 +685,16 @@ static netdev_tx_t rtl8150_start_xmit(st
+ rtl8150_t *dev = netdev_priv(netdev);
+ int count, res;
+
++ /* pad the frame and ensure terminating USB packet, datasheet 9.2.3 */
++ count = max(skb->len, ETH_ZLEN);
++ if (count % 64 == 0)
++ count++;
++ if (skb_padto(skb, count)) {
++ netdev->stats.tx_dropped++;
++ return NETDEV_TX_OK;
++ }
++
+ netif_stop_queue(netdev);
+- count = (skb->len < 60) ? 60 : skb->len;
+- count = (count & 0x3f) ? count : count + 1;
+ dev->tx_skb = skb;
+ usb_fill_bulk_urb(dev->tx_urb, dev->udev, usb_sndbulkpipe(dev->udev, 2),
+ skb->data, count, write_bulk_callback, dev);
--- /dev/null
+From 78a63493f8e352296dbc7cb7b3f4973105e8679e Mon Sep 17 00:00:00 2001
+From: Deepanshu Kartikey <kartikey406@gmail.com>
+Date: Thu, 9 Oct 2025 21:19:03 +0530
+Subject: ocfs2: clear extent cache after moving/defragmenting extents
+
+From: Deepanshu Kartikey <kartikey406@gmail.com>
+
+commit 78a63493f8e352296dbc7cb7b3f4973105e8679e upstream.
+
+The extent map cache can become stale when extents are moved or
+defragmented, causing subsequent operations to see outdated extent flags.
+This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().
+
+The problem occurs when:
+1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED
+2. ioctl(FITRIM) triggers ocfs2_move_extents()
+3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)
+4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent()
+ which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)
+5. The extent map cache is not invalidated after the move
+6. Later write() operations read stale cached flags (0x2) but disk has
+ updated flags (0x0), causing a mismatch
+7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggers
+
+Fix by clearing the extent map cache after each extent move/defrag
+operation in __ocfs2_move_extents_range(). This ensures subsequent
+operations read fresh extent data from disk.
+
+Link: https://lore.kernel.org/all/20251009142917.517229-1-kartikey406@gmail.com/T/
+Link: https://lkml.kernel.org/r/20251009154903.522339-1-kartikey406@gmail.com
+Fixes: 53069d4e7695 ("Ocfs2/move_extents: move/defrag extents within a certain range.")
+Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
+Reported-by: syzbot+6fdd8fa3380730a4b22c@syzkaller.appspotmail.com
+Tested-by: syzbot+6fdd8fa3380730a4b22c@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?id=2959889e1f6e216585ce522f7e8bc002b46ad9e7
+Reviewed-by: Mark Fasheh <mark@fasheh.com>
+Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Changwei Ge <gechangwei@live.cn>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ocfs2/move_extents.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/fs/ocfs2/move_extents.c
++++ b/fs/ocfs2/move_extents.c
+@@ -868,6 +868,11 @@ static int __ocfs2_move_extents_range(st
+ mlog_errno(ret);
+ goto out;
+ }
++ /*
++ * Invalidate extent cache after moving/defragging to prevent
++ * stale cached data with outdated extent flags.
++ */
++ ocfs2_extent_map_trunc(inode, cpos);
+
+ context->clusters_moved += alloc_size;
+ next:
--- /dev/null
+From 10fad4012234a7dea621ae17c0c9486824f645a0 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Sat, 18 Oct 2025 14:27:15 +0200
+Subject: Revert "cpuidle: menu: Avoid discarding useful information"
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit 10fad4012234a7dea621ae17c0c9486824f645a0 upstream.
+
+It is reported that commit 85975daeaa4d ("cpuidle: menu: Avoid discarding
+useful information") led to a performance regression on Intel Jasper Lake
+systems because it reduced the time spent by CPUs in idle state C7 which
+is correlated to the maximum frequency the CPUs can get to because of an
+average running power limit [1].
+
+Before that commit, get_typical_interval() would have returned UINT_MAX
+whenever it had been unable to make a high-confidence prediction which
+had led to selecting the deepest available idle state too often and
+both power and performance had been inadequate as a result of that on
+some systems. However, this had not been a problem on systems with
+relatively aggressive average running power limits, like the Jasper Lake
+systems in question, because on those systems it was compensated by the
+ability to run CPUs faster.
+
+It was addressed by causing get_typical_interval() to return a number
+based on the recent idle duration information available to it even if it
+could not make a high-confidence prediction, but that clearly did not
+take the possible correlation between idle power and available CPU
+capacity into account.
+
+For this reason, revert most of the changes made by commit 85975daeaa4d,
+except for one cosmetic cleanup, and add a comment explaining the
+rationale for returning UINT_MAX from get_typical_interval() when it
+is unable to make a high-confidence prediction.
+
+Fixes: 85975daeaa4d ("cpuidle: menu: Avoid discarding useful information")
+Closes: https://lore.kernel.org/linux-pm/36iykr223vmcfsoysexug6s274nq2oimcu55ybn6ww4il3g3cv@cohflgdbpnq7/ [1]
+Reported-by: Sergey Senozhatsky <senozhatsky@chromium.org>
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Link: https://patch.msgid.link/3663603.iIbC2pHGDl@rafael.j.wysocki
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpuidle/governors/menu.c | 21 +++++++++------------
+ 1 file changed, 9 insertions(+), 12 deletions(-)
+
+--- a/drivers/cpuidle/governors/menu.c
++++ b/drivers/cpuidle/governors/menu.c
+@@ -256,20 +256,17 @@ again:
+ *
+ * This can deal with workloads that have long pauses interspersed
+ * with sporadic activity with a bunch of short pauses.
++ *
++ * However, if the number of remaining samples is too small to exclude
++ * any more outliers, allow the deepest available idle state to be
++ * selected because there are systems where the time spent by CPUs in
++ * deep idle states is correlated to the maximum frequency the CPUs
++ * can get to. On those systems, shallow idle states should be avoided
++ * unless there is a clear indication that the given CPU is most likley
++ * going to be woken up shortly.
+ */
+- if (divisor * 4 <= INTERVALS * 3) {
+- /*
+- * If there are sufficiently many data points still under
+- * consideration after the outliers have been eliminated,
+- * returning without a prediction would be a mistake because it
+- * is likely that the next interval will not exceed the current
+- * maximum, so return the latter in that case.
+- */
+- if (divisor >= INTERVALS / 2)
+- return max;
+-
++ if (divisor * 4 <= INTERVALS * 3)
+ return UINT_MAX;
+- }
+
+ thresh = max - 1;
+ goto again;
dpaa2-eth-fix-the-pointer-passed-to-ptr_align-on-tx-.patch
arm64-mm-avoid-always-making-pte-dirty-in-pte_mkwrit.patch
sctp-avoid-null-dereference-when-chunk-data-buffer-i.patch
+net-bonding-fix-possible-peer-notify-event-loss-or-dup-issue.patch
+revert-cpuidle-menu-avoid-discarding-useful-information.patch
+mips-malta-fix-keyboard-resource-preventing-i8042-driver-from-registering.patch
+ocfs2-clear-extent-cache-after-moving-defragmenting-extents.patch
+vsock-fix-lock-inversion-in-vsock_assign_transport.patch
+net-usb-rtl8150-fix-frame-padding.patch
+net-ravb-ensure-memory-write-completes-before-ringing-tx-doorbell.patch
--- /dev/null
+From f7c877e7535260cc7a21484c994e8ce7e8cb6780 Mon Sep 17 00:00:00 2001
+From: Stefano Garzarella <sgarzare@redhat.com>
+Date: Tue, 21 Oct 2025 14:17:18 +0200
+Subject: vsock: fix lock inversion in vsock_assign_transport()
+
+From: Stefano Garzarella <sgarzare@redhat.com>
+
+commit f7c877e7535260cc7a21484c994e8ce7e8cb6780 upstream.
+
+Syzbot reported a potential lock inversion deadlock between
+vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.
+
+The issue was introduced by commit 687aa0c5581b ("vsock: Fix
+transport_* TOCTOU") which added vsock_register_mutex locking in
+vsock_assign_transport() around the transport->release() call, that can
+call vsock_linger(). vsock_assign_transport() can be called with sk_lock
+held. vsock_linger() calls sk_wait_event() that temporarily releases and
+re-acquires sk_lock. During this window, if another thread hold
+vsock_register_mutex while trying to acquire sk_lock, a circular
+dependency is created.
+
+Fix this by releasing vsock_register_mutex before calling
+transport->release() and vsock_deassign_transport(). This is safe
+because we don't need to hold vsock_register_mutex while releasing the
+old transport, and we ensure the new transport won't disappear by
+obtaining a module reference first via try_module_get().
+
+Reported-by: syzbot+10e35716f8e4929681fa@syzkaller.appspotmail.com
+Tested-by: syzbot+10e35716f8e4929681fa@syzkaller.appspotmail.com
+Fixes: 687aa0c5581b ("vsock: Fix transport_* TOCTOU")
+Cc: mhal@rbox.co
+Cc: stable@vger.kernel.org
+Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
+Link: https://patch.msgid.link/20251021121718.137668-1-sgarzare@redhat.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/vmw_vsock/af_vsock.c | 38 +++++++++++++++++++-------------------
+ 1 file changed, 19 insertions(+), 19 deletions(-)
+
+--- a/net/vmw_vsock/af_vsock.c
++++ b/net/vmw_vsock/af_vsock.c
+@@ -480,12 +480,26 @@ int vsock_assign_transport(struct vsock_
+ goto err;
+ }
+
+- if (vsk->transport) {
+- if (vsk->transport == new_transport) {
+- ret = 0;
+- goto err;
+- }
++ if (vsk->transport && vsk->transport == new_transport) {
++ ret = 0;
++ goto err;
++ }
++
++ /* We increase the module refcnt to prevent the transport unloading
++ * while there are open sockets assigned to it.
++ */
++ if (!new_transport || !try_module_get(new_transport->module)) {
++ ret = -ENODEV;
++ goto err;
++ }
++
++ /* It's safe to release the mutex after a successful try_module_get().
++ * Whichever transport `new_transport` points at, it won't go away until
++ * the last module_put() below or in vsock_deassign_transport().
++ */
++ mutex_unlock(&vsock_register_mutex);
+
++ if (vsk->transport) {
+ /* transport->release() must be called with sock lock acquired.
+ * This path can only be taken during vsock_connect(), where we
+ * have already held the sock lock. In the other cases, this
+@@ -505,20 +519,6 @@ int vsock_assign_transport(struct vsock_
+ vsk->peer_shutdown = 0;
+ }
+
+- /* We increase the module refcnt to prevent the transport unloading
+- * while there are open sockets assigned to it.
+- */
+- if (!new_transport || !try_module_get(new_transport->module)) {
+- ret = -ENODEV;
+- goto err;
+- }
+-
+- /* It's safe to release the mutex after a successful try_module_get().
+- * Whichever transport `new_transport` points at, it won't go away until
+- * the last module_put() below or in vsock_deassign_transport().
+- */
+- mutex_unlock(&vsock_register_mutex);
+-
+ if (sk->sk_type == SOCK_SEQPACKET) {
+ if (!new_transport->seqpacket_allow ||
+ !new_transport->seqpacket_allow(remote_cid)) {
projects / thirdparty / kernel / stable-queue.git / commitdiff
