From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6BA97C3DA7F for ; Mon, 12 Aug 2024 20:36:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B63FD6B00B0; Mon, 12 Aug 2024 16:36:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B13A56B00B1; Mon, 12 Aug 2024 16:36:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B3D16B00B3; Mon, 12 Aug 2024 16:36:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 78D326B00B0 for ; Mon, 12 Aug 2024 16:36:21 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E3D4F803CA for ; Mon, 12 Aug 2024 20:36:20 +0000 (UTC) X-FDA: 82444750920.23.A1C4E43 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf11.hostedemail.com (Postfix) with ESMTP id 11A5E4000D for ; Mon, 12 Aug 2024 20:36:18 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="et/MacuK"; spf=pass (imf11.hostedemail.com: domain of ubizjak@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=ubizjak@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723494924; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5Krl4tzyVcLOgEOZk0xyBfeZl1rzZ7k3IomOAOBcy3A=; b=kR9pkwi/YpPdyb5N2/EFC7ng4T88Sy9PhhTJQWV0heU7Zg7sHV5jHi/olIYCPPWG6lkuXf 3m6K8RInBFCNk4TbZkue53E7bZ1e4c18amlFFrrHn+KBzzD6XwLVkGXJTiR59s0gEtKhbe gXCfnQ04Z/MxUlMEJHmHlX1n8034dYo= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="et/MacuK"; spf=pass (imf11.hostedemail.com: domain of ubizjak@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=ubizjak@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723494924; a=rsa-sha256; cv=none; b=aLLn2xgrqa8BHjM/oLXznzNEM/LyDxqniHTc+T+zZiiLoLJCIAZPKVes+umQvU065tbLuL inhx1NreK3E73yMIVdyFS7mC/kCH2mfEMwghm2DpI/9l4LkmWiZRlmDL9buxqMnZ2HeDxG hYxvJJQT6kUDqFu5/te2YM/89cDPcbg= Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2ef1c12ae23so48334531fa.0 for ; Mon, 12 Aug 2024 13:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723494977; x=1724099777; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5Krl4tzyVcLOgEOZk0xyBfeZl1rzZ7k3IomOAOBcy3A=; b=et/MacuKDh88QLDgvhZi4qmaaKrqH9E97rWN3lQkC2HDAleqRImnfCIeC6HPERjSg8 qsYxSiIQsGLEjmvZ9R3MHA5E0eC+zl8oJ/hOzdUjSeRNeCkm88EJXyMf9bicVyTHsXen LSV6841LAm3JPx8fHAarnd/nzO3H5fgj9dwqnAeCJe8KmuZ2lyIC6gIeA2Om4i15wvQ4 PdMC+GzDPsw+HLqATapTgf8cuKy+GWx/SViWetZ7XhVOWMqgRd/6N32TvsR9LXiBTWbw iXW5jSRbmi4cgNe2omqo1VNFeRbuSPogZYNTMMoZXuj9CD5FpI6GZrFQYF1OAcnDx5tq 7RaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723494977; x=1724099777; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5Krl4tzyVcLOgEOZk0xyBfeZl1rzZ7k3IomOAOBcy3A=; b=dlTPjCGgbHY8oVSXEEOFMoIDjLVbkohwkect3FuDjsseFlfwmHF/h2sJKM1leL2HpA BA0SkUFOfhTdnE7S1EhkXogIJDEYaxKtnlglXQbXfxn5GgjlcnE8TX5Nvy1G4h4UuHvu +T9/JJCuLlzxOZKsDcxHFndt8ulX2YTCpbJJ7Kb2Yu6KbPyr6akzI6AGeYp2ezZiD/sb 6G0AV1XxKGe1cgt9q3PprlKP43VPiTzox2io3FmYTEixbcHTqrmCduKfKvgWCPg1ItcG aiNvCXrA5ifrRYjF1z6fo1G0OfZDt9D//Iqr77rM4Ux2O67aPV/v6ikoqgaRS9zHL09N +z4Q== X-Gm-Message-State: AOJu0YzD6KKegVcgotffHRxs8PKMXKPcl6UemjF0QWBSlWo88X1UZOtb LBwnalVjlTr2JB9XYSTk3cKT5Qj3ftr1khEbTVSXmz5HewT1mD/00tvFeKx22eUKiuAzBTcenSu Q4C3dJWoQCM4PwNQZTOn5+0MNcaM= X-Google-Smtp-Source: AGHT+IHAnN6iPut17bEYXfYnfLGsXK6sfXzfubPXfbhUS8blTjz17bOTn91JlkDIm7hIKzp3PRjRYFu2wWeBlv0+4lY= X-Received: by 2002:a2e:d12:0:b0:2ef:2344:deec with SMTP id 38308e7fff4ca-2f2b72779a8mr8663761fa.45.1723494976878; Mon, 12 Aug 2024 13:36:16 -0700 (PDT) MIME-Version: 1.0 References: <20240812115945.484051-1-ubizjak@gmail.com> <20240812115945.484051-3-ubizjak@gmail.com> <2EF46123-30B0-4A7E-9414-EE25CBCF255E@gmail.com> In-Reply-To: <2EF46123-30B0-4A7E-9414-EE25CBCF255E@gmail.com> From: Uros Bizjak Date: Mon, 12 Aug 2024 22:36:04 +0200 Message-ID: Subject: Re: [RFC PATCH v2 2/4] percpu: Assorted fixes found by strict percpu address space checks To: Nadav Amit Cc: "open list:MEMORY MANAGEMENT" , Linux Kernel Mailing List , Dennis Zhou , Tejun Heo , Christoph Lameter , Andy Lutomirski , Ingo Molnar , Brian Gerst , Denys Vlasenko , "H. Peter Anvin" , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , Borislav Petkov , Luc Van Oostenryck Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 1h8utb1cxrdk1gjzzofuhmzasywn3fhg X-Rspam-User: X-Rspamd-Queue-Id: 11A5E4000D X-Rspamd-Server: rspam02 X-HE-Tag: 1723494978-33852 X-HE-Meta: U2FsdGVkX19ZM9otso0biNSTIOhrbKpMxOK5blYGZ4lVDdWoNQn0jLE71ft2lTD3K5Lx8TGsEkYzvgMwk+yOXpcnJ04N/26KyH3mzMqm0V5AeRvXkfoyamfDnSUHdMcJEGwQtKyedOCabfLSvITvEHU2GJaZiiEwKH38tOyoIE3XzDj61e4BPKFTfDwWXaDrs4zOtW2NdP5UUQVi4oAsuWA6HKu5fbN1cp0oXqhsofmzsPvdBgXwAsyD3s9Ht5IksG6zjpMdn8g9Dle6IGsNDLsqi/OCAqW/HdQIs0KHbC0i+z683bMPT1KNoPEWyDfMGQLXFC4ZB07/ymGfzU1VY6ThEUuF9tOdkA+yO0AWWslK2GAjByim5kUfdbMfdPckreUzY7zUcxCbVcXMzBvO5E7DEtO3cYrZBws1Fuxh6u7WDdnel1Go6REEmEWKZFeMV1YBa/aFHNzN2XRchvVw3SyJeZnSsIzyB8BdRELTtNVWtfxloP2VO/Y+7A+zvALKo179lNkr5SximKMy9Kg3yiQKAx12Dkoi4eg3tuswq2B+eVTu16o0zudKDeOVZX0Y7QfkIEgzPwCe3e4JANqd61tAiSnRMcEiBImXbUX2sqe8sA0usvrubXv2XkSNxlS9cEB23Yi0QI+UcSkjNqkMPu8Twr9wgJT9XJ+pb2TxsTVJpT16L+MoemenEDH4hbJ6vTup4wEpiop+POk67uYaTu8pEtx03iBEWDgaouUJ68/093XTMuD0UTak/oVgkB67L09JgIaVxW84XgYCGiWgzMwJQDcl7ROGJBqRtaiJkNRcoEoz3fr1tW5egQW20qObUq84u7u0leNdalftfE2bhdMuKZnjo2IfQjORfk9C+1iq8qBn2TCthOnzEPKxRvSgKHhmo5P/9BnlWNXEWIsDMCSmTkA0sNm16z9T3xR19RWBIgKGxSii6BvAg/wfuOWBjzW+NZBwXTl/6MRM1pZ 5wXKhcwK 9j/iXFmnwOUyPcuEajA6Qoy/1lDcPBC65VkRWHekkNFrde1OyUMX6Xx/5LDI6Rmhut23R7CsZkeDrTQbYomCiXCMgCUV6RbQEUhzKcl3L1VahmtEfUnX0mrQ+/IxCR7RQ6V1w9KzRTwFscHgwi9srTmIlAS59ROs1dsIGcdDjbBAxLRSzfOGtuLKDs0suizOdg+flU0oLm8Yj+fmYME6UKHY2kbjGRfmEgfSRjnOX0jfPY2tJARBiGfbKmghEQAXmeCNYH8vPuMZqsl9iTr7mXVs1F08oDxSQZiIRNDyjgo0XM+uDHhFVpjcqy7ZW9bLzlwu/0zW2ogPju3CynTYVHcLMJ7iKbJRgHMmpO17BV2zIV6e1y0RMpEF+c5EeE+VxMWeb7/eUM48G7191oCIRN9Ic6THSpqexPRIe1PyXw8G1iif6jhX1Oa3yow== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Aug 12, 2024 at 9:09=E2=80=AFPM Nadav Amit w= rote: > > > > On 12 Aug 2024, at 14:57, Uros Bizjak wrote: > > Assorted fixes to prevent defconfig build failures when > > strict percpu address space checks will be enabled. > > > > These show effeciveness of strict percpu address space checks. > > [snip] > > > --- a/drivers/base/devres.c > > +++ b/drivers/base/devres.c > > @@ -1231,6 +1231,6 @@ void devm_free_percpu(struct device *dev, void __= percpu *pdata) > > * devm_free_pages() does. > > */ > > WARN_ON(devres_release(dev, devm_percpu_release, devm_percpu_matc= h, > > - (__force void *)pdata)); > > + (__force void *)(uintptr_t)pdata)); > > > > Since this pattern of casting appears multiple times (sometimes slightly > different), I think it would be best to give a name for this operation > and put it behind a macro. The macro would not be flexible enough to also cover const qualified (const void __percpu *)(const uintptr_t) casts, required in e.g. [1]. [1] https://lore.kernel.org/lkml/20240811161414.56744-1-ubizjak@gmail.com/ Also, some casts are decorated with __force. According to sparse documentation [2], there is no need to use __force when the destination type is uintptr_t or unsigned long, but sparse seems to not be consistent with this exception, leading to spurious warnings and fixes like the one in [3]. [2] https://sparse.docs.kernel.org/en/latest/annotations.html#address-space= -name [3] https://lore.kernel.org/lkml/20240402175058.52649-1-ubizjak@gmail.com/ OTOH, in a full allyesconfig this pattern of casting appears maybe a dozen of times (which is a surprisingly small number). > This would allow both to audit the cases developers move data between > address-spaces, and also make them think whether what they do makes > sense. Looking through the fixes required for allyesconfig build, the remaining couple of casts are mostly required for ERR_PTR return with __percpu return type function, like: --cut here-- diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c index 6c2cb4e4f48d..d82fe78f0658 100644 --- a/kernel/events/hw_breakpoint.c +++ b/kernel/events/hw_breakpoint.c @@ -849,7 +849,7 @@ register_wide_hw_breakpoint(struct perf_event_attr *att= r, cpu_events =3D alloc_percpu(typeof(*cpu_events)); if (!cpu_events) - return (void __percpu __force *)ERR_PTR(-ENOMEM); + return (void __percpu __force *)(uintptr_t)ERR_PTR(-ENOMEM); cpus_read_lock(); for_each_online_cpu(cpu) { @@ -868,7 +868,7 @@ register_wide_hw_breakpoint(struct perf_event_attr *att= r, return cpu_events; unregister_wide_hw_breakpoint(cpu_events); - return (void __percpu __force *)ERR_PTR(err); + return (void __percpu __force *)(uintptr_t)ERR_PTR(err); } EXPORT_SYMBOL_GPL(register_wide_hw_breakpoint); --cut here-- While the casts are somehow ugly, I think that the number of different types (pcpu -> generic and generic -> pcpu casts with possible const qualifier and still needed __force sparse attribute) and low number of occurrences currently do not warrant a separate macro. Uros.