From nobody Fri Apr 3 08:25:00 2026 Received: from va-1-111.ptr.blmpb.com (va-1-111.ptr.blmpb.com [209.127.230.111]) (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 8C10D3BF680 for ; Tue, 31 Mar 2026 11:32:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.230.111 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774956760; cv=none; b=hvKqc/N3JeljP1WsfeVfRevVj/kGo/eMebGhoV0LxCN6eEXQcQADrXQ2Z00kPKyu4hQe6Ly3DJMNyhmCL1vnWZQTVOFZtsl7IM4CM8T4IfprAn36/AI+psiWnZcQJ/ILhLXw+tZss7w8JMVmHV03f/78D+lLHrfvK5oslCw25Xs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774956760; c=relaxed/simple; bh=pdq0IJ9ol3YXfuwtoTfM1eCh4RF5Wdt2TD5XtAvjhmw=; h=From:In-Reply-To:Subject:Date:Message-Id:To:Cc:Mime-Version: References:Content-Type; b=XO2jcN5lQLnXwY6LXZTwJVcORB3fHP3L+nypXOIimpn3koG5i4DR76kTDqWMZ6fZCZVVLEnVgbZgr518MVF7/BZWc4qLo1ZDecytUy/Iq7M/QvehEhvqYys2cUSsr7EdpDhWiLJpx4Vp5ZVlHSZc90LhMPcDUficEdkQuk9KOm8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=oxGY3aSV; arc=none smtp.client-ip=209.127.230.111 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="oxGY3aSV" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1774956754; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=GPWBH8CkBbclLXy0JLLOWAAPp3nPoBMoyH4dd3fN0Jc=; b=oxGY3aSViHgIhkFQhmIUYKUfb0XuQN4lv+7cH+hlbZyZ3u03JgrLE3ctpzGVquvf3vfesR jgoQ872+dBdOGQeve/Yl6hF8P7qTJkp/EKy7TTBLMjffdMqsFfgBPtKdVDxJ1iU/CkiqzC w+QhoKfdCnpXxpfWYUR73KbufyZURVUZPEgqnPVwEchBW7wWAG7RKQGRgK4IwqdlKVojzL JbN0r66eJ3fWXBPMdxDtgH5G1adm9E9iWHdWh/n8I95NqBpiWHv296gzMJZ2TjzUDoJ+Kb OSPfgTIhzMIIn5IFXPpF+X6txX6XVQEXuUoNR11hKsBpa8r21f3nofoHBIcv8g== From: "Chuyi Zhou" In-Reply-To: <20260331113103.2197007-1-zhouchuyi@bytedance.com> X-Original-From: Chuyi Zhou Subject: [PATCH v4 05/12] smp: Alloc percpu csd data in smpcfd_prepare_cpu() only once Date: Tue, 31 Mar 2026 19:30:56 +0800 X-Lms-Return-Path: X-Mailer: git-send-email 2.20.1 Message-Id: <20260331113103.2197007-6-zhouchuyi@bytedance.com> To: , , , , , , , , , , , , Cc: , "Chuyi Zhou" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260331113103.2197007-1-zhouchuyi@bytedance.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Later patch would enable preemption during csd_lock_wait() in smp_call_function_many_cond(), which may cause access cfd->csd data that has already been freed in smpcfd_dead_cpu(). One way to fix the above issue is to use the RCU mechanism to protect the csd data and wait for all read critical sections to exit before freeing the memory in smpcfd_dead_cpu(), but this could delay CPU shutdown. This patch chooses a simpler approach: allocate the percpu csd on the UP side only once and skip freeing the csd memory in smpcfd_dead_cpu(). Suggested-by: Sebastian Andrzej Siewior Signed-off-by: Chuyi Zhou --- kernel/smp.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/kernel/smp.c b/kernel/smp.c index 446e3f80007e..2a33877dd812 100644 --- a/kernel/smp.c +++ b/kernel/smp.c @@ -63,7 +63,15 @@ int smpcfd_prepare_cpu(unsigned int cpu) free_cpumask_var(cfd->cpumask); return -ENOMEM; } - cfd->csd =3D alloc_percpu(call_single_data_t); + + /* + * The percpu csd is allocated only once and never freed. + * This ensures that smp_call_function_many_cond() can safely + * access the csd of an offlined CPU if it gets preempted + * during csd_lock_wait(). + */ + if (!cfd->csd) + cfd->csd =3D alloc_percpu(call_single_data_t); if (!cfd->csd) { free_cpumask_var(cfd->cpumask); free_cpumask_var(cfd->cpumask_ipi); @@ -79,7 +87,6 @@ int smpcfd_dead_cpu(unsigned int cpu) =20 free_cpumask_var(cfd->cpumask); free_cpumask_var(cfd->cpumask_ipi); - free_percpu(cfd->csd); return 0; } =20 --=20 2.20.1