From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from esa1.hc1455-7.c3s2.iphmx.com (esa1.hc1455-7.c3s2.iphmx.com [207.54.90.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3773448033E for ; Mon, 18 May 2026 13:40:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=207.54.90.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779111611; cv=none; b=R7PLKQwGxILEzZdztO7JFYTiNMr8jcyAcyb0vgMRFEsslN4G6bG6jmeHm9qjsjf9ju74+CCEZu92J80JAC2v7Ex4IroIYObperGxGSeZyJtxE8Y258TNJzIpuWJa1Syq5Q2rAbiWnayCTb5nyNwoT1sCvYmgeQ9K0JzJG2c02bg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779111611; c=relaxed/simple; bh=Z2kNdpLbI2LyHk1ntAUPjhzA6RQ5Jbi78aL7gqWOJ6s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZaRe6YQVtvgPMPA0aaTNLacyj5qvWgb79vHfqewkxjlEqIFv+7M8RRO+kKhQp76u/Y+wAK+ABDr3vvYn4Q2UeamfHBbHziAertTlOkWveiw/nOeSIwauG9TFMPA+26PSFXrAbf1k1mg4LPyAgpbr+nNTpkEVDqdmF71X22Tktg0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=fujitsu.com; spf=pass smtp.mailfrom=fujitsu.com; dkim=pass (2048-bit key) header.d=fujitsu.com header.i=@fujitsu.com header.b=LcGdDZ40; arc=none smtp.client-ip=207.54.90.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=fujitsu.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fujitsu.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fujitsu.com header.i=@fujitsu.com header.b="LcGdDZ40" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fujitsu.com; i=@fujitsu.com; q=dns/txt; s=fj2; t=1779111609; x=1810647609; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Z2kNdpLbI2LyHk1ntAUPjhzA6RQ5Jbi78aL7gqWOJ6s=; b=LcGdDZ40Szz/0G7YRpSkZHG6xsZJbXsw1072aYsHYH7Txl+xFirDYu/a VgEF7VIen85kqoJazbmp0GZFfYMkWCg9YZpo3GyMuqLy4WGR/Z1j8Bd9Q Nw+gw7TwOQxXxdUgOmj+R+IAre8v5DGYd/OdYGEbY2qRxO9gBX9aEex+w gpArixA34SeYf1zre0HuxCho5gSpUwnEAlgdnl5BvS7PDxToQxDvaJrLe Ckg7jYg8arZ1SeqQPCaDles9llPbwXVfIq3zXKRgGdkTx5D/fgNUcCUwL DNKOLTLGpJoIpJ56xgj/jT6IkCWTC7sP2cUwxoMGMhuRArbGGJu1cHrcB A==; X-CSE-ConnectionGUID: vqPAXb04Sta6vhg0NFRY1Q== X-CSE-MsgGUID: FDGCjr/wQoaMisuIUJi/9Q== X-IronPort-AV: E=McAfee;i="6800,10657,11790"; a="240977339" X-IronPort-AV: E=Sophos;i="6.23,242,1770562800"; d="scan'208";a="240977339" Received: from gmgwuk01.global.fujitsu.com ([172.187.114.235]) by esa1.hc1455-7.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2026 22:38:59 +0900 Received: from az2uksmgm4.o.css.fujitsu.com (unknown [10.151.22.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by gmgwuk01.global.fujitsu.com (Postfix) with ESMTPS id E39871002B83 for ; Mon, 18 May 2026 13:38:58 +0000 (UTC) Received: from az2uksmom3.o.css.fujitsu.com (az2uksmom3.o.css.fujitsu.com [10.151.22.205]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by az2uksmgm4.o.css.fujitsu.com (Postfix) with ESMTPS id 9C6D914003B3 for ; Mon, 18 May 2026 13:38:58 +0000 (UTC) Received: from FCCLS0092175.localdomain (unknown [10.8.3.119]) by az2uksmom3.o.css.fujitsu.com (Postfix) with SMTP id 6019810003F8; Mon, 18 May 2026 13:38:54 +0000 (UTC) Date: Mon, 18 May 2026 22:38:53 +0900 From: Kohei Enju To: Catalin Marinas 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=utf-8 Content-Disposition: inline In-Reply-To: On 05/18 13:33, Catalin Marinas wrote: > 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. Hi Catalin, Thank you for reviewing. You've raised a very valid point about raw_smp_processor_id() potentially hiding a genuine issue. I agree this would be a concern in most contexts. However, this implementation was intentionally designed not to block CPU hotplug: https://lore.kernel.org/linux-arm-kernel/7a83461d-40fd-4e61-8833-5dae2abaf82b@arm.com/ As mentioned in the thread above, the potential failure from the target CPU going offline (resulting in -ENXIO) is an expected and tolerated condition in this path. Using migrate_disable() would go against the non-blocking design goal. Given the context, the debug warning looks false positive for our specific use case to me, and I believe raw_smp_processor_id() correctly reflects the design intent by simply acquiring a CPU number without debug checks. > > We should also look at the other unrelated findings in this function Regarding the other unrelated findings by Sashiko, I'll take a look at them. Thanks for the heads-up. Thanks, Kohei > > -- > Catalin >