From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from va-1-112.ptr.blmpb.com (va-1-112.ptr.blmpb.com [209.127.230.112]) (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 291853451A9 for ; Thu, 9 Apr 2026 03:49:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.230.112 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775706597; cv=none; b=Z7/c/S4EFLA9kj0/kHJB6J2UbWU7+6KxZG7i/GFTUVsWppaj+ISWoj7hYXOzEYGcE5OjVudsBE+z0A87v6fNSsyBfvLLaw+IxnvaqD1KvtHb4jk6q7O7InAfW1IgwfsnH46TB5EFIzHuRFbZJD3PKaFiuFDI54oXxEIxoOohCNg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775706597; c=relaxed/simple; bh=g4c5QoY9wFyrpaHC0dMNX8K4hGAT9a8Mmq4YmC2BZNM=; h=To:Date:Message-Id:Mime-Version:References:Cc:From:Subject: Content-Type:In-Reply-To; b=CbwHimV5nVUlVqsaShpvhaM9YHiTFHBrJw8g04J9CjZIBrCgDD5vMrYMFebhHf+TeaO4rIZsB61vDbj1gWFHxVzrjK6L0l/gwjZkuzuRsJRKl+Ca1fAWCGkJ54epv5NPa8Obx3Za8HuCg4RE6IIyl1oOiNSX6Wkcu1/VzGNrNdE= 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=LFvu68GT; arc=none smtp.client-ip=209.127.230.112 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="LFvu68GT" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1775706584; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=CiOinApjr1j2L1fDnmqhfMFjSAK87PeFgFsVdZU5/Wg=; b=LFvu68GTOb0dB2yM+2XaQWibu818swMEv9cLquDUFKt/pEBEaML4hRETWu1qDtSmHR0zUh u6hdj7krddcmMUa4lRovlMDXdo10xOuXgT5zEFUOPk7/vu/yY5pcBLQezJ5ziu6iD070U4 P0qQqlOZDSkJEoisKdXyRQm+UdEqptbde/+AaDkGfpxpcXTBwJl+MpNUXOg6woX5QA1XzL ay5kyI3+VnKolePEoL77l5S3XMT8AdBsiaqU6Z9iZjKjNvsfWzEgXEWrMXRTq4KDTch4Ew oxUlFlXsA3NSL81b11wytAQZlEmLKd3/+n+jHVH8OuuvMGJMaVorISoE6xbUyg== To: , , , , , , , , , , , , Date: Thu, 9 Apr 2026 11:48:19 +0800 Message-Id: <88a1be12-d16e-45cc-adb1-690423b08793@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 User-Agent: Mozilla Thunderbird References: <20260331113103.2197007-1-zhouchuyi@bytedance.com> <20260331113103.2197007-4-zhouchuyi@bytedance.com> X-Lms-Return-Path: Cc: X-Original-From: Chuyi Zhou From: "Chuyi Zhou" Subject: Re: [PATCH v4 03/12] smp: Remove get_cpu from smp_call_function_any Content-Type: text/plain; charset=UTF-8 In-Reply-To: <20260331113103.2197007-4-zhouchuyi@bytedance.com> Content-Transfer-Encoding: 7bit On 2026-03-31 7:30 p.m., Chuyi Zhou wrote: > Now smp_call_function_single() would enable preemption before > csd_lock_wait() to reduce the critical section. To allow callers of > smp_call_function_any() to also benefit from this optimization, remove > get_cpu()/put_cpu() from smp_call_function_any(). > > Signed-off-by: Chuyi Zhou > Reviewed-by: Muchun Song > --- > kernel/smp.c | 16 +++++++++++++--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > diff --git a/kernel/smp.c b/kernel/smp.c > index b603d4229f95..80daf9dd4a25 100644 > --- a/kernel/smp.c > +++ b/kernel/smp.c > @@ -761,16 +761,26 @@ EXPORT_SYMBOL_GPL(smp_call_function_single_async); > int smp_call_function_any(const struct cpumask *mask, > smp_call_func_t func, void *info, int wait) > { > + bool local = true; > unsigned int cpu; > int ret; > > - /* Try for same CPU (cheapest) */ > + /* > + * Prevent migration to another CPU after selecting the current CPU > + * as the target. > + */ > cpu = get_cpu(); > - if (!cpumask_test_cpu(cpu, mask)) > + > + /* Try for same CPU (cheapest) */ > + if (!cpumask_test_cpu(cpu, mask)) { > cpu = sched_numa_find_nth_cpu(mask, 0, cpu_to_node(cpu)); > + local = false; > + put_cpu(); > + } > From sashiko[1]: ' By calling put_cpu() before smp_call_function_single() for remote CPUs, does this open a preemption window where the selected remote CPU could be fully offlined before the IPI is dispatched? If the selected CPU goes offline in this window, smp_call_function_single() will fail the cpu_online() check and return -ENXIO. Because this function does not retry with another CPU from the mask, it propagates -ENXIO directly to the caller even if other valid online CPUs remain in the mask. Could this cause spurious failures for callers in preemptible contexts that do not hold CPU hotplug locks, violating the guarantee to run on any online CPU in the mask? ' This causes smp_call_function_any() to return -ENXIO immediately, rather than returning -ENXIO only when all CPUs are offline. One way to fix this is to refactor the logic of smp_call_function_any() and smp_call_function_single(), moving the target CPU selection logic into smp_call_function_single() and keeping preemption disabled until the IPI is sent out. Another approach is to retry sched_numa_find_nth_cpu() once smp_call_function_single() returns -ENXIO, until sched_numa_find_nth_cpu() returns nr_cpu_ids. Do you have any better suggestions? Thanks. [1] https://sashiko.dev/#/patchset/20260331113103.2197007-1-zhouchuyi%40bytedance.com > ret = smp_call_function_single(cpu, func, info, wait); > - put_cpu(); > + if (local) > + put_cpu(); > return ret; > } > EXPORT_SYMBOL_GPL(smp_call_function_any);