From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-1-103.ptr.blmpb.com (sg-1-103.ptr.blmpb.com [118.26.132.103]) (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 8A30134CFA7 for ; Fri, 6 Feb 2026 08:44:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.26.132.103 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770367471; cv=none; b=lgkOmcr6BzMM5Io7aKqPpzeSD9fLYuckdx0fItuzU93yZB8Etm0WdDx+9bYRqL3h3k//Ffo/U/J1DGUVzzMf0fmwcDIF3BRq1kvExV1AwCAxQTqKJGzPxvLinlCs5ukPTTqhBEC2xmR/CrL4Umcf5WF/7lba8AvNesrLeB9k8Eo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770367471; c=relaxed/simple; bh=65JAkZTw6z0VkAbdIZBIUm3srptaFZzsfpwSMQu0XFo=; h=References:Cc:Subject:Mime-Version:In-Reply-To:Content-Type:To: From:Message-Id:Date; b=a18t5XZrCcO5RbUEbz6vAkRo+f/jwaqciYDWoYfsY2VDwPQRROUTJe5a8sOFmnAnFUz0xnmSgvWHQwV1qj2wHeiEs8OoqNTruGHr8HX296BZe1xyFOEuk54lhzs6A7jFT0e+ulC5QsbTabYAk41wsnUir35ncs0DlpKqxWCXmog= 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=nyxKgNaD; arc=none smtp.client-ip=118.26.132.103 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="nyxKgNaD" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1770367463; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=xvGpLoak+adbw71ufrejg4QCW6mBoVs9Rz5E9+I8rGc=; b=nyxKgNaDWIi5GfhItQONlAjUl0auoeGdMiNazwjRa+rYsNR3w6CjfycxunKUEmtTlO9DYY /B9wmmQDeMmrXMSukKhhBmXZ2P6HNgSNomtajX2w4Ww8QIhrZEYEIq3R6rU0yhrNyiD/E4 fgkYCRaQkjAzc9mlcCQlOO0ynd3ljzBY/9FqbzJFHEXooTalptnHUghpj9FVKtspGQb62b F6R6NIAiMIDr8u/40VLYGKFtZSbG3X+FItZjzsynhk1+u85q81hTZakIpZmTikWykZp1B6 ga2so+LYtE/QIXRTENMfp5hHV6fSAqJCUbEvETRimC9ucRSDknzUIttJnbrdPw== User-Agent: Mozilla Thunderbird References: <20260203112401.3889029-1-zhouchuyi@bytedance.com> <20260203112401.3889029-6-zhouchuyi@bytedance.com> <20260205095236.GI232055@noisy.programming.kicks-ass.net> <20260205105704.GA245049@noisy.programming.kicks-ass.net> <261ae19f-e3d1-4017-be1e-90b5c6d91dc7@bytedance.com> <20260205145912.GM2995752@noisy.programming.kicks-ass.net> Cc: , , , , , , , Subject: Re: [PATCH 05/11] smp: Enable preemption early in smp_call_function_many_cond Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20260205145912.GM2995752@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8 X-Lms-Return-Path: To: "Peter Zijlstra" From: "Chuyi Zhou" Message-Id: X-Original-From: Chuyi Zhou Date: Fri, 6 Feb 2026 16:43:48 +0800 Hi Peter, =E5=9C=A8 2026/2/5 22:59, Peter Zijlstra =E5=86=99=E9=81=93: > On Thu, Feb 05, 2026 at 10:29:51PM +0800, Chuyi Zhou wrote: >> Hi Peter, >> >> =E5=9C=A8 2026/2/5 18:57, Peter Zijlstra =E5=86=99=E9=81=93: >>> On Thu, Feb 05, 2026 at 10:52:36AM +0100, Peter Zijlstra wrote: >>>> On Tue, Feb 03, 2026 at 07:23:55PM +0800, Chuyi Zhou wrote: >>>> >>>>> + /* >>>>> + * Prevent the current CPU from going offline. >>>>> + * Being migrated to another CPU and calling csd_lock_wait() may ca= use >>>>> + * UAF due to smpcfd_dead_cpu() during the current CPU offline proc= ess. >>>>> + */ >>>>> + migrate_disable(); >>>> >>>> This is horrible crap. migrate_disable() is *NOT* supposed to be used = to >>>> serialize cpu hotplug. >>> >>> This was too complicated or something? >>> >> >> Now most callers of smp_call*() explicitly use preempt_disable(). IIUC, >> if we want to use cpus_read_lock(), we first need to clean up all these >> preempt_disable() calls. >> >> Maybe a stupid question: Why can't migrate_disable prevent CPU removal? >=20 > It can, but migrate_disable() is horrible, it should not be used if at > all possible. As you pointed out, using cpus_read_lock() is the simplest approach, and=20 indeed, that was the first solution we considered. However, 99% of callers have preemption disabled, some of them even=20 invoking it within spin_locks (for example, we might trigger a TLB flush=20 while holding pte spinlocks). It's difficult for us to eliminate all these preempt_disable(),=20 especially for callers that disable preemption for other purposes,=20 making the use of cpus_read_lock almost impossible. In our production environment, we observed that the overhead of=20 csd_lock_wait can be as high as several milliseconds, and in extreme=20 cases, even exceed 10ms+. Generally speaking, the time spent on=20 csd_lock_wait far exceeds the overhead of sending the IPI. Disabling preemption for the entire duration would obviously affect the=20 preemption latency of high-priority tasks, which is unacceptable. This=20 optimization primarily targets PREEMPT, although PREEMPT_RT can also=20 benefit from it. Compared to the cost of disabling preemption entirely, maybe using=20 migrate_disable() here seems to be an acceptable trade-off.