From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 52BC43CE493 for ; Wed, 18 Mar 2026 16:19:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773850777; cv=none; b=gZrSD72QFl81ubE9EJYawS+STbn9anGt/QMUP/MsUvUKIaEG0Qiv4CMKHe2JrDv+I65iBgp8jIh6HmTUO4J89ne9wxpAhFioZupIORC2liUY9Ue0ppT3rpkjWkrs46fbYTnmWXVdyRpBGIG269ksN8i7mrQ+MewUp5SJBTc/AsI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773850777; c=relaxed/simple; bh=Y7TvW8v+BRhASl3rWmEMfdArcLJsPAs6Y7KplhtUoV4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SfcO93VBPD+lq8eB49IVuS8DnJ97hoJBdQ4dIV91RCgYPQ0FQ5yOCsFPSVEziYXZnG0mraNSdMK3lCQRILqnJG/sREosKzc7hB3zGUIMLy4g8e9vaDo5whHuvKqmvnBDWe/IyZfBPMXHBkqTKJ9y26rGC/ZEBKNQWRnThWcK6Z4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=rmgoRfxZ; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=8OPuqm/t; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="rmgoRfxZ"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="8OPuqm/t" Date: Wed, 18 Mar 2026 17:19:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1773850769; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xB8aOlmBSKp3j/Vs2T7NXFO5kAHv3UFzm4RrtJz3fYg=; b=rmgoRfxZ0pSLwCS0A14JdiI1RKaU4jT33awAegIqpsot2V0kPj6CPos2e3RAQZ1cND6Nzs RYu6Wp+0kvwk4WqI0nAKEugeSXL3CGtXVmLk3R8IVSoAx4jyZEiwBODfIMhI02ml+F/BO1 CSzWlKaP8H+jDPJSxmO4WNvn77mDq61KJUFW74Oi2Vmvmrp7DvNH/9gAG6BCP+PCthPqJ4 p9WXv46zvc+f3q8/omwfw+ex9H9d7ObJasepSQJ+6EjGWf2X7wY2yfZb29YRL9Y2ePCnwE 29X2xwRDwhd0KkjnMEW/fAwArMaXZEGQBFkO35yjeAfm+z31n/WFQNCpQ+po9g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1773850769; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xB8aOlmBSKp3j/Vs2T7NXFO5kAHv3UFzm4RrtJz3fYg=; b=8OPuqm/trvrxHV1oFAcIxDcd1h+b/7fwg0TRzkvmhqG2mKKWOXuQII2NsTejm97hVQ/65r 4JYloaxPluBzZ8Ag== From: Sebastian Andrzej Siewior To: Chuyi Zhou Cc: tglx@linutronix.de, mingo@redhat.com, luto@kernel.org, peterz@infradead.org, paulmck@kernel.org, muchun.song@linux.dev, bp@alien8.de, dave.hansen@linux.intel.com, pbonzini@redhat.com, clrkwllms@kernel.org, rostedt@goodmis.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 05/12] smp: Free call_function_data via RCU in smpcfd_dead_cpu Message-ID: <20260318161928.jdoUolLo@linutronix.de> References: <20260318045638.1572777-1-zhouchuyi@bytedance.com> <20260318045638.1572777-6-zhouchuyi@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260318045638.1572777-6-zhouchuyi@bytedance.com> On 2026-03-18 12:56:31 [+0800], Chuyi Zhou wrote: > Use rcu_read_lock() to protect csd in smp_call_function_many_cond() and > wait for all read critical sections to exit before releasing percpu csd > data. This is preparation for enabling preemption during csd_lock_wait() > and can prevent accessing cfd->csd data that has already been freed in > smpcfd_dead_cpu(). > > Signed-off-by: Chuyi Zhou > --- > kernel/smp.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/kernel/smp.c b/kernel/smp.c > index 9728ba55944d..32c293d8be0e 100644 > --- a/kernel/smp.c > +++ b/kernel/smp.c > @@ -77,6 +77,7 @@ int smpcfd_dead_cpu(unsigned int cpu) > { > struct call_function_data *cfd = &per_cpu(cfd_data, cpu); > > + synchronize_rcu(); > free_cpumask_var(cfd->cpumask); > free_cpumask_var(cfd->cpumask_ipi); > free_percpu(cfd->csd); This seems to make sense. But it could delay CPU shutdown and then the stress-cpu-hotplug.sh. And this one helped to find bugs. What is expectation of shutting down a CPU? Will it remain off for _long_ at which point we care about this memory or is temporary and we could skip to free the memory here because we allocate it only once on the UP side? Sebastian