Re: [Xen-devel] [PATCH v2 3/3] arm64: remove the rest of asm-uaccess.h

[Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>]

On Wed, Nov 27, 2019 at 11:03 AM Mark Rutland <mark.rutland@xxxxxxx> wrote:
>
> On Wed, Nov 27, 2019 at 10:31:54AM -0500, Pavel Tatashin wrote:
> > On Wed, Nov 27, 2019 at 10:12 AM Mark Rutland <mark.rutland@xxxxxxx> wrote:
> > >
> > > On Thu, Nov 21, 2019 at 09:24:06PM -0500, Pavel Tatashin wrote:
> > > > The __uaccess_ttbr0_disable and __uaccess_ttbr0_enable,
> > > > are the last two macros defined in asm-uaccess.h.
> > > >
> > > > Replace them with C wrappers and call C functions from
> > > > kernel_entry and kernel_exit.
> > >
> > > For now, please leave those as-is.
> > >
> > > I don't think we want to have out-of-line C wrappers in the middle of
> > > the entry assembly where we don't have a complete kernel environment.
> > > The use in entry code can also assume non-preemptibility, while the C
> > > functions have to explcitily disable that.
> >
> > I do not understand, if C function is called form non-preemptible
> > context it stays non-preemptible. kernel_exit already may call C
> > functions around the time __uaccess_ttbr0_enable is called (it may
> > call post_ttbr_update_workaround), and that C functions does not do
> > explicit preempt disable:
>
> Sorry, I meant that IRQs are disabled here.
>
> The C wrapper calls __uaccess_ttbr0_enable(), which calls
> local_irq_save() and local_irq_restore(). Those are pointless in the
> bowels of the entry code, and potentially expensive if IRQ prio masking
> is in use.
>
> I'd rather not add more out-of-line C code calls here right now as I'd
> prefer to factor out the logic to C in a better way.

Ah, yes, this makes sense. I could certainly factor out C calls in a
better way, or is this something you want to work on?

Without removing these assembly macros I do not think we want to
address this suggestion from Kees Cook:
https://lore.kernel.org/lkml/CA+CK2bCBS2fKOTmTFm13iv3u5TBPwpoCsYeeP352DVE-gs9GJw@xxxxxxxxxxxxxx/

Thank you,
Pasha

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel