From: Uros Bizjak <ubizjak@gmail.com>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: linux-sparse@vger.kernel.org, Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: sparse: Expected ) at end of cast operator, got __seg_gs
Date: Mon, 4 Dec 2023 16:02:32 +0100 [thread overview]
Message-ID: <CAFULd4buj4yX9Rgef1H3F4Sk042CaP1v=DwZBi=LHg1oEvQ2Sw@mail.gmail.com> (raw)
In-Reply-To: <CAFULd4YJ2vC-3Yj648XRquz0rh5jUgJEw6S89JC-h8p5A4-WTg@mail.gmail.com>
On Mon, Dec 4, 2023 at 3:50 PM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Mon, Dec 4, 2023 at 3:37 PM Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
> >
> > On Mon, Dec 04, 2023 at 02:57:53PM +0100, Uros Bizjak wrote:
> > > On Mon, Dec 4, 2023 at 2:05 PM Luc Van Oostenryck <luc.vanoostenryck@gmail.com> wrote:
> > >
> > > __seg_gs qualified variables can be referenced anywhere in the code, e.g.:
> > >
> > > --cut here--
> > > __seg_gs int m;
> > >
> > > int foo (void)
> > > {
> > > return m + m;
> > > }
> >
> > Yes, of course. But my point was not if they *can* be dereferenced but rather
> > if *in the kernel, do want or not to use 'naked' __seg_gs qualified variable*.
> > In other words, do we want to be warned if someone, somewhere try to
> > dereference such qualified variable without using the accessor function?
> > And I think the answer to this question should be 'yes'.
>
> Not really - when used as e.g.:
>
> extern const struct pcpu_hot __seg_gs const_pcpu_hot;
>
> we can use variable directly, e.g.:
>
> return const_pcpu_hot.current_task;
>
> This way, the compiler is able to significantly reduce the number of
> loads from current_task, which is not achievable when the accessor is
> used to dereference the structure. In the x86/percpu branch, the
> number of loads from current_task were reduced from ~4700 to 3201 by
> using 'naked' __seg_gs qualified variable. IOW, the benefit of using
> __seg_gs is to be able to access the naked variable.
Additionally, the compiler checks access to this internal ("named")
address space, and will prevent dereference from "generic" address
space without appropriate casts. So, compiling:
--cut here--
__seg_gs int *m;
int *foo (void)
{
return m;
}
--cut here--
will generate "error: return from pointer to non-enclosed address space".
But the following is allowed:
int *foo (void)
{
return (int *)(unsigned long) m;
}
Uros.
prev parent reply other threads:[~2023-12-04 15:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <202310080853.UhMe5iWa-lkp@intel.com>
[not found] ` <CAFULd4ZgT1dZFz36ZbPeqJa+U2NwusSTudg175sSarhpvEu-Zw@mail.gmail.com>
2023-12-01 14:10 ` sparse: Expected ) at end of cast operator, got __seg_gs Uros Bizjak
2023-12-01 14:51 ` Dan Carpenter
2023-12-01 14:56 ` Uros Bizjak
2023-12-04 13:05 ` Luc Van Oostenryck
2023-12-04 13:57 ` Uros Bizjak
2023-12-04 14:37 ` Luc Van Oostenryck
2023-12-04 14:50 ` Uros Bizjak
2023-12-04 15:02 ` Uros Bizjak [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='CAFULd4buj4yX9Rgef1H3F4Sk042CaP1v=DwZBi=LHg1oEvQ2Sw@mail.gmail.com' \
--to=ubizjak@gmail.com \
--cc=dan.carpenter@linaro.org \
--cc=linux-sparse@vger.kernel.org \
--cc=luc.vanoostenryck@gmail.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).