--- /dev/null
+From 5f41161059fd0f1bbf18c90f3180e38cc45a14eb Mon Sep 17 00:00:00 2001
+From: Helen Koike <koike@igalia.com>
+Date: Mon, 11 May 2026 18:53:05 -0300
+Subject: debugobjects: Do not fill_pool() if pi_blocked_on
+
+From: Helen Koike <koike@igalia.com>
+
+commit 5f41161059fd0f1bbf18c90f3180e38cc45a14eb upstream.
+
+On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which
+asserts if current::pi_blocked_on is set, because a task can obviously only
+block on one lock as otherwise the priority inheritenace chain gets
+corrupted.
+
+Prevent this by expanding the conditional to take current::pi_blocked_on
+into account.
+
+Fixes: 4bedcc28469a ("debugobjects: Make them PREEMPT_RT aware")
+Reported-by: syzbot+b8ca586b9fc235f0c0df@syzkaller.appspotmail.com
+Signed-off-by: Helen Koike <koike@igalia.com>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Link: https://patch.msgid.link/20260511215359.3351259-1-koike@igalia.com
+Closes: https://syzkaller.appspot.com/bug?extid=b8ca586b9fc235f0c0df
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ lib/debugobjects.c | 18 ++++++++++++++----
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+--- a/lib/debugobjects.c
++++ b/lib/debugobjects.c
+@@ -711,6 +711,15 @@ static struct debug_obj *lookup_object_o
+ return NULL;
+ }
+
++static inline bool debug_objects_is_pi_blocked_on(void)
++{
++#ifdef CONFIG_RT_MUTEXES
++ return current->pi_blocked_on != NULL;
++#else
++ return false;
++#endif
++}
++
+ static void debug_objects_fill_pool(void)
+ {
+ if (!static_branch_likely(&obj_cache_enabled))
+@@ -727,11 +736,12 @@ static void debug_objects_fill_pool(void
+
+ /*
+ * On RT enabled kernels the pool refill must happen in preemptible
+- * context -- for !RT kernels we rely on the fact that spinlock_t and
+- * raw_spinlock_t are basically the same type and this lock-type
+- * inversion works just fine.
++ * context and not enqueued on an rt_mutex -- for !RT kernels we rely
++ * on the fact that spinlock_t and raw_spinlock_t are basically the
++ * same type and this lock-type inversion works just fine.
+ */
+- if (!IS_ENABLED(CONFIG_PREEMPT_RT) || preemptible() || system_state < SYSTEM_SCHEDULING) {
++ if (!IS_ENABLED(CONFIG_PREEMPT_RT) || system_state < SYSTEM_SCHEDULING ||
++ (preemptible() && !debug_objects_is_pi_blocked_on())) {
+ /*
+ * Annotate away the spinlock_t inside raw_spinlock_t warning
+ * by temporarily raising the wait-type to LD_WAIT_CONFIG, matching
--- /dev/null
+From 0d046ae106255cba5eb83b23f78ee93f3620247d Mon Sep 17 00:00:00 2001
+From: Waiman Long <longman@redhat.com>
+Date: Fri, 5 Jun 2026 13:30:38 -0400
+Subject: debugobjects: Don't call fill_pool() in early boot hardirq context
+
+From: Waiman Long <longman@redhat.com>
+
+commit 0d046ae106255cba5eb83b23f78ee93f3620247d upstream.
+
+When booting a debug PREEMPT_RT kernel on an ARM64 system, a "inconsistent
+{HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage" lockdep warning message was
+reported to the console.
+
+During early boot, interrupts are enabled before the scheduler is
+enabled. In this window (before SYSTEM_SCHEDULING is set) interrupts can
+fire and in the hard interrupt context handler attempt to fill the pool
+
+This can lead to a deadlock when the interrupt occurred when the interrupt
+hits a region which holds a lock that is required to be taken in the
+allocation path.
+
+Add a new can_fill_pool() helper and reorder the exception rule and forbid
+this scenario by excluding allocations from hard interrupt context.
+
+Fixes: 06e0ae988f6e ("debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING")
+Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Suggested-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260605173038.495075-1-longman@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ lib/debugobjects.c | 46 +++++++++++++++++++++++++++++++++++++---------
+ 1 file changed, 37 insertions(+), 9 deletions(-)
+
+--- a/lib/debugobjects.c
++++ b/lib/debugobjects.c
+@@ -720,6 +720,41 @@ static inline bool debug_objects_is_pi_b
+ #endif
+ }
+
++static inline bool can_fill_pool(void)
++{
++ /*
++ * On !RT enabled kernels there are no restrictions and spinlock_t and
++ * raw_spinlock_t are the same types.
++ */
++ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
++ return true;
++
++ /*
++ * On RT enabled kernels, the task must not be blocked on a lock as
++ * that could corrupt the PI state when blocking on a lock in the
++ * allocation path.
++ */
++ if (debug_objects_is_pi_blocked_on())
++ return false;
++
++ /*
++ * On RT enabled kernels the pool refill should happen in preemptible
++ * context.
++ */
++ if (preemptible())
++ return true;
++
++ /*
++ * Though during system boot before scheduling is set up, preemption is
++ * disabled and the pool can get exhausted. Before scheduling is active
++ * a task cannot be blocked on a sleeping lock, but it might hold a lock
++ * and if interrupted then hard interrupt context might run into a lock
++ * inversion. So exclude hard interrupt context from allocations before
++ * scheduling is active.
++ */
++ return system_state < SYSTEM_SCHEDULING && !in_hardirq();
++}
++
+ static void debug_objects_fill_pool(void)
+ {
+ if (!static_branch_likely(&obj_cache_enabled))
+@@ -734,18 +769,11 @@ static void debug_objects_fill_pool(void
+ if (likely(!pool_should_refill(&pool_global)))
+ return;
+
+- /*
+- * On RT enabled kernels the pool refill must happen in preemptible
+- * context and not enqueued on an rt_mutex -- for !RT kernels we rely
+- * on the fact that spinlock_t and raw_spinlock_t are basically the
+- * same type and this lock-type inversion works just fine.
+- */
+- if (!IS_ENABLED(CONFIG_PREEMPT_RT) || system_state < SYSTEM_SCHEDULING ||
+- (preemptible() && !debug_objects_is_pi_blocked_on())) {
++ if (can_fill_pool()) {
+ /*
+ * Annotate away the spinlock_t inside raw_spinlock_t warning
+ * by temporarily raising the wait-type to LD_WAIT_CONFIG, matching
+- * the preemptible() condition above.
++ * the preemptible() condition in can_fill_pool().
+ */
+ static DEFINE_WAIT_OVERRIDE_MAP(fill_pool_map, LD_WAIT_CONFIG);
+ lock_map_acquire_try(&fill_pool_map);
rdma-umem-fix-kernel-doc-warnings.patch
rdma-move-dma-block-iterator-logic-into-dedicated-files.patch
rdma-umem-fix-truncation-for-block-sizes-4g.patch
+vsock-virtio-fix-potential-unbounded-skb-queue.patch
+vsock-virtio-fix-skb-overhead-accounting-to-preserve-full-buf_alloc.patch
+debugobjects-do-not-fill_pool-if-pi_blocked_on.patch
+debugobjects-don-t-call-fill_pool-in-early-boot-hardirq-context.patch
--- /dev/null
+From 059b7dbd20a6f0c539a45ddff1573cb8946685b5 Mon Sep 17 00:00:00 2001
+From: Eric Dumazet <edumazet@google.com>
+Date: Thu, 30 Apr 2026 12:26:52 +0000
+Subject: vsock/virtio: fix potential unbounded skb queue
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Eric Dumazet <edumazet@google.com>
+
+commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5 upstream.
+
+virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
+
+virtio_transport_recv_enqueue() skips coalescing for packets
+with VIRTIO_VSOCK_SEQ_EOM.
+
+If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
+a very large number of packets can be queued
+because vvs->rx_bytes stays at 0.
+
+Fix this by estimating the skb metadata size:
+
+ (Number of skbs in the queue) * SKB_TRUESIZE(0)
+
+Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
+Cc: Stefan Hajnoczi <stefanha@redhat.com>
+Cc: Stefano Garzarella <sgarzare@redhat.com>
+Cc: "Michael S. Tsirkin" <mst@redhat.com>
+Cc: Jason Wang <jasowang@redhat.com>
+Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
+Cc: "Eugenio Pérez" <eperezma@redhat.com>
+Cc: virtualization@lists.linux.dev
+Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/vmw_vsock/virtio_transport_common.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/net/vmw_vsock/virtio_transport_common.c
++++ b/net/vmw_vsock/virtio_transport_common.c
+@@ -425,7 +425,9 @@ static int virtio_transport_send_pkt_inf
+ static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
+ u32 len)
+ {
+- if (vvs->buf_used + len > vvs->buf_alloc)
++ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
++
++ if (skb_overhead + vvs->buf_used + len > vvs->buf_alloc)
+ return false;
+
+ vvs->rx_bytes += len;
--- /dev/null
+From c6087c5aaad6d1b8be1a1a641e0a422218ade911 Mon Sep 17 00:00:00 2001
+From: Stefano Garzarella <sgarzare@redhat.com>
+Date: Mon, 18 May 2026 11:06:56 +0200
+Subject: vsock/virtio: fix skb overhead accounting to preserve full buf_alloc
+
+From: Stefano Garzarella <sgarzare@redhat.com>
+
+commit c6087c5aaad6d1b8be1a1a641e0a422218ade911 upstream.
+
+After commit 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb
+queue"), virtio_transport_inc_rx_pkt() subtracts per-skb overhead from
+buf_alloc when checking whether a new packet fits. This reduces the
+effective receive buffer below what the user configured via
+SO_VM_SOCKETS_BUFFER_SIZE, causing legitimate data packets to be
+silently dropped and applications that rely on the full buffer size
+to deadlock.
+
+Also, the reduced space is not communicated to the remote peer, so
+its credit calculation accounts more credit than the receiver will
+actually accept, causing data loss (there is no retransmission).
+
+With this approach we currently have failures in
+tools/testing/vsock/vsock_test.c. Test 18 sometimes fails, while
+test 22 always fails in this way:
+ 18 - SOCK_STREAM MSG_ZEROCOPY...hash mismatch
+
+ 22 - SOCK_STREAM virtio credit update + SO_RCVLOWAT...send failed:
+ Resource temporarily unavailable
+
+Fix by allowing at most `buf_alloc * 2` as the total budget for payload
+plus skb overhead in virtio_transport_inc_rx_pkt(), similar to how
+SO_RCVBUF is doubled to reserve space for sk_buff metadata.
+This preserves the full buf_alloc for payload under normal operation,
+while still bounding the skb queue growth.
+
+With this patch, all tests in tools/testing/vsock/vsock_test.c are
+now passing again.
+
+Fixes: 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue")
+Cc: stable@vger.kernel.org
+Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
+Link: https://patch.msgid.link/20260518090656.134588-3-sgarzare@redhat.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/vmw_vsock/virtio_transport_common.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/net/vmw_vsock/virtio_transport_common.c
++++ b/net/vmw_vsock/virtio_transport_common.c
+@@ -427,7 +427,14 @@ static bool virtio_transport_inc_rx_pkt(
+ {
+ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
+
+- if (skb_overhead + vvs->buf_used + len > vvs->buf_alloc)
++ /* Allow at most buf_alloc * 2 total budget (payload + overhead),
++ * similar to how SO_RCVBUF is doubled to reserve space for sk_buff
++ * metadata. Check payload against buf_alloc to be sure the other
++ * peer is respecting the credit, and sk_buff overhead to bound
++ * queue growth.
++ */
++ if ((u64)vvs->buf_used + len > vvs->buf_alloc ||
++ skb_overhead > vvs->buf_alloc)
+ return false;
+
+ vvs->rx_bytes += len;
projects / thirdparty / kernel / stable-queue.git / commitdiff
