From nobody Mon Jun 15 13:42:20 2026 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1231F3A5E64 for ; Fri, 10 Apr 2026 14:07:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775830065; cv=none; b=DHlk2nNMlSRKWMLl99G5Eo6iG4whwmc5cGrPORWyr3Q6TIwrm41oVy+yewQsmjyy/+mRS6L6oTtJsD9+47OI6ZgIfErB5RDuyWRwkS6GCe9QYlALroM/9tRqzq9K2BOrNRrfJxy75PedViySwcz4ekY13PvB9TXm0sXORO2j4bk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775830065; c=relaxed/simple; bh=hOxm7SjlpbqBrEEDguYsG+OkjxtRvM2/8AInbZBt79Q=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=JBApC3NxxPYYyO/qO6mCHASjA0aVCN727D2g/2ABfYOs1TbQCxbZUMQ0ojsAi6i0E+QDXIc+l/riiCzM8zvS/48y0F1R1IB9ls3LrvmMYu5IfIIlwzMsZ8HMC4iQdDMHe5317O2mwWOncW345ju8RLWrJgOjEnIfrXG5y40cXpA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Ov0qzb/o; arc=none smtp.client-ip=209.85.221.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Ov0qzb/o" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-43b8ebe6bd1so112977f8f.2 for ; Fri, 10 Apr 2026 07:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775830062; x=1776434862; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=qyzPpXAXSz138DHYR7mZI4kKk1VA1xvVpWE+tBCFF8M=; b=Ov0qzb/oKp48mDdjoRGkZv6L+RMdac2BAjVx/5FngAJcY0/R22AbqTL/HywJc0i0BN HYSNJXPVxbgPrvBldNh/aZARN7dUHdxpqpt1WFXJjAgTSdivgSnkcIDRceAY385kyUjj kDn9tYRllsvZTkyFwvSuBqYcDYuLXHswCLPsjvw/OAs3XH/aVzPpgChVl/WipGn62WcL xJIIFgbZlgFY50cXn/D9jYcuaZqwaGvIOjW8hhtxZYt7LiB+iEqjeXmcnm8hMxgYyXLG 3iN7PaV5H9RiknGe8ENW3U7VRBZYWCiDeX7MbWbss7VlA+LkVripRCuSqcamGaRU7BBw EpcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775830062; x=1776434862; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qyzPpXAXSz138DHYR7mZI4kKk1VA1xvVpWE+tBCFF8M=; b=UgmVy10MlnS3Y/sl6pHe6IMhJJXHzA5qoaI0PJzbz6XMYKRtoQZIm/B8dsQZmOJYaN FCvzdQXv0eHI3xBuYsPZSbw7QZY31XraAsI3168DOmDEtMb8AmEJxF1LYicRu4whBXnD QDfJqy8ep68nat1AIDIrYjvAEywgIRECKg65a0WjiMWrJS4jFZEAWofReDgN6OnT4aG1 TdsFcdcEYGv9uFkyFc9fhZfF/1OGZweY/DIgVXX+dwRE0/+nVipdmORCmZ3kEdxZsgmt 0QI9Fvvs7WxYx+E8ixOkyMKe5IQvngRVSzRqSaZJbJvKRr3/KrCzE9igV45EZ8HsD52a uQEg== X-Gm-Message-State: AOJu0YyfFKvDuMKx0ZEhVWqs3Xg35CQdWjR+lGAAwAOr012T+F+aQZzX AVwFOYQvNsj5nG8S9IaR8SaWgxwsxv/ws5EXw9qtQDdUEURchh/MkgHP X-Gm-Gg: AeBDiesVLUHl0HU+ROFlb0Vxkook2d2YJq5yDr0tJdtia28YQiO3PgmEEhdPzi7VN9W AKF9y2u8S+Et42WppodJAMZ+DkewVeFRBAR+EHWJQGb4jT7O4voaqWeKhUldKrxroB0vrRRMNRX nRZB28KlYusRwKbiNCkMxRDcdGkSTr9bQDZQlWuHySFPqPOG3Y46x66cUT2e5Gi/QOK0ZY3Vbyp 6uPD9kXgy2p69EcpZJ7Uppzw3g1W/Im+U9/JYatugHb9UZMFc3yodEFk+y4WwovWaEI+AtD5erB kQRmMWf+13lDxk1EnKszh4XezT+snKfvRlScSYvVgPBOkZyWtjC9OJaey1qsdatHHJSyJVsfF7M WHQcV72OguhCXy3LgyTWgweviS2jIBFhMadrQwnV/4OPgCpR2s3FMhOmv1zvLe71I/3EA8WDzY1 Y7ND37hIEvZwHDawFe2DkJnEdDw6N9Z4/obRaHKGaKyPaELwWbFRi0A3roH3ctBm6+BdFKAfdQ4 mqkC04= X-Received: by 2002:a05:600c:1f83:b0:488:a9e4:35be with SMTP id 5b1f17b1804b1-488d687c0f9mr24225825e9.5.1775830062231; Fri, 10 Apr 2026 07:07:42 -0700 (PDT) Received: from ast-epyc5.inf.ethz.ch (ast-epyc4.inf.ethz.ch. [129.132.161.179]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488d67b4a46sm47409655e9.4.2026.04.10.07.07.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Apr 2026 07:07:41 -0700 (PDT) From: Zijing Yin To: bpf@vger.kernel.org Cc: linux-kernel@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev, john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com, jolsa@kernel.org, Zijing Yin Subject: [PATCH bpf-next] bpf: reuseport: add cond_resched_rcu() in reuseport_array_free() Date: Fri, 10 Apr 2026 07:07:25 -0700 Message-ID: <20260410140725.961623-1-yzjaurora@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" reuseport_array_free() iterates over all map entries inside rcu_read_lock() to detach sockets from the array. When max_entries is very large (e.g., hundreds of millions), this loop runs for an extended period without yielding the CPU, triggering RCU stall warnings in the kworker thread that executes bpf_map_free_deferred(). The observed stall occurs because the loop has no scheduling point: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: Workqueue: events_unbound bpf_map_free_deferred Call Trace: reuseport_array_free+0x1ec/0x470 kernel/bpf/reuseport_array.c:127 bpf_map_free_deferred+0x34a/0x7e0 kernel/bpf/syscall.c:893 process_one_work+0x952/0x1a80 worker_thread+0x87b/0x11f0 Add cond_resched_rcu() in the loop body to allow the scheduler to run and RCU grace periods to complete. This is safe because each iteration processes a single entry independently, sk->sk_callback_lock is not held across the yield point, and the map is fully detached from userspace so no concurrent insertions can occur. This follows an established pattern for long-running kernel loops that must run under rcu_read_lock(). The closest precedent is in another BPF map free function: kernel/bpf/hashtab.c:1600 htab_free_malloced_internal_structs() rcu_read_lock(); for (i =3D 0; i < htab->n_buckets; i++) { ... walk bucket ... cond_resched_rcu(); } rcu_read_unlock(); Fixes: 5dc4c4b7d4e8 ("bpf: Introduce BPF_MAP_TYPE_REUSEPORT_SOCKARRAY") Signed-off-by: Zijing Yin --- Base: bpf-next.git master branch (tip a0c584fc18056709c8e047a82a6045d6c209f4ce "bpf: Fix use-after-free in offloaded map/prog info fill" as of 2026-04-09). Tested with CONFIG_PREEMPT_RCU=3Dy, CONFIG_KASAN=3Dy (inline), CONFIG_SMP=3Dn (single vCPU QEMU VM), gcc 13.3.0. To reproduce: create a BPF_MAP_TYPE_REUSEPORT_SOCKARRAY with max_entries >=3D 100M, set rcu_cpu_stall_timeout low, pin the CPU with a SCHED_FIFO thread so the kworker stays in rcu_read_lock() long enough to trip the stall timeout, then close the fd. Without the fix the reuseport_array_free() kworker stalls RCU reliably; with the fix, cond_resched_rcu() yields periodically and no stall is observed. Reproducer (C source): repro_reuseport.c (https://pastebin.com/YjdwqdX1) kernel/bpf/reuseport_array.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/bpf/reuseport_array.c b/kernel/bpf/reuseport_array.c index 49b8e5a0c6b4f..e3c789b80e2b8 100644 --- a/kernel/bpf/reuseport_array.c +++ b/kernel/bpf/reuseport_array.c @@ -5,6 +5,7 @@ #include #include #include +#include #include #include @@ -136,6 +137,7 @@ static void reuseport_array_free(struct bpf_map *map) write_unlock_bh(&sk->sk_callback_lock); RCU_INIT_POINTER(array->ptrs[i], NULL); } + cond_resched_rcu(); } rcu_read_unlock(); --=20 2.43.0