From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Malcolm <dmalcolm@redhat.com>
Cc: linux-sparse@vger.kernel.org, linux-toolchains@vger.kernel.org,
David Faust <david.faust@oracle.com>,
Julia Lawall <julia.lawall@inria.fr>,
"Jose E. Marchesi" <jose.marchesi@oracle.com>,
Elena Zannoni <elena.zannoni@oracle.com>
Subject: Re: address_space and noderef on non-pointer types
Date: Thu, 13 Oct 2022 16:21:14 -0700 [thread overview]
Message-ID: <CAHk-=wg_haaRm5SyXZdQOO2OFr2GFqaZuW2CvhraKkq8f1V+jA@mail.gmail.com> (raw)
In-Reply-To: <e583356b104fbef6940a06bf360aa59c42bba3c2.camel@redhat.com>
On Thu, Oct 13, 2022 at 12:37 PM David Malcolm <dmalcolm@redhat.com> wrote:
>
> Is it valid to apply the sparse attributes 'noderef' or 'address_space'
> to non-pointers, and if so, what does this mean?
It means that the thing itself is in said address space and cannot be
accessed directly.
IOW, if you have something like this (I'll just use "__percpu" as an
example from the kernel):
# define __percpu __attribute__((noderef, address_space(__percpu)))
then
int __percpu x;
means that you cannot access the value of 'x' directly, and that x
itself is in the "__percpu" address space.
Trying to use the value of 'x', eg
printf("%d\n", x);
should cause a warning, along the lines of
warning: dereference of noderef expression
and taking the address of 'x' should result in a pointer that is of type
int __percpu *
which is entirely consistent (and then you'd have an inline function
or macro that then does the right magic to dereference a pointer in
that __percpu address space, in the kernel it would be
"this_cpu_read()" and friends).
> What is the intended meaning of "noderef" for a non-pointer?
Note that the pointer use is the common (and historical) use in the
kernel, but "noderef" really is not so much about the pointer, it's
about what the pointer points to.
IOW, notice that when you have a pointer to a __percpu variable, you
don't mark the *pointer* as being __percpu. It's not "int *ptr
__percpu", it's "int __percpu *ptr".
(Ok, "int *ptr __percpu" does conceptually exist, but it means that
the pointer itself is just an "int *", but it is in __percpu space, so
it's not about how the pointer cannot be dereferenced - you cannot
actually access the pointer value itself!).
So the type system is entirely consistent.
The documentation (and the naming) may be a bit pointer-centric, and
that in turn comes from the historical use of this originally only
being used for things like user pointers, but also from the fact that
internally in sparse, accessing a variable is actually the same as
dereferencing the symbol.
Linus
prev parent reply other threads:[~2022-10-13 23:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-13 19:37 address_space and noderef on non-pointer types David Malcolm
2022-10-13 23:21 ` Linus Torvalds [this message]
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='CAHk-=wg_haaRm5SyXZdQOO2OFr2GFqaZuW2CvhraKkq8f1V+jA@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=david.faust@oracle.com \
--cc=dmalcolm@redhat.com \
--cc=elena.zannoni@oracle.com \
--cc=jose.marchesi@oracle.com \
--cc=julia.lawall@inria.fr \
--cc=linux-sparse@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).