On Mon, Dec 4, 2023 at 3:50 PM Uros Bizjak <ubizjak@xxxxxxxxx> wrote:
>
> On Mon, Dec 4, 2023 at 3:37 PM Luc Van Oostenryck
> <luc.vanoostenryck@xxxxxxxxx> 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@xxxxxxxxx> 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.
