From: Uros Bizjak <ubizjak@gmail.com>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: "open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>,
Christoph Lameter <cl@linux.com>,
Andy Lutomirski <luto@kernel.org>,
Ingo Molnar <mingo@kernel.org>, Brian Gerst <brgerst@gmail.com>,
Denys Vlasenko <dvlasenk@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Subject: Re: [RFC PATCH v2 2/4] percpu: Assorted fixes found by strict percpu address space checks
Date: Mon, 12 Aug 2024 22:36:04 +0200 [thread overview]
Message-ID: <CAFULd4YOf0Mz-JbR6LEWxM2M=4GTxqC9m-q_QAZJw8Ws16yrTA@mail.gmail.com> (raw)
In-Reply-To: <2EF46123-30B0-4A7E-9414-EE25CBCF255E@gmail.com>
On Mon, Aug 12, 2024 at 9:09 PM Nadav Amit <nadav.amit@gmail.com> wrote:
>
>
> > On 12 Aug 2024, at 14:57, Uros Bizjak <ubizjak@gmail.com> 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_match,
> > - (__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 *attr,
cpu_events = 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 *attr,
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.
next prev parent reply other threads:[~2024-08-12 20:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 11:57 [RFC PATCH v2 0/4] Enable " Uros Bizjak
2024-08-12 11:57 ` [RFC PATCH v2 1/4] percpu: Define pcpu_typeof() Uros Bizjak
2024-08-12 11:57 ` [RFC PATCH v2 2/4] percpu: Assorted fixes found by strict percpu address space checks Uros Bizjak
2024-08-12 19:09 ` Nadav Amit
2024-08-12 20:36 ` Uros Bizjak [this message]
2024-08-12 11:57 ` [RFC PATCH v2 3/4] percpu: Repurpose __percpu tag as a named address space qualifier Uros Bizjak
2024-08-12 19:12 ` Nadav Amit
2024-08-12 20:01 ` Uros Bizjak
2024-08-12 11:57 ` [RFC PATCH v2 4/4] percpu/x86: Enable strict percpu checks via named AS qualifiers Uros Bizjak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFULd4YOf0Mz-JbR6LEWxM2M=4GTxqC9m-q_QAZJw8Ws16yrTA@mail.gmail.com' \
--to=ubizjak@gmail.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=cl@linux.com \
--cc=dennis@kernel.org \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luc.vanoostenryck@gmail.com \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=nadav.amit@gmail.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox