From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9EAE9343216 for ; Mon, 18 May 2026 12:33:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779107595; cv=none; b=DeethShHY9SSFWl4/Fa5Ay1T4/HK4rKVpSxgc8XrJ5BRamWjRMUmjwTJG6XDDngY8vIiE2DKa028A0Z1EwUGZK9vir3WYMH2FzWSfuxtt/SrhMsjfD11VecX2AYKQ75kqmIb78KlOlfgcEwxDtAK/Dua88mpww5LTwyVjEOb+gs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779107595; c=relaxed/simple; bh=xNPh5x7PUYf2b0+n2U0rK7b6u2aqB0hPpKpAY97oSLg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OIiP4FBU71RwWgZ5zzFihzE8WTTTvWac0HuRcjdQFq8usA6rRQ7Z6U8H8069XaLhkdrvp+cN7gjGMiTisDsTdxUaxNeMr22axwr/HoLY7ffDvMYE38roSN7yQzWI1zz7BjuA6npsKqaLSVt+845xfK/qUe9+1IZpUXOyh10YZlA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=fxV9110z; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="fxV9110z" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 722CD2328; Mon, 18 May 2026 05:33:07 -0700 (PDT) Received: from arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8D4233F632; Mon, 18 May 2026 05:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1779107592; bh=xNPh5x7PUYf2b0+n2U0rK7b6u2aqB0hPpKpAY97oSLg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fxV9110zFT4QtYbjAKKw/u/WXWljCB9/fD8p/t3vV8MJurFeKElZJnwr8OE0wNL9+ rDbuhQfWsZYCRrkah6haXxGqI3cAZqgGi/gNxVc1uvrGhuSHoemIjYnfi7XIreIcNJ 3TgPNVpVqKZFF3Z9ekUgfa/XYHcrCcirN+9yuRxU= Date: Mon, 18 May 2026 13:33:09 +0100 From: Catalin Marinas To: Kohei Enju Cc: Will Deacon , Sami Mujawar , Gavin Shan , Steven Price , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] virt: arm-cca-guest: use raw variant of smp_processor_id() in arm_cca_report_new() Message-ID: References: <20260518033157.1865498-1-enju.kohei@fujitsu.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260518033157.1865498-1-enju.kohei@fujitsu.com> On Mon, May 18, 2026 at 12:31:31PM +0900, Kohei Enju wrote: > With CONFIG_DEBUG_PREEMPT=y, smp_processor_id() becomes an alias of > debug_smp_processor_id(). This debug function complains when certain > conditions that ensure CPU ID stability are not met, specifically when > it's called from a preemptible context. > > In arm_cca_report_new(), which runs in a preemptible context, > smp_processor_id() triggers a splat [0] due to this. > > However, the CPU ID obtained here is used as the target CPU for > smp_call_function_single() to designate a specific CPU for subsequent > operations, not to assert that the current thread will continue to > execute on the same CPU. Therefore, snapshotting the CPU ID itself is > correct, and thus there's no actual harm except for the splat. > > Use raw_smp_processor_id() instead, to directly retrieve the current CPU > ID without the debug checks, avoiding the unnecessary warning message > while preserving the correct functional behavior. > > [0] > BUG: using smp_processor_id() in preemptible [00000000] code: cca-workload-at/134 > caller is debug_smp_processor_id+0x20/0x2c > CPU: 0 UID: 0 PID: 134 Comm: cca-workload-at Not tainted 7.0.0-rc1-gc74a64d12073 #1 PREEMPT > Hardware name: linux,dummy-virt (DT) > Call trace: > [...] > check_preemption_disabled+0xf8/0x100 > debug_smp_processor_id+0x20/0x2c > arm_cca_report_new+0x54/0x230 > tsm_report_read+0x184/0x260 > tsm_report_outblob_read+0x18/0x38 > configfs_bin_read_iter+0xf4/0x1dc > vfs_read+0x230/0x31c > [...] > > Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms") > Signed-off-by: Kohei Enju > --- > drivers/virt/coco/arm-cca-guest/arm-cca-guest.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c > index 0c9ea24a200c..2d450caee3e4 100644 > --- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c > +++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c > @@ -108,7 +108,7 @@ static int arm_cca_report_new(struct tsm_report *report, void *data) > * allocate outblob based on the returned value from the 'init' > * call and that cannot be done in an atomic context. > */ > - cpu = smp_processor_id(); > + cpu = raw_smp_processor_id(); That's just hiding the warning which might be genuine, irrespective of what the comment says. Sashiko has some good points: https://sashiko.dev/#/patchset/20260518033157.1865498-1-enju.kohei@fujitsu.com Basically what guarantees that the cpu won't go offline? Can we use migrate_disable() and ignore the smp_call_function_single() altogether? It looks like a hack anyway. We should also look at the other unrelated findings in this function from Sashiko. -- Catalin