Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
On Tue, Oct 01, 2019 at 03:39:41PM +0100, Julien Grall wrote:
> On 01/10/2019 15:33, Mark Rutland wrote:
> > On Sat, Sep 07, 2019 at 11:05:45AM +0100, Julien Grall wrote:
> > > On 9/6/19 6:20 PM, Andrew Cooper wrote:
> > > > On 06/09/2019 17:00, Arnd Bergmann wrote:
> > > > > On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper
> > > > > wrote:
> > > > > > On 06/09/2019 16:39, Arnd Bergmann wrote:
> > > > > > > HYPERVISOR_platform_op() is an inline function and should not
> > > > > > > be exported. Since commit 15bfc2348d54 ("modpost: check for
> > > > > > > static EXPORT_SYMBOL* functions"), this causes a warning:
> > > > > > >
> > > > > > > WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static
> > > > > > > EXPORT_SYMBOL_GPL
> > > > > > >
> > > > > > > Remove the extraneous export.
> > > > > > >
> > > > > > > Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL*
> > > > > > > functions")
> > > > > > > Signed-off-by: Arnd Bergmann
[...]
> > > While looking at the code, I also realized that the implementation of
> > > HYPERCALL_dm_op might be incorrect for Arm32. Similarly do privcmd call, I
> > > think dm_op call should enable user access as they will be used by
> > > userspace.
> > >
> > > We don't use dm_op on Arm so far, hence why I think this was unnoticed. I
> > > will see if I can reproduce it and send a patch.
> >
> > I'm seeing this when building arm64 defconfig v5.4-rc1:
> >
> > | [mark@lakrids:~/src/linux]% usekorg 8.1.0 make ARCH=arm64
> > CROSS_COMPILE=aarch64-linux- -j56 -s
> > | arch/arm64/Makefile:62: CROSS_COMPILE_COMPAT not defined or empty, the
> > compat vDSO will not be built
> > | WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
> > | WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
> >
> > I couldn't see a follow-up; do you have a patch for this?
>
> The first e-mail of the thread should contain a patch to address the warning
> (see [1]). But it is still waiting on an Ack from Stefano so it can get
> merged.
Ah, sorry. I misunderstood what you were planning to send a patch for,
and assumed you were going to propose an alternative to Arnd's patch.
Stefano, do you see any problem with Arnd's patch? If not, it would be
good to get this merged soon.
Thanks,
Mark.
>
> Cheers,
>
> [1] https://patchwork.kernel.org/patch/11135601/
>
> --
> Julien Grall
Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
On 01/10/2019 15:33, Mark Rutland wrote:
Hi Julien,
Hi Mark,
On Sat, Sep 07, 2019 at 11:05:45AM +0100, Julien Grall wrote:
On 9/6/19 6:20 PM, Andrew Cooper wrote:
On 06/09/2019 17:00, Arnd Bergmann wrote:
On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper wrote:
On 06/09/2019 16:39, Arnd Bergmann wrote:
HYPERVISOR_platform_op() is an inline function and should not
be exported. Since commit 15bfc2348d54 ("modpost: check for
static EXPORT_SYMBOL* functions"), this causes a warning:
WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
Remove the extraneous export.
Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
Signed-off-by: Arnd Bergmann
Something is wonky. That symbol is (/ really ought to be) in the
hypercall page and most definitely not inline.
Which tree is that changeset from? I can't find the SHA.
This is from linux-next, I think from the kbuild tree.
Thanks.
Julien/Stefano: Why are any of these hypercalls out-of-line? ARM
doesn't use the hypercall page, and there is no argument translation
(not even in arm32 as there are no 5-argument hypercalls declared).
I am not sure how the hypercall page makes things different. You still have
to store the arguments in the correct register so...
They'd surely be easier to implement with a few static inlines and some
common code, than to try and replicate the x86 side hypercall_page
interface ?
... I don't think they will be easier to implement with a few static
inlines. The implementation will likely end up to be similar to
arch/x86/asm/xen/hypercall.h.
Furthermore, one of the downside of per-arch static inline is it is more
difficult to ensure the prototype match for all the architectures. Although,
it might be possible to make them common by only requesting per-arch to
implement HYPERCALL_N(...).
So I think the code is better as it is.
While looking at the code, I also realized that the implementation of
HYPERCALL_dm_op might be incorrect for Arm32. Similarly do privcmd call, I
think dm_op call should enable user access as they will be used by
userspace.
We don't use dm_op on Arm so far, hence why I think this was unnoticed. I
will see if I can reproduce it and send a patch.
I'm seeing this when building arm64 defconfig v5.4-rc1:
| [mark@lakrids:~/src/linux]% usekorg 8.1.0 make ARCH=arm64
CROSS_COMPILE=aarch64-linux- -j56 -s
| arch/arm64/Makefile:62: CROSS_COMPILE_COMPAT not defined or empty, the compat
vDSO will not be built
| WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
| WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
I couldn't see a follow-up; do you have a patch for this?
The first e-mail of the thread should contain a patch to address the warning
(see [1]). But it is still waiting on an Ack from Stefano so it can get merged.
Cheers,
[1] https://patchwork.kernel.org/patch/11135601/
--
Julien Grall
Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
Hi Julien,
On Sat, Sep 07, 2019 at 11:05:45AM +0100, Julien Grall wrote:
> On 9/6/19 6:20 PM, Andrew Cooper wrote:
> > On 06/09/2019 17:00, Arnd Bergmann wrote:
> > > On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper
> > > wrote:
> > > > On 06/09/2019 16:39, Arnd Bergmann wrote:
> > > > > HYPERVISOR_platform_op() is an inline function and should not
> > > > > be exported. Since commit 15bfc2348d54 ("modpost: check for
> > > > > static EXPORT_SYMBOL* functions"), this causes a warning:
> > > > >
> > > > > WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static
> > > > > EXPORT_SYMBOL_GPL
> > > > >
> > > > > Remove the extraneous export.
> > > > >
> > > > > Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL*
> > > > > functions")
> > > > > Signed-off-by: Arnd Bergmann
> > > > Something is wonky. That symbol is (/ really ought to be) in the
> > > > hypercall page and most definitely not inline.
> > > >
> > > > Which tree is that changeset from? I can't find the SHA.
> > > This is from linux-next, I think from the kbuild tree.
> >
> > Thanks.
> >
> > Julien/Stefano: Why are any of these hypercalls out-of-line? ARM
> > doesn't use the hypercall page, and there is no argument translation
> > (not even in arm32 as there are no 5-argument hypercalls declared).
>
> I am not sure how the hypercall page makes things different. You still have
> to store the arguments in the correct register so...
>
> >
> > They'd surely be easier to implement with a few static inlines and some
> > common code, than to try and replicate the x86 side hypercall_page
> > interface ?
>
> ... I don't think they will be easier to implement with a few static
> inlines. The implementation will likely end up to be similar to
> arch/x86/asm/xen/hypercall.h.
>
> Furthermore, one of the downside of per-arch static inline is it is more
> difficult to ensure the prototype match for all the architectures. Although,
> it might be possible to make them common by only requesting per-arch to
> implement HYPERCALL_N(...).
>
> So I think the code is better as it is.
>
> While looking at the code, I also realized that the implementation of
> HYPERCALL_dm_op might be incorrect for Arm32. Similarly do privcmd call, I
> think dm_op call should enable user access as they will be used by
> userspace.
>
> We don't use dm_op on Arm so far, hence why I think this was unnoticed. I
> will see if I can reproduce it and send a patch.
I'm seeing this when building arm64 defconfig v5.4-rc1:
| [mark@lakrids:~/src/linux]% usekorg 8.1.0 make ARCH=arm64
CROSS_COMPILE=aarch64-linux- -j56 -s
| arch/arm64/Makefile:62: CROSS_COMPILE_COMPAT not defined or empty, the compat
vDSO will not be built
| WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
| WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
I couldn't see a follow-up; do you have a patch for this?
Thanks,
Mark.
Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
Hi Andrew,
On 9/6/19 6:20 PM, Andrew Cooper wrote:
On 06/09/2019 17:00, Arnd Bergmann wrote:
On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper wrote:
On 06/09/2019 16:39, Arnd Bergmann wrote:
HYPERVISOR_platform_op() is an inline function and should not
be exported. Since commit 15bfc2348d54 ("modpost: check for
static EXPORT_SYMBOL* functions"), this causes a warning:
WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
Remove the extraneous export.
Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
Signed-off-by: Arnd Bergmann
Something is wonky. That symbol is (/ really ought to be) in the
hypercall page and most definitely not inline.
Which tree is that changeset from? I can't find the SHA.
This is from linux-next, I think from the kbuild tree.
Thanks.
Julien/Stefano: Why are any of these hypercalls out-of-line? ARM
doesn't use the hypercall page, and there is no argument translation
(not even in arm32 as there are no 5-argument hypercalls declared).
I am not sure how the hypercall page makes things different. You still
have to store the arguments in the correct register so...
They'd surely be easier to implement with a few static inlines and some
common code, than to try and replicate the x86 side hypercall_page
interface ?
... I don't think they will be easier to implement with a few static
inlines. The implementation will likely end up to be similar to
arch/x86/asm/xen/hypercall.h.
Furthermore, one of the downside of per-arch static inline is it is more
difficult to ensure the prototype match for all the architectures.
Although, it might be possible to make them common by only requesting
per-arch to implement HYPERCALL_N(...).
So I think the code is better as it is.
While looking at the code, I also realized that the implementation of
HYPERCALL_dm_op might be incorrect for Arm32. Similarly do privcmd call,
I think dm_op call should enable user access as they will be used by
userspace.
We don't use dm_op on Arm so far, hence why I think this was unnoticed.
I will see if I can reproduce it and send a patch.
Cheers,
--
Julien Grall
Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
On 06/09/2019 17:00, Arnd Bergmann wrote:
> On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper
> wrote:
>> On 06/09/2019 16:39, Arnd Bergmann wrote:
>>> HYPERVISOR_platform_op() is an inline function and should not
>>> be exported. Since commit 15bfc2348d54 ("modpost: check for
>>> static EXPORT_SYMBOL* functions"), this causes a warning:
>>>
>>> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
>>>
>>> Remove the extraneous export.
>>>
>>> Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
>>> Signed-off-by: Arnd Bergmann
>> Something is wonky. That symbol is (/ really ought to be) in the
>> hypercall page and most definitely not inline.
>>
>> Which tree is that changeset from? I can't find the SHA.
> This is from linux-next, I think from the kbuild tree.
Thanks.
Julien/Stefano: Why are any of these hypercalls out-of-line? ARM
doesn't use the hypercall page, and there is no argument translation
(not even in arm32 as there are no 5-argument hypercalls declared).
They'd surely be easier to implement with a few static inlines and some
common code, than to try and replicate the x86 side hypercall_page
interface ?
~Andrew
Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper wrote:
>
> On 06/09/2019 16:39, Arnd Bergmann wrote:
> > HYPERVISOR_platform_op() is an inline function and should not
> > be exported. Since commit 15bfc2348d54 ("modpost: check for
> > static EXPORT_SYMBOL* functions"), this causes a warning:
> >
> > WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
> >
> > Remove the extraneous export.
> >
> > Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
> > Signed-off-by: Arnd Bergmann
>
> Something is wonky. That symbol is (/ really ought to be) in the
> hypercall page and most definitely not inline.
>
> Which tree is that changeset from? I can't find the SHA.
This is from linux-next, I think from the kbuild tree.
Arnd
Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
On 06.09.2019 17:55, Andrew Cooper wrote:
> On 06/09/2019 16:39, Arnd Bergmann wrote:
>> HYPERVISOR_platform_op() is an inline function and should not
>> be exported. Since commit 15bfc2348d54 ("modpost: check for
>> static EXPORT_SYMBOL* functions"), this causes a warning:
>>
>> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
>>
>> Remove the extraneous export.
>>
>> Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
>> Signed-off-by: Arnd Bergmann
>
> Something is wonky. That symbol is (/ really ought to be) in the
> hypercall page and most definitely not inline.
It's HYPERVISOR_platform_op_raw that's in the hypercall page afaics.
Jan
Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
On 06/09/2019 16:39, Arnd Bergmann wrote:
> HYPERVISOR_platform_op() is an inline function and should not
> be exported. Since commit 15bfc2348d54 ("modpost: check for
> static EXPORT_SYMBOL* functions"), this causes a warning:
>
> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
>
> Remove the extraneous export.
>
> Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
> Signed-off-by: Arnd Bergmann
Something is wonky. That symbol is (/ really ought to be) in the
hypercall page and most definitely not inline.
Which tree is that changeset from? I can't find the SHA.
I hate to open a separate can of worms, but why are they tagged GPL?
The Xen hypercall ABI, like the Linux syscall ABI, are specifically not
GPL. Xen has as something very similar to (and probably derived from)
the Linux-syscall-note exception.
~Andrew
