From nobody Wed Apr 1 11:15:18 2026 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 C940E3BF680 for ; Tue, 31 Mar 2026 11:32:51 +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=1774956773; cv=none; b=o52FKE0+NitinWdVUmXqZfBgUst4gTwtuLEcsqPJlR8jjqdWhCfFXlJLm8TIaUQoQcG1hu6nmKZttHHzKWhQVYQlSF3PHZBfAehyZkYVBwWE6gLuJF1pPBq6YEVPRiThjgsc9q442gDuv9JLLHZkx774nyurCzh7L9jCLAix4UQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774956773; c=relaxed/simple; bh=I9hXemxNVff+3OSIOGk3Ax3O4tzLD3jTo41thSFz57M=; h=From:References:To:Date:Cc:Message-Id:Mime-Version:Subject: In-Reply-To:Content-Type; b=WIfipNOu+1vpFWJ3+ch1PHg6MW4ChEXlk+I7DxdR/5v9h0hDkocgWHEaC/TSSAdqDb+uGbK61pNEvqAY6Y5bE36Q+1bHcfR8uByfur2xwFDnx/7PuCHxZnsLxKGk3Y5VJgaqoTMOOzI9elggB7spi6DPEXvbPPnF63K/thYfwGA= 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=Qe9+uIaU; 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="Qe9+uIaU" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1774956767; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=IR2fbYWvvlLHW7bF5ETZrAx+GthPVN05/ic0Oz1bRok=; b=Qe9+uIaUdynRXSyf55AZhnT9iOTPrNaDbYRBdfX9olRZJgGi4hycuKaS/UEUn11XdAhMy6 RNKoeSriByZy+bomYYSzFtOoij9303BUEv11lOVaX8q9yoXQNY+s8oMpb2eT/y58z5N7z0 nVoPfrguQWCsE9reYIM6CumWGIlaJbPLIc5XMUoxbwXRCzRNkMuwtv5r5UkK7Hcwv7ZD2n wsIjpQ6oPujnSZh/RAENlD6RYL0+Avk8DO+lq095wuEVX5mbXyGk/Z+RX521knLbus8/jD tYUgOCZSGeJDH3vCrLneUCtqD0JjSXU9ytRtqORfQwWOnVCsXIji5yNDd3Z/GA== From: "Chuyi Zhou" References: <20260331113103.2197007-1-zhouchuyi@bytedance.com> To: , , , , , , , , , , , , Date: Tue, 31 Mar 2026 19:30:57 +0800 Cc: , "Chuyi Zhou" Message-Id: <20260331113103.2197007-7-zhouchuyi@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Subject: [PATCH v4 06/12] smp: Enable preemption early in smp_call_function_many_cond X-Original-From: Chuyi Zhou Content-Transfer-Encoding: quoted-printable X-Mailer: git-send-email 2.20.1 In-Reply-To: <20260331113103.2197007-1-zhouchuyi@bytedance.com> X-Lms-Return-Path: Content-Type: text/plain; charset="utf-8" Disabling preemption entirely during smp_call_function_many_cond() was primarily 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 current CPU from going offline. Being migrated to another CPU and calling csd_lock_wait() may cause UAF due to smpcfd_dead_cpu() during the current CPU offline process. - To protect the per-cpu cfd_data from concurrent modification by other tasks 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 async 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 =3D fun_a send ipis preempted by B ---------------> csd_lock(csd); // block until last // fun_a finished csd->func =3D func_b; csd->info =3D info; ... send ipis switch back to A <--------------- csd_lock_wait(csd); // block until remote finish func_* Previous patches replaced the per-cpu cfd->cpumask with task-local cpumask, and the percpu csd is allocated only once and is never freed to ensure we can safely access csd. Now we can enable preemption before csd_lock_wait() which makes the potentially unpredictable csd_lock_wait() preemptible and migratable. Signed-off-by: Chuyi Zhou --- kernel/smp.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/kernel/smp.c b/kernel/smp.c index 2a33877dd812..4ddb1ec1e43e 100644 --- a/kernel/smp.c +++ b/kernel/smp.c @@ -844,7 +844,7 @@ static void smp_call_function_many_cond(const struct cp= umask *mask, unsigned int scf_flags, smp_cond_func_t cond_func) { - int cpu, last_cpu, this_cpu =3D smp_processor_id(); + int cpu, last_cpu, this_cpu; struct call_function_data *cfd; bool wait =3D scf_flags & SCF_WAIT; struct cpumask *cpumask, *task_mask; @@ -852,10 +852,10 @@ static void smp_call_function_many_cond(const struct = cpumask *mask, int nr_cpus =3D 0; bool run_remote =3D false; =20 - lockdep_assert_preemption_disabled(); - task_mask =3D smp_task_ipi_mask(current); preemptible_wait =3D task_mask && preemptible(); + + this_cpu =3D get_cpu(); cfd =3D this_cpu_ptr(&cfd_data); cpumask =3D preemptible_wait ? task_mask : cfd->cpumask; =20 @@ -937,6 +937,19 @@ static void smp_call_function_many_cond(const struct c= pumask *mask, local_irq_restore(flags); } =20 + /* + * 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() completes. + */ + if (preemptible_wait) + put_cpu(); + if (run_remote && wait) { for_each_cpu(cpu, cpumask) { call_single_data_t *csd; @@ -945,6 +958,9 @@ static void smp_call_function_many_cond(const struct cp= umask *mask, csd_lock_wait(csd); } } + + if (!preemptible_wait) + put_cpu(); } =20 /** --=20 2.20.1