From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-1-101.ptr.blmpb.com (sg-1-101.ptr.blmpb.com [118.26.132.101]) (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 DF2EB34C802 for ; Fri, 6 Feb 2026 09:07:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.26.132.101 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770368854; cv=none; b=KFoivTqczDZBt6vOQ7gUD57a4igv/jCeZ6nKctNJ1doNA/3RqhccT0dAydypfx1OVNfBw/M+wN9EqKYaiNnMCnK1I4ZTlhsBz+750HbSEFQqAeUcOf9vm0CSYQu/qAx93Fbk/uk23d35NnVkQHwVUyjELHA08JW7mXU++SiHzHk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770368854; c=relaxed/simple; bh=M5fv+2IhAWw/DUG4tplYKTSbMeSClJD/85Pk4AZ1KlQ=; h=From:Subject:Date:Mime-Version:Cc:Content-Type:To:Message-Id: References:In-Reply-To; b=cVds0O6Y007Uz6v02T4L0fBlqcPO8iSnwBUiNiyYiuh8wPbjifa3YjisfRQeNVLASJk40vF+5yQv4GeYw63rdbru8njlohK7+QyRo2p06z0tjnBQ+o6EnqBvoQXInkI48o3iCFJntJutnPVKtOPXoxWfRxIc/QSFxAtmFRYOnmo= 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=dNcJQNTW; arc=none smtp.client-ip=118.26.132.101 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="dNcJQNTW" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1770368841; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=/dWg1ruU2E79y9KXo379Y1aNpaycThgy8jfQ3F2LL7I=; b=dNcJQNTWUSfSbGZxumsUG9vKYL9qb+2HH+Zhmqe3YZDvv/dIDj8xgJBjmTnB9IojTOxHAF ydgum20z6VbU/UO0D4vinltLcqqjUGLzehmHCUOwsoLNJyYKsxO0EZsr6o2gw51RMSK3Ys xBhzeDcxBMwMl1wxn5YHqJQ1PhkqeGdQNkHl2aMqs3brMMcWlmQnW6S82KGAU+EqWBI9hO uRKiDxjl2lCURH5puGg/R+sS0KMDuNz0jLhS0JSvEkgriGNxt0PQno9p5RVVN7+oFExhx8 YLwFfZAS03/52P0XBn/ijSemCazmmxyam4VDNGAf3uhps/C2pe6o2/kPJB16XQ== From: "Chuyi Zhou" Subject: Re: [PATCH 04/11] smp: Use on-stack cpumask in smp_call_function_many_cond X-Lms-Return-Path: Date: Fri, 6 Feb 2026 17:07:05 +0800 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 Cc: , , , , , , , Content-Type: text/plain; charset=UTF-8 X-Original-From: Chuyi Zhou To: "Peter Zijlstra" Message-Id: References: <20260203112401.3889029-1-zhouchuyi@bytedance.com> <20260203112401.3889029-5-zhouchuyi@bytedance.com> <20260205094422.GG232055@noisy.programming.kicks-ass.net> User-Agent: Mozilla Thunderbird In-Reply-To: <20260205094422.GG232055@noisy.programming.kicks-ass.net> =E5=9C=A8 2026/2/5 17:44, Peter Zijlstra =E5=86=99=E9=81=93: > On Tue, Feb 03, 2026 at 07:23:54PM +0800, Chuyi Zhou wrote: >> This patch use on-stack cpumask to replace percpu cfd cpumask in >> smp_call_function_many_cond(). alloc_cpumask_var() may fail when >> CONFIG_CPUMASK_OFFSTACK is enabled. In such extreme case, fall back to >> cfd->cpumask. This is a preparation for the next patch. >> >> Signed-off-by: Chuyi Zhou >> --- >> kernel/smp.c | 22 +++++++++++++++++----- >> 1 file changed, 17 insertions(+), 5 deletions(-) >> >> diff --git a/kernel/smp.c b/kernel/smp.c >> index f572716c3c7d..35948afced2e 100644 >> --- a/kernel/smp.c >> +++ b/kernel/smp.c >> @@ -805,11 +805,17 @@ static void smp_call_function_many_cond(const stru= ct cpumask *mask, >> int cpu, last_cpu, this_cpu =3D smp_processor_id(); >> struct call_function_data *cfd; >> bool wait =3D scf_flags & SCF_WAIT; >> + bool preemptible_wait =3D true; >> + cpumask_var_t cpumask_stack; >> + struct cpumask *cpumask; >> int nr_cpus =3D 0; >> bool run_remote =3D false; >> =20 >> lockdep_assert_preemption_disabled(); >> =20 >> + if (!alloc_cpumask_var(&cpumask_stack, GFP_ATOMIC)) >> + preemptible_wait =3D false; >=20 > IIRC this breaks RT, must not allocate with preemption disabled. Thank you for the reminder. Perhaps another feasible approach is only consider=20 CONFIG_CPUMASK_OFFSTACK=3Dn. Of course, if we use cpus_read_lock and ensure that the caller=E2=80=99s co= ntext=20 is sleepable, this issue would also be eliminated.