From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) (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 068C618FC97 for ; Mon, 11 May 2026 01:48:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778464131; cv=none; b=eIm2kGWzJqhHWRPWhr4gW0M7gxbalMbJ/wk1pJc68wEYb0ItTUQU/0P7SIeWkS5fgl/kUQBRa1ugFRTV8i59G+iWxTtaqSOUxBahwNPgj/g1H36VBvf0iMFWcmy3ONYQSUDT1adc2Z/9+xqzL8XrdT439wjcq8QNciCCWPwp75k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778464131; c=relaxed/simple; bh=TZP92YwLVERFb1hXBB/eyqJGKZ0TOipnU5TW9zwoUXI=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References; b=mn/3fNpB8KFTaZfkRAYzU+eBQLrOdvG6spcOHWkTeOrvbjqrohBFMlCKIVVokYPo7BJNDSarhdEVzI4NiJyuTQ9q74o52HuifZPUreQ1/EKsS/RakwDaHY/n1HoUMQHVlz9U4FTiF23ukRiwOD9ed4LoyFEE6sFGa8XwOpWjLPs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=n8Suj3cc; arc=none smtp.client-ip=209.85.215.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="n8Suj3cc" Received: by mail-pg1-f174.google.com with SMTP id 41be03b00d2f7-c801912c903so1568595a12.0 for ; Sun, 10 May 2026 18:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778464128; x=1779068928; darn=vger.kernel.org; h=references:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to; bh=EcpoM038XooU1Y0bBIiyinlJ3K3Hm9yy8VMj5gv4Yrg=; b=n8Suj3ccLB61VTiu1+bPIw96ggUQn52ldwEOINb4r6Bxdm/WnnCZw+wtzMM+WdO8NF DtZOxofqBtlw61FnMXgGb+4sh+EF+AqbWETiOvSBKGul/vXleJlAuJcDfa0Nv+vAwZxK EBCB+KJI9iLWUVr5ASjjMLhD+K/M7XIaCl6Z5N9gyNIIUCRbcp+XD1Al2IVlS4tUyU4+ lC1Cf88nS2BWbsZefYudXMsTtFAHItfoKIT6GOF39qKR7H/ncLHWiy3vlMFfIBGrbxX3 zNA5wl/mYsQqt4XpWzPUjVtsT4yLy1OA+ErfHm7W5IH/dMpk9SdRrWOyTCWORNynwl26 +6KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778464128; x=1779068928; h=references:message-id:date:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EcpoM038XooU1Y0bBIiyinlJ3K3Hm9yy8VMj5gv4Yrg=; b=hGA7k+EGocOv4WyjQDptbQYBXvSyY62Oj0nn9pw/MhT+UTuN+8glCBidOI3pBqdaVP fJ2x4dULOVNdbjjRA7bsTdIKqANDyjKUhzGwBSRz9PnK81u+Vx0ucozXIRGq12LRNcr1 AW6Eo3QhTvPwrMvCT4x6/+vneuVWpk+jr+hVxA7uG1tnvVEmGl+f7In23GD/HzvLxLz/ XxWvYqq/2iMTmyFyHhEpYLqplMcDq3cUz8Ybj2gyHh7C3k9RKf9wLSsOqAuRRYJObnyp +lrN3ZEjA/xrp4e94wd2oz93tJqs2PyIn6L+YuwBirmLTx9//sG5jbMyHagD6MUpCbYS HRSQ== X-Forwarded-Encrypted: i=1; AFNElJ89bMl3BEwtLDc+moX2YA+IibRQxTcc3zxcHnpDJ8sZYybe/fykNCOoqL26wVQuraQ1j+yC43CHypi8W5E=@vger.kernel.org X-Gm-Message-State: AOJu0Yy/YFMxwJ73YPHazJmRkKtXFdpLYGomNBhH4KJxI0uUL4XsBHzI P8PIf1EkX8BqX63Veug4VymvsVGsODxD8iQmGkzBLvcHkuc4yBwU3CikvMEpBQ== X-Gm-Gg: Acq92OHAIOGHw3PoB9KxsdzH4N44lsTaJCdM59kvKilLA/vUXbIlmq95CKLYMwp8LhT mYjrIy6Rkzoc9aHh0DVo7qWbj2fEESVzx/ErGhfSsxqqanKCIQaAmDXG66j37SYJvVATfE/Lr2i Z+cRhv39LJMbwHzCC1bHgw9ly1fbK5g/6OBfQN4achGaopYih283BzvlNIteRhxqDy+zq4leEgt 7TCr7xmfWGsSCJ28IzZ4Kugi98cVT+IpgJhWIPv2GlX5r4UbxzIPJFHq16uuliCIxrM3NdSlIAe Wg62GwmdFg8P+KoLlZduOFlETtxlX7m8VAtEk3aN8693k2yyWz/jcDBxr3bU+9GlqkGLcMfA8tD MOWy/wcjmTcGSAL8CsMe7tqVUN0Nm68QPaYtNDE4f/wagK12OUzuttPGL/hIfx1wogI1TRNa3US GLW5vboscPQE9KQGkC0+dZnvaAYkNGwvwH X-Received: by 2002:a05:6a20:1585:b0:3a2:dc51:458 with SMTP id adf61e73a8af0-3aad4498cc2mr7256531637.41.1778464128371; Sun, 10 May 2026 18:48:48 -0700 (PDT) Received: from pve-server ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c8267727401sm7349158a12.30.2026.05.10.18.48.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 May 2026 18:48:47 -0700 (PDT) From: Ritesh Harjani (IBM) To: Aboorva Devarajan , Madhavan Srinivasan , Athira Rajeev , linuxppc-dev@lists.ozlabs.org Cc: Aboorva Devarajan , Christophe Leroy , Kajol Jain , linux-kernel@vger.kernel.org Subject: Re: [PATCH] powerpc/hv-gpci: fix preempt count leak in sysfs show paths In-Reply-To: <20260508041256.3447113-1-aboorvad@linux.ibm.com> Date: Mon, 11 May 2026 07:07:32 +0530 Message-ID: <5x4usp43.ritesh.list@gmail.com> References: <20260508041256.3447113-1-aboorvad@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Aboorva Devarajan writes: > Four sysfs show() callbacks in hv-gpci take get_cpu_var(hv_gpci_reqb) > (which calls preempt_disable()) but only call the matching put_cpu_var() > on the error path under the 'out:' label. Every successful read leaks > one preempt_disable(): > > processor_bus_topology_show() > processor_config_show() > affinity_domain_via_virtual_processor_show() > affinity_domain_via_domain_show() > > (affinity_domain_via_partition_show() was already correct.) > > On a CONFIG_PREEMPT=y kernel, repeated reads raise preempt_count and > eventually return to userspace with preemption still disabled. The > next user-mode page fault then hits faulthandler_disabled() == 1, > gets forced to SIGSEGV, and the resulting coredump trips > 'BUG: scheduling while atomic' in call_usermodehelper_exec -> > wait_for_completion_state -> schedule: > > BUG: scheduling while atomic: //0x00000004 > ... > __schedule_bug+0x6c/0x90 > __schedule+0x58c/0x13a0 > schedule+0x48/0x1a0 > schedule_timeout+0x104/0x170 > wait_for_completion_state+0x16c/0x330 > call_usermodehelper_exec+0x254/0x2d0 > vfs_coredump+0x1050/0x2590 > get_signal+0xb9c/0xc80 > do_notify_resume+0xf8/0x470 > > Add an out_success label that calls put_cpu_var() before returning > the byte count, mirroring affinity_domain_via_partition_show(). Yup. That seems like the right thing to do otherwise we leak preempt count. I guess, these would be the other kind of issues which might show up now, since powerpc is moved to CONFIG_PREEMPTION=y with lazy preempt as the default preemption mode. It will be nice to have some mechanism to catch these error handling paths where preempt counts might be getting leaked. Nice Catch! As for this patch, it looks to me. Reviewed-by: Ritesh Harjani (IBM)