From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-1-102.ptr.blmpb.com (sg-1-102.ptr.blmpb.com [118.26.132.102]) (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 F145D1DF73C for ; Mon, 2 Mar 2026 07:54:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.26.132.102 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772438047; cv=none; b=Ce0btXrXSBGnlNCH8g9knOlT33k9SbCzy5L71nU+342oPE8kZXI6oWgzeumtfh6uRxyGVMlH5gL0cFvyWGFkHAU611K5V5Ff0QKCPnnZSija1bJRPjIbBV0h2IPSRinJ7ZJesSGFXK/xcDKh9W807hPnTSrNU1cuiRHE/tHFeBk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772438047; c=relaxed/simple; bh=NcG8Wz4fb5QGR9IfgzJPleBuULaYFRoy8AhRldIt9Rk=; h=Mime-Version:From:Subject:Message-Id:In-Reply-To:To:References:Cc: Date:Content-Type; b=ccCe57/Vqjp/ZnHG53ERn+PmyBAxIvIBiY9V7gk72qZDcWgPw91FCNwkRkiaelNpjdA0Yn9TbXPTmV2s7Crjw1aTrcVBjcWpuHOws6sokk3lP6hpuYKzSRvLBFOjhuyxnT0Vp6b84W3FRk2whuudnV38CGTqL2ym1V0vmFSTVbs= 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=DhmhvF3i; arc=none smtp.client-ip=118.26.132.102 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="DhmhvF3i" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1772438040; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=khwCmEjQKCEpmf3resegxvg4YTzSDN2uWcvMSwGXVs0=; b=DhmhvF3irZq+yklkCHVxPLZ8xYZWMV2K2694a6j3SiT3VgBcawJYzxsiLWCbAINedKqpEL QntjY7BFSxA8tZyPfJS9mKL82erzNONKn8o3RDCUorn7SWyt78zOOjijDpAV8tP5xzZo0V 94fSowwX/vYT/pe6r9uzCLETZMhFs7wF02Ni7q0kRgz+mQbLeA+s3AYfl3ydQwpse+YSxX q47TXlmQUlnxOP8ddN0z/23TtMXM4TN4WhmcwwofHniveWLjiCdnuZ9x8RvgZ0CyMwV9YP PCq/Se57VBy70Ga86bZCqjp0cKmszqN6UPIdanyPYZIyMP16kgxSOmgXWYSSiQ== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Original-From: Chuyi Zhou From: "Chuyi Zhou" Subject: [PATCH v2 06/12] smp: Enable preemption early in smp_call_function_many_cond Message-Id: <20260302075216.2170675-7-zhouchuyi@bytedance.com> In-Reply-To: <20260302075216.2170675-1-zhouchuyi@bytedance.com> To: , , , , , , , , , , , X-Lms-Return-Path: References: <20260302075216.2170675-1-zhouchuyi@bytedance.com> X-Mailer: git-send-email 2.20.1 Cc: , "Chuyi Zhou" Date: Mon, 2 Mar 2026 15:52:10 +0800 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Now smp_call_function_many_cond() disables preemption mainly for the following reasons: - To prevent the remote online CPU from going offline. Specifically, we want to ensure that no new csds are queued after smpcfd_dying_cpu() has finished. Therefore, preemption must be disabled until all necessary IPIs are sent. - To prevent migration to another CPU, which also implicitly prevents the current CPU from going offline (since stop_machine requires preempting the current task to execute offline callbacks). - To protect the per-cpu cfd_data from concurrent modification by other smp_call_*() on the current CPU. cfd_data contains cpumasks and per-cpu csds. Before enqueueing a csd, we block on the csd_lock() to ensure the previous asyc csd->func() has completed, and then initialize csd->func and csd->info. After sending the IPI, we spin-wait for the remote CPU to call csd_unlock(). Actually the csd_lock mechanism already guarantees csd serialization. If preemption occurs during csd_lock_wait, other concurrent smp_call_function_many_cond calls will simply block until the previous csd->func() completes: task A task B sd->func = fun_a send ipis preempted by B ---------------> csd_lock(csd); // block until last // fun_a finished csd->func = func_b; csd->info = info; ... send ipis switch back to A <--------------- csd_lock_wait(csd); // block until remote finish func_* This patch enables preemption before csd_lock_wait() which makes the potentially unpredictable csd_lock_wait() preemptible and migratable. Note that being migrated to another CPU and calling csd_lock_wait() may cause UAF due to smpcfd_dead_cpu() during the current CPU offline process. Previous patch used the RCU mechanism to synchronize csd_lock_wait() with smpcfd_dead_cpu() to prevent the above UAF issue. Signed-off-by: Chuyi Zhou --- kernel/smp.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/kernel/smp.c b/kernel/smp.c index ad6073b71bbd..18e7e4a8f1b6 100644 --- a/kernel/smp.c +++ b/kernel/smp.c @@ -801,7 +801,7 @@ static void smp_call_function_many_cond(const struct cpumask *mask, smp_cond_func_t cond_func) { bool preemptible_wait = !IS_ENABLED(CONFIG_CPUMASK_OFFSTACK); - int cpu, last_cpu, this_cpu = smp_processor_id(); + int cpu, last_cpu, this_cpu; struct call_function_data *cfd; bool wait = scf_flags & SCF_WAIT; cpumask_var_t cpumask_stack; @@ -809,9 +809,9 @@ static void smp_call_function_many_cond(const struct cpumask *mask, int nr_cpus = 0; bool run_remote = false; - lockdep_assert_preemption_disabled(); - rcu_read_lock(); + this_cpu = get_cpu(); + cfd = this_cpu_ptr(&cfd_data); cpumask = cfd->cpumask; @@ -898,6 +898,19 @@ static void smp_call_function_many_cond(const struct cpumask *mask, local_irq_restore(flags); } + /* + * We may block in csd_lock_wait() for a significant amount of time, + * especially when interrupts are disabled or with a large number of + * remote CPUs. Try to enable preemption before csd_lock_wait(). + * + * Use the cpumask_stack instead of cfd->cpumask to avoid concurrency + * modification from tasks on the same cpu. If preemption occurs during + * csd_lock_wait, other concurrent smp_call_function_many_cond() calls + * will simply block until the previous csd->func() complete. + */ + if (preemptible_wait) + put_cpu(); + if (run_remote && wait) { for_each_cpu(cpu, cpumask) { call_single_data_t *csd; @@ -907,7 +920,9 @@ static void smp_call_function_many_cond(const struct cpumask *mask, } } - if (preemptible_wait) + if (!preemptible_wait) + put_cpu(); + else free_cpumask_var(cpumask_stack); rcu_read_unlock(); } -- 2.20.1