Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Ard Biesheuvel]

On Tue, 10 Nov 2020 at 08:44, Dmitry Osipenko  wrote:
>
> 09.11.2020 10:25, Ard Biesheuvel пишет:
> ...
> >>> So the options are
> >>>
> >>> a) merge my patch that adds 2 bytes of opcode to the Thumb2 build
> >>> b) merge Dmitry's patch that adds an unconditional literal load to all 
> >>> builds
> >>> c) remove kernel mode handling from vfp_support_entry() [my other patch]
> >>> d) move sections around so that vfp_kmode_exception is guaranteed to
> >>> be in range.
> >>> e) do nothing
> ...
> >> The performance argument is questionable to me, to be honest. In
> >> practice the performance difference should be absolutely negligible for
> >> either of the proposed options, it should stay in a noise even if
> >> somebody thoroughly counting cycles, IMO.
> >>
> >> I'm still thinking that the best option will be to apply a).
> >>
> >
> > Can we take that as an acked-by?
>
> Are you asking me for the ack?

Yes.

> I think this is a more appropriate
> question to Russel. I'm not arm/ maintainer, but could give r-b and t-b.
>

R-b and acked-by are basically the same thing.

> If you're going to follow approach that I'm suggesting with a) + d),
> then could you please resend the two patches in a single series? The
> first one-line patch-fix should contain the fixes tag.

Ok

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Dmitry Osipenko]

09.11.2020 10:25, Ard Biesheuvel пишет:
...
>>> So the options are
>>>
>>> a) merge my patch that adds 2 bytes of opcode to the Thumb2 build
>>> b) merge Dmitry's patch that adds an unconditional literal load to all 
>>> builds
>>> c) remove kernel mode handling from vfp_support_entry() [my other patch]
>>> d) move sections around so that vfp_kmode_exception is guaranteed to
>>> be in range.
>>> e) do nothing
...
>> The performance argument is questionable to me, to be honest. In
>> practice the performance difference should be absolutely negligible for
>> either of the proposed options, it should stay in a noise even if
>> somebody thoroughly counting cycles, IMO.
>>
>> I'm still thinking that the best option will be to apply a).
>>
> 
> Can we take that as an acked-by?

Are you asking me for the ack? I think this is a more appropriate
question to Russel. I'm not arm/ maintainer, but could give r-b and t-b.

If you're going to follow approach that I'm suggesting with a) + d),
then could you please resend the two patches in a single series? The
first one-line patch-fix should contain the fixes tag.

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Ard Biesheuvel]

On Tue, 3 Nov 2020 at 09:43, Dmitry Osipenko  wrote:
>
> 03.11.2020 10:24, Ard Biesheuvel пишет:
> > Still broken today
> >
> > https://kernelci.org/build/id/5fa0c1a74bdb1ea4063fe7e4/
> >

Still broken today

https://kernelci.org/build/id/5fa898baa00b5f3167db8857/

> > So the options are
> >
> > a) merge my patch that adds 2 bytes of opcode to the Thumb2 build
> > b) merge Dmitry's patch that adds an unconditional literal load to all 
> > builds
> > c) remove kernel mode handling from vfp_support_entry() [my other patch]
> > d) move sections around so that vfp_kmode_exception is guaranteed to
> > be in range.
> > e) do nothing
> >
> > Given the lack of reports about this issue, it is pretty clear that
> > few people use the Thumb2 build (which I find odd, tbh, since it
> > really is much smaller).
>
> I waited for about a month, hoping that somebody will fix this problem
> before bothering with bisection, which took quite some time and effort
> because intermediate commits were broken, and then with creating and
> sending a patch :)
>
> Thumb2 usually is untested by CI farms and in a case of personal use
> it's easier to wait for a fix. Hence no much reports, I suppose.
>
> > However, that means that a) is a reasonable
> > fix, since nobody will notice the potential performance hit either,
> > and it can easily be backported to wherever the breakage was
> > introduced. (Note that eff8728fe698, which created the problem is
> > marked cc:stable itself).
>
> The performance argument is questionable to me, to be honest. In
> practice the performance difference should be absolutely negligible for
> either of the proposed options, it should stay in a noise even if
> somebody thoroughly counting cycles, IMO.
>
> I'm still thinking that the best option will be to apply a).
>

Can we take that as an acked-by?

> > Going forward, I can refine d) so that we can get rid of the kernel
> > mode path entirely.
>
> And then improve it using d).

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Dmitry Osipenko]

03.11.2020 10:24, Ard Biesheuvel пишет:
> Still broken today
> 
> https://kernelci.org/build/id/5fa0c1a74bdb1ea4063fe7e4/
> 
> So the options are
> 
> a) merge my patch that adds 2 bytes of opcode to the Thumb2 build
> b) merge Dmitry's patch that adds an unconditional literal load to all builds
> c) remove kernel mode handling from vfp_support_entry() [my other patch]
> d) move sections around so that vfp_kmode_exception is guaranteed to
> be in range.
> e) do nothing
> 
> Given the lack of reports about this issue, it is pretty clear that
> few people use the Thumb2 build (which I find odd, tbh, since it
> really is much smaller).

I waited for about a month, hoping that somebody will fix this problem
before bothering with bisection, which took quite some time and effort
because intermediate commits were broken, and then with creating and
sending a patch :)

Thumb2 usually is untested by CI farms and in a case of personal use
it's easier to wait for a fix. Hence no much reports, I suppose.

> However, that means that a) is a reasonable
> fix, since nobody will notice the potential performance hit either,
> and it can easily be backported to wherever the breakage was
> introduced. (Note that eff8728fe698, which created the problem is
> marked cc:stable itself).

The performance argument is questionable to me, to be honest. In
practice the performance difference should be absolutely negligible for
either of the proposed options, it should stay in a noise even if
somebody thoroughly counting cycles, IMO.

I'm still thinking that the best option will be to apply a).

> Going forward, I can refine d) so that we can get rid of the kernel
> mode path entirely.

And then improve it using d).

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Ard Biesheuvel]

On Thu, 29 Oct 2020 at 10:56, Ard Biesheuvel  wrote:
>
> On Mon, 26 Oct 2020 at 09:58, Ard Biesheuvel  wrote:
> >
> > On Thu, 22 Oct 2020 at 19:59, Ard Biesheuvel  wrote:
> > >
> > > On Thu, 22 Oct 2020 at 19:48, Russell King - ARM Linux admin
> > >  wrote:
> > > >
> > > > On Thu, Oct 22, 2020 at 06:33:17PM +0200, Ard Biesheuvel wrote:
> > > > > On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
> > > > >  wrote:
> > > > > >
> > > > > > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > > > > > > On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > > > > > > > > On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > > > > > > > > > On Thu, 22 Oct 2020 at 05:30, Kees Cook 
> > > > > > > > > > >  wrote:
> > > > > > > > > > >>
> > > > > > > > > > >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry 
> > > > > > > > > > >> Osipenko wrote:
> > > > > > > > > > >>> 22.10.2020 02:40, Kees Cook пишет:
> > > > > > > > > >  On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry 
> > > > > > > > > >  Osipenko wrote:
> > > > > > > > > > > The vfp_kmode_exception() function now is unreachable 
> > > > > > > > > > > using relative
> > > > > > > > > > > branching in THUMB2 kernel configuration, resulting 
> > > > > > > > > > > in a "relocation
> > > > > > > > > > > truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > > > > > > > > > > `vfp_kmode_exception'"
> > > > > > > > > > > linker error. Let's use long jump in order to fix the 
> > > > > > > > > > > issue.
> > > > > > > > > > 
> > > > > > > > > >  Eek. Is this with gcc or clang?
> > > > > > > > > > >>>
> > > > > > > > > > >>> GCC 9.3.0
> > > > > > > > > > >>>
> > > > > > > > > > > Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and 
> > > > > > > > > > > AutoFDO input sections")
> > > > > > > > > > 
> > > > > > > > > >  Are you sure it wasn't 512dd2eebe55 ("arm/build: Add 
> > > > > > > > > >  missing sections") ?
> > > > > > > > > >  That commit may have implicitly moved the location of 
> > > > > > > > > >  .vfp11_veneer,
> > > > > > > > > >  though I thought I had chosen the correct position.
> > > > > > > > > > >>>
> > > > > > > > > > >>> I re-checked that the fixes tag is correct.
> > > > > > > > > > >>>
> > > > > > > > > > > Signed-off-by: Dmitry Osipenko 
> > > > > > > > > > > ---
> > > > > > > > > > >  arch/arm/vfp/vfphw.S | 3 ++-
> > > > > > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/arch/arm/vfp/vfphw.S 
> > > > > > > > > > > b/arch/arm/vfp/vfphw.S
> > > > > > > > > > > index 4fcff9f59947..6e2b29f0c48d 100644
> > > > > > > > > > > --- a/arch/arm/vfp/vfphw.S
> > > > > > > > > > > +++ b/arch/arm/vfp/vfphw.S
> > > > > > > > > > > @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > > > > > > > > > >ldr r3, [sp, #S_PSR]@ Neither lazy 
> > > > > > > > > > > restore nor FP exceptions
> > > > > > > > > > >and r3, r3, #MODE_MASK  @ are supported in 
> > > > > > > > > > > kernel mode
> > > > > > > > > > >teq r3, #USR_MODE
> > > > > > > > > > > -  bne vfp_kmode_exception @ Returns through 
> > > > > > > > > > > lr
> > > > > > > > > > > +  ldr r1, =vfp_kmode_exception
> > > > > > > > > > > +  bxner1  @ Returns through 
> > > > > > > > > > > lr
> > > > > > > > > > >
> > > > > > > > > > >VFPFMRX r1, FPEXC   @ Is the VFP 
> > > > > > > > > > > enabled?
> > > > > > > > > > >DBGSTR1 "fpexc %08x", r1
> > > > > > > > > > 
> > > > > > > > > >  This seems like a workaround though? I suspect the 
> > > > > > > > > >  vfp11_veneer needs
> > > > > > > > > >  moving?
> > > > > > > > > > 
> > > > > > > > > > >>>
> > > > > > > > > > >>> I don't know where it needs to be moved. Please feel 
> > > > > > > > > > >>> free to make a
> > > > > > > > > > >>> patch if you have a better idea, I'll be glad to test 
> > > > > > > > > > >>> it.
> > > > > > > > > > >>
> > > > > > > > > > >> I might have just been distracted by the common "vfp" 
> > > > > > > > > > >> prefix. It's
> > > > > > > > > > >> possible that the text section shuffling just ended up 
> > > > > > > > > > >> being very large,
> > > > > > > > > > >> so probably this patch is right then!
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > > > I already sent a fix for this issue:
> > > > > > > > > > >
> > > > > > > > > > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > The offending commit contains stable tag, so I assume that 
> > 

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Ard Biesheuvel]

On Mon, 26 Oct 2020 at 09:58, Ard Biesheuvel  wrote:
>
> On Thu, 22 Oct 2020 at 19:59, Ard Biesheuvel  wrote:
> >
> > On Thu, 22 Oct 2020 at 19:48, Russell King - ARM Linux admin
> >  wrote:
> > >
> > > On Thu, Oct 22, 2020 at 06:33:17PM +0200, Ard Biesheuvel wrote:
> > > > On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
> > > >  wrote:
> > > > >
> > > > > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > > > > > On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > > > > > > > On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > > > > > > > > On Thu, 22 Oct 2020 at 05:30, Kees Cook 
> > > > > > > > > >  wrote:
> > > > > > > > > >>
> > > > > > > > > >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko 
> > > > > > > > > >> wrote:
> > > > > > > > > >>> 22.10.2020 02:40, Kees Cook пишет:
> > > > > > > > >  On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry 
> > > > > > > > >  Osipenko wrote:
> > > > > > > > > > The vfp_kmode_exception() function now is unreachable 
> > > > > > > > > > using relative
> > > > > > > > > > branching in THUMB2 kernel configuration, resulting in 
> > > > > > > > > > a "relocation
> > > > > > > > > > truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > > > > > > > > > `vfp_kmode_exception'"
> > > > > > > > > > linker error. Let's use long jump in order to fix the 
> > > > > > > > > > issue.
> > > > > > > > > 
> > > > > > > > >  Eek. Is this with gcc or clang?
> > > > > > > > > >>>
> > > > > > > > > >>> GCC 9.3.0
> > > > > > > > > >>>
> > > > > > > > > > Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and 
> > > > > > > > > > AutoFDO input sections")
> > > > > > > > > 
> > > > > > > > >  Are you sure it wasn't 512dd2eebe55 ("arm/build: Add 
> > > > > > > > >  missing sections") ?
> > > > > > > > >  That commit may have implicitly moved the location of 
> > > > > > > > >  .vfp11_veneer,
> > > > > > > > >  though I thought I had chosen the correct position.
> > > > > > > > > >>>
> > > > > > > > > >>> I re-checked that the fixes tag is correct.
> > > > > > > > > >>>
> > > > > > > > > > Signed-off-by: Dmitry Osipenko 
> > > > > > > > > > ---
> > > > > > > > > >  arch/arm/vfp/vfphw.S | 3 ++-
> > > > > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > > > > > > > > > index 4fcff9f59947..6e2b29f0c48d 100644
> > > > > > > > > > --- a/arch/arm/vfp/vfphw.S
> > > > > > > > > > +++ b/arch/arm/vfp/vfphw.S
> > > > > > > > > > @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > > > > > > > > >ldr r3, [sp, #S_PSR]@ Neither lazy 
> > > > > > > > > > restore nor FP exceptions
> > > > > > > > > >and r3, r3, #MODE_MASK  @ are supported in 
> > > > > > > > > > kernel mode
> > > > > > > > > >teq r3, #USR_MODE
> > > > > > > > > > -  bne vfp_kmode_exception @ Returns through lr
> > > > > > > > > > +  ldr r1, =vfp_kmode_exception
> > > > > > > > > > +  bxner1  @ Returns through lr
> > > > > > > > > >
> > > > > > > > > >VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> > > > > > > > > >DBGSTR1 "fpexc %08x", r1
> > > > > > > > > 
> > > > > > > > >  This seems like a workaround though? I suspect the 
> > > > > > > > >  vfp11_veneer needs
> > > > > > > > >  moving?
> > > > > > > > > 
> > > > > > > > > >>>
> > > > > > > > > >>> I don't know where it needs to be moved. Please feel free 
> > > > > > > > > >>> to make a
> > > > > > > > > >>> patch if you have a better idea, I'll be glad to test it.
> > > > > > > > > >>
> > > > > > > > > >> I might have just been distracted by the common "vfp" 
> > > > > > > > > >> prefix. It's
> > > > > > > > > >> possible that the text section shuffling just ended up 
> > > > > > > > > >> being very large,
> > > > > > > > > >> so probably this patch is right then!
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > > I already sent a fix for this issue:
> > > > > > > > > >
> > > > > > > > > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > The offending commit contains stable tag, so I assume that 
> > > > > > > > > fixes tag is
> > > > > > > > > mandatory. Yours patch misses the fixes tag.
> > > > > > > >
> > > > > > > > Russell, mind adding that? Or would you like me to update the 
> > > > > > > > patch in
> > > > > > > > the patch system?
> > > > > > >
> > > > > > > Rather than adding the IT, I'm suggesting that we solve it a 
> > > > > > > different
> > > > > > > way - 

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Ard Biesheuvel]

On Thu, 22 Oct 2020 at 19:59, Ard Biesheuvel  wrote:
>
> On Thu, 22 Oct 2020 at 19:48, Russell King - ARM Linux admin
>  wrote:
> >
> > On Thu, Oct 22, 2020 at 06:33:17PM +0200, Ard Biesheuvel wrote:
> > > On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
> > >  wrote:
> > > >
> > > > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > > > > On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > > > >  wrote:
> > > > > >
> > > > > > On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > > > > > > On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > > > > > > > On Thu, 22 Oct 2020 at 05:30, Kees Cook 
> > > > > > > > >  wrote:
> > > > > > > > >>
> > > > > > > > >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko 
> > > > > > > > >> wrote:
> > > > > > > > >>> 22.10.2020 02:40, Kees Cook пишет:
> > > > > > > >  On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko 
> > > > > > > >  wrote:
> > > > > > > > > The vfp_kmode_exception() function now is unreachable 
> > > > > > > > > using relative
> > > > > > > > > branching in THUMB2 kernel configuration, resulting in a 
> > > > > > > > > "relocation
> > > > > > > > > truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > > > > > > > > `vfp_kmode_exception'"
> > > > > > > > > linker error. Let's use long jump in order to fix the 
> > > > > > > > > issue.
> > > > > > > > 
> > > > > > > >  Eek. Is this with gcc or clang?
> > > > > > > > >>>
> > > > > > > > >>> GCC 9.3.0
> > > > > > > > >>>
> > > > > > > > > Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO 
> > > > > > > > > input sections")
> > > > > > > > 
> > > > > > > >  Are you sure it wasn't 512dd2eebe55 ("arm/build: Add 
> > > > > > > >  missing sections") ?
> > > > > > > >  That commit may have implicitly moved the location of 
> > > > > > > >  .vfp11_veneer,
> > > > > > > >  though I thought I had chosen the correct position.
> > > > > > > > >>>
> > > > > > > > >>> I re-checked that the fixes tag is correct.
> > > > > > > > >>>
> > > > > > > > > Signed-off-by: Dmitry Osipenko 
> > > > > > > > > ---
> > > > > > > > >  arch/arm/vfp/vfphw.S | 3 ++-
> > > > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > > > > > > > > index 4fcff9f59947..6e2b29f0c48d 100644
> > > > > > > > > --- a/arch/arm/vfp/vfphw.S
> > > > > > > > > +++ b/arch/arm/vfp/vfphw.S
> > > > > > > > > @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > > > > > > > >ldr r3, [sp, #S_PSR]@ Neither lazy restore 
> > > > > > > > > nor FP exceptions
> > > > > > > > >and r3, r3, #MODE_MASK  @ are supported in 
> > > > > > > > > kernel mode
> > > > > > > > >teq r3, #USR_MODE
> > > > > > > > > -  bne vfp_kmode_exception @ Returns through lr
> > > > > > > > > +  ldr r1, =vfp_kmode_exception
> > > > > > > > > +  bxner1  @ Returns through lr
> > > > > > > > >
> > > > > > > > >VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> > > > > > > > >DBGSTR1 "fpexc %08x", r1
> > > > > > > > 
> > > > > > > >  This seems like a workaround though? I suspect the 
> > > > > > > >  vfp11_veneer needs
> > > > > > > >  moving?
> > > > > > > > 
> > > > > > > > >>>
> > > > > > > > >>> I don't know where it needs to be moved. Please feel free 
> > > > > > > > >>> to make a
> > > > > > > > >>> patch if you have a better idea, I'll be glad to test it.
> > > > > > > > >>
> > > > > > > > >> I might have just been distracted by the common "vfp" 
> > > > > > > > >> prefix. It's
> > > > > > > > >> possible that the text section shuffling just ended up being 
> > > > > > > > >> very large,
> > > > > > > > >> so probably this patch is right then!
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > > I already sent a fix for this issue:
> > > > > > > > >
> > > > > > > > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > > > > > > > >
> > > > > > > >
> > > > > > > > The offending commit contains stable tag, so I assume that 
> > > > > > > > fixes tag is
> > > > > > > > mandatory. Yours patch misses the fixes tag.
> > > > > > >
> > > > > > > Russell, mind adding that? Or would you like me to update the 
> > > > > > > patch in
> > > > > > > the patch system?
> > > > > >
> > > > > > Rather than adding the IT, I'm suggesting that we solve it a 
> > > > > > different
> > > > > > way - ensuring that the two bits of code are co-located. There's no
> > > > > > reason for them to be separated, and the assembly code entry point 
> > > > > > is
> > > > > > already called indirectly.
> > > > > >
> > > > > > The problem is the assembly ends up in the 

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Dmitry Osipenko]

22.10.2020 20:38, Russell King - ARM Linux admin пишет:
...
>> But the two line change isn't portable to stable kernels as-is, isn't it?
> 
> Why not?
> 

I assume we will need to define a new section, no?

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Ard Biesheuvel]

On Thu, 22 Oct 2020 at 19:48, Russell King - ARM Linux admin
 wrote:
>
> On Thu, Oct 22, 2020 at 06:33:17PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
> >  wrote:
> > >
> > > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > > > On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > > >  wrote:
> > > > >
> > > > > On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > > > > > On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  
> > > > > > wrote:
> > > > > > >
> > > > > > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > > > > > > On Thu, 22 Oct 2020 at 05:30, Kees Cook  
> > > > > > > > wrote:
> > > > > > > >>
> > > > > > > >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko 
> > > > > > > >> wrote:
> > > > > > > >>> 22.10.2020 02:40, Kees Cook пишет:
> > > > > > >  On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko 
> > > > > > >  wrote:
> > > > > > > > The vfp_kmode_exception() function now is unreachable using 
> > > > > > > > relative
> > > > > > > > branching in THUMB2 kernel configuration, resulting in a 
> > > > > > > > "relocation
> > > > > > > > truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > > > > > > > `vfp_kmode_exception'"
> > > > > > > > linker error. Let's use long jump in order to fix the issue.
> > > > > > > 
> > > > > > >  Eek. Is this with gcc or clang?
> > > > > > > >>>
> > > > > > > >>> GCC 9.3.0
> > > > > > > >>>
> > > > > > > > Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO 
> > > > > > > > input sections")
> > > > > > > 
> > > > > > >  Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing 
> > > > > > >  sections") ?
> > > > > > >  That commit may have implicitly moved the location of 
> > > > > > >  .vfp11_veneer,
> > > > > > >  though I thought I had chosen the correct position.
> > > > > > > >>>
> > > > > > > >>> I re-checked that the fixes tag is correct.
> > > > > > > >>>
> > > > > > > > Signed-off-by: Dmitry Osipenko 
> > > > > > > > ---
> > > > > > > >  arch/arm/vfp/vfphw.S | 3 ++-
> > > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > > > > > > > index 4fcff9f59947..6e2b29f0c48d 100644
> > > > > > > > --- a/arch/arm/vfp/vfphw.S
> > > > > > > > +++ b/arch/arm/vfp/vfphw.S
> > > > > > > > @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > > > > > > >ldr r3, [sp, #S_PSR]@ Neither lazy restore 
> > > > > > > > nor FP exceptions
> > > > > > > >and r3, r3, #MODE_MASK  @ are supported in 
> > > > > > > > kernel mode
> > > > > > > >teq r3, #USR_MODE
> > > > > > > > -  bne vfp_kmode_exception @ Returns through lr
> > > > > > > > +  ldr r1, =vfp_kmode_exception
> > > > > > > > +  bxner1  @ Returns through lr
> > > > > > > >
> > > > > > > >VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> > > > > > > >DBGSTR1 "fpexc %08x", r1
> > > > > > > 
> > > > > > >  This seems like a workaround though? I suspect the 
> > > > > > >  vfp11_veneer needs
> > > > > > >  moving?
> > > > > > > 
> > > > > > > >>>
> > > > > > > >>> I don't know where it needs to be moved. Please feel free to 
> > > > > > > >>> make a
> > > > > > > >>> patch if you have a better idea, I'll be glad to test it.
> > > > > > > >>
> > > > > > > >> I might have just been distracted by the common "vfp" prefix. 
> > > > > > > >> It's
> > > > > > > >> possible that the text section shuffling just ended up being 
> > > > > > > >> very large,
> > > > > > > >> so probably this patch is right then!
> > > > > > > >>
> > > > > > > >
> > > > > > > > I already sent a fix for this issue:
> > > > > > > >
> > > > > > > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > > > > > > >
> > > > > > >
> > > > > > > The offending commit contains stable tag, so I assume that fixes 
> > > > > > > tag is
> > > > > > > mandatory. Yours patch misses the fixes tag.
> > > > > >
> > > > > > Russell, mind adding that? Or would you like me to update the patch 
> > > > > > in
> > > > > > the patch system?
> > > > >
> > > > > Rather than adding the IT, I'm suggesting that we solve it a different
> > > > > way - ensuring that the two bits of code are co-located. There's no
> > > > > reason for them to be separated, and the assembly code entry point is
> > > > > already called indirectly.
> > > > >
> > > > > The problem is the assembly ends up in the .text section which ends up
> > > > > at the start of the binary, but depending on the compiler, functions
> > > > > in .c files end up in their own sections. It would be good if, as
> > > > > Dmitry has shown that it is indeed possible, to have them co-located.
> > > >
> > > > Why is that better? I provided a 

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Ard Biesheuvel]

On Thu, 22 Oct 2020 at 19:50, Russell King - ARM Linux admin
 wrote:
>
> On Thu, Oct 22, 2020 at 07:47:57PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Oct 2020 at 19:38, Russell King - ARM Linux admin
> >  wrote:
> > >
> > > On Thu, Oct 22, 2020 at 07:34:38PM +0300, Dmitry Osipenko wrote:
> > > > 22.10.2020 19:23, Russell King - ARM Linux admin пишет:
> > > > > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > > > >> On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > > > >>  wrote:
> > > > >>>
> > > > >>> On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > > >  On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  
> > > >  wrote:
> > > > >
> > > > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > > >> On Thu, 22 Oct 2020 at 05:30, Kees Cook  
> > > > >> wrote:
> > > > >>>
> > > > >>> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> > > >  22.10.2020 02:40, Kees Cook пишет:
> > > > > On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko 
> > > > > wrote:
> > > > >> The vfp_kmode_exception() function now is unreachable using 
> > > > >> relative
> > > > >> branching in THUMB2 kernel configuration, resulting in a 
> > > > >> "relocation
> > > > >> truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > > > >> `vfp_kmode_exception'"
> > > > >> linker error. Let's use long jump in order to fix the issue.
> > > > >
> > > > > Eek. Is this with gcc or clang?
> > > > 
> > > >  GCC 9.3.0
> > > > 
> > > > >> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO 
> > > > >> input sections")
> > > > >
> > > > > Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing 
> > > > > sections") ?
> > > > > That commit may have implicitly moved the location of 
> > > > > .vfp11_veneer,
> > > > > though I thought I had chosen the correct position.
> > > > 
> > > >  I re-checked that the fixes tag is correct.
> > > > 
> > > > >> Signed-off-by: Dmitry Osipenko 
> > > > >> ---
> > > > >>  arch/arm/vfp/vfphw.S | 3 ++-
> > > > >>  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >>
> > > > >> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > > > >> index 4fcff9f59947..6e2b29f0c48d 100644
> > > > >> --- a/arch/arm/vfp/vfphw.S
> > > > >> +++ b/arch/arm/vfp/vfphw.S
> > > > >> @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > > > >>ldr r3, [sp, #S_PSR]@ Neither lazy restore 
> > > > >> nor FP exceptions
> > > > >>and r3, r3, #MODE_MASK  @ are supported in kernel 
> > > > >> mode
> > > > >>teq r3, #USR_MODE
> > > > >> -  bne vfp_kmode_exception @ Returns through lr
> > > > >> +  ldr r1, =vfp_kmode_exception
> > > > >> +  bxner1  @ Returns through lr
> > > > >>
> > > > >>VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> > > > >>DBGSTR1 "fpexc %08x", r1
> > > > >
> > > > > This seems like a workaround though? I suspect the 
> > > > > vfp11_veneer needs
> > > > > moving?
> > > > >
> > > > 
> > > >  I don't know where it needs to be moved. Please feel free to 
> > > >  make a
> > > >  patch if you have a better idea, I'll be glad to test it.
> > > > >>>
> > > > >>> I might have just been distracted by the common "vfp" prefix. 
> > > > >>> It's
> > > > >>> possible that the text section shuffling just ended up being 
> > > > >>> very large,
> > > > >>> so probably this patch is right then!
> > > > >>>
> > > > >>
> > > > >> I already sent a fix for this issue:
> > > > >>
> > > > >> https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > > > >>
> > > > >
> > > > > The offending commit contains stable tag, so I assume that fixes 
> > > > > tag is
> > > > > mandatory. Yours patch misses the fixes tag.
> > > > 
> > > >  Russell, mind adding that? Or would you like me to update the 
> > > >  patch in
> > > >  the patch system?
> > > > >>>
> > > > >>> Rather than adding the IT, I'm suggesting that we solve it a 
> > > > >>> different
> > > > >>> way - ensuring that the two bits of code are co-located. There's no
> > > > >>> reason for them to be separated, and the assembly code entry point 
> > > > >>> is
> > > > >>> already called indirectly.
> > > > >>>
> > > > >>> The problem is the assembly ends up in the .text section which ends 
> > > > >>> up
> > > > >>> at the start of the binary, but depending on the compiler, functions
> > > > >>> in .c files end up in their own sections. It would be good if, as
> > > > 

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Russell King - ARM Linux admin]

On Thu, Oct 22, 2020 at 07:47:57PM +0200, Ard Biesheuvel wrote:
> On Thu, 22 Oct 2020 at 19:38, Russell King - ARM Linux admin
>  wrote:
> >
> > On Thu, Oct 22, 2020 at 07:34:38PM +0300, Dmitry Osipenko wrote:
> > > 22.10.2020 19:23, Russell King - ARM Linux admin пишет:
> > > > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > > >> On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > > >>  wrote:
> > > >>>
> > > >>> On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > >  On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  
> > >  wrote:
> > > >
> > > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > >> On Thu, 22 Oct 2020 at 05:30, Kees Cook  
> > > >> wrote:
> > > >>>
> > > >>> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> > >  22.10.2020 02:40, Kees Cook пишет:
> > > > On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> > > >> The vfp_kmode_exception() function now is unreachable using 
> > > >> relative
> > > >> branching in THUMB2 kernel configuration, resulting in a 
> > > >> "relocation
> > > >> truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > > >> `vfp_kmode_exception'"
> > > >> linker error. Let's use long jump in order to fix the issue.
> > > >
> > > > Eek. Is this with gcc or clang?
> > > 
> > >  GCC 9.3.0
> > > 
> > > >> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input 
> > > >> sections")
> > > >
> > > > Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing 
> > > > sections") ?
> > > > That commit may have implicitly moved the location of 
> > > > .vfp11_veneer,
> > > > though I thought I had chosen the correct position.
> > > 
> > >  I re-checked that the fixes tag is correct.
> > > 
> > > >> Signed-off-by: Dmitry Osipenko 
> > > >> ---
> > > >>  arch/arm/vfp/vfphw.S | 3 ++-
> > > >>  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > > >> index 4fcff9f59947..6e2b29f0c48d 100644
> > > >> --- a/arch/arm/vfp/vfphw.S
> > > >> +++ b/arch/arm/vfp/vfphw.S
> > > >> @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > > >>ldr r3, [sp, #S_PSR]@ Neither lazy restore nor 
> > > >> FP exceptions
> > > >>and r3, r3, #MODE_MASK  @ are supported in kernel 
> > > >> mode
> > > >>teq r3, #USR_MODE
> > > >> -  bne vfp_kmode_exception @ Returns through lr
> > > >> +  ldr r1, =vfp_kmode_exception
> > > >> +  bxner1  @ Returns through lr
> > > >>
> > > >>VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> > > >>DBGSTR1 "fpexc %08x", r1
> > > >
> > > > This seems like a workaround though? I suspect the vfp11_veneer 
> > > > needs
> > > > moving?
> > > >
> > > 
> > >  I don't know where it needs to be moved. Please feel free to 
> > >  make a
> > >  patch if you have a better idea, I'll be glad to test it.
> > > >>>
> > > >>> I might have just been distracted by the common "vfp" prefix. It's
> > > >>> possible that the text section shuffling just ended up being very 
> > > >>> large,
> > > >>> so probably this patch is right then!
> > > >>>
> > > >>
> > > >> I already sent a fix for this issue:
> > > >>
> > > >> https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > > >>
> > > >
> > > > The offending commit contains stable tag, so I assume that fixes 
> > > > tag is
> > > > mandatory. Yours patch misses the fixes tag.
> > > 
> > >  Russell, mind adding that? Or would you like me to update the patch 
> > >  in
> > >  the patch system?
> > > >>>
> > > >>> Rather than adding the IT, I'm suggesting that we solve it a different
> > > >>> way - ensuring that the two bits of code are co-located. There's no
> > > >>> reason for them to be separated, and the assembly code entry point is
> > > >>> already called indirectly.
> > > >>>
> > > >>> The problem is the assembly ends up in the .text section which ends up
> > > >>> at the start of the binary, but depending on the compiler, functions
> > > >>> in .c files end up in their own sections. It would be good if, as
> > > >>> Dmitry has shown that it is indeed possible, to have them co-located.
> > > >>
> > > >> Why is that better? I provided a minimal fix which has zero impact on
> > > >> ARM builds, and minimal impact on Thumb2 builds, given that it retains
> > > >> the exact same semantics as before, but using a different opcode.
> > > >
> > > > I think you just 

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Russell King - ARM Linux admin]

On Thu, Oct 22, 2020 at 06:33:17PM +0200, Ard Biesheuvel wrote:
> On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
>  wrote:
> >
> > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > > On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > >  wrote:
> > > >
> > > > On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > > > > On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  
> > > > > wrote:
> > > > > >
> > > > > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > > > > > On Thu, 22 Oct 2020 at 05:30, Kees Cook  
> > > > > > > wrote:
> > > > > > >>
> > > > > > >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> > > > > > >>> 22.10.2020 02:40, Kees Cook пишет:
> > > > > >  On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko 
> > > > > >  wrote:
> > > > > > > The vfp_kmode_exception() function now is unreachable using 
> > > > > > > relative
> > > > > > > branching in THUMB2 kernel configuration, resulting in a 
> > > > > > > "relocation
> > > > > > > truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > > > > > > `vfp_kmode_exception'"
> > > > > > > linker error. Let's use long jump in order to fix the issue.
> > > > > > 
> > > > > >  Eek. Is this with gcc or clang?
> > > > > > >>>
> > > > > > >>> GCC 9.3.0
> > > > > > >>>
> > > > > > > Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO 
> > > > > > > input sections")
> > > > > > 
> > > > > >  Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing 
> > > > > >  sections") ?
> > > > > >  That commit may have implicitly moved the location of 
> > > > > >  .vfp11_veneer,
> > > > > >  though I thought I had chosen the correct position.
> > > > > > >>>
> > > > > > >>> I re-checked that the fixes tag is correct.
> > > > > > >>>
> > > > > > > Signed-off-by: Dmitry Osipenko 
> > > > > > > ---
> > > > > > >  arch/arm/vfp/vfphw.S | 3 ++-
> > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > > > > > > index 4fcff9f59947..6e2b29f0c48d 100644
> > > > > > > --- a/arch/arm/vfp/vfphw.S
> > > > > > > +++ b/arch/arm/vfp/vfphw.S
> > > > > > > @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > > > > > >ldr r3, [sp, #S_PSR]@ Neither lazy restore nor 
> > > > > > > FP exceptions
> > > > > > >and r3, r3, #MODE_MASK  @ are supported in kernel 
> > > > > > > mode
> > > > > > >teq r3, #USR_MODE
> > > > > > > -  bne vfp_kmode_exception @ Returns through lr
> > > > > > > +  ldr r1, =vfp_kmode_exception
> > > > > > > +  bxner1  @ Returns through lr
> > > > > > >
> > > > > > >VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> > > > > > >DBGSTR1 "fpexc %08x", r1
> > > > > > 
> > > > > >  This seems like a workaround though? I suspect the 
> > > > > >  vfp11_veneer needs
> > > > > >  moving?
> > > > > > 
> > > > > > >>>
> > > > > > >>> I don't know where it needs to be moved. Please feel free to 
> > > > > > >>> make a
> > > > > > >>> patch if you have a better idea, I'll be glad to test it.
> > > > > > >>
> > > > > > >> I might have just been distracted by the common "vfp" prefix. 
> > > > > > >> It's
> > > > > > >> possible that the text section shuffling just ended up being 
> > > > > > >> very large,
> > > > > > >> so probably this patch is right then!
> > > > > > >>
> > > > > > >
> > > > > > > I already sent a fix for this issue:
> > > > > > >
> > > > > > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > > > > > >
> > > > > >
> > > > > > The offending commit contains stable tag, so I assume that fixes 
> > > > > > tag is
> > > > > > mandatory. Yours patch misses the fixes tag.
> > > > >
> > > > > Russell, mind adding that? Or would you like me to update the patch in
> > > > > the patch system?
> > > >
> > > > Rather than adding the IT, I'm suggesting that we solve it a different
> > > > way - ensuring that the two bits of code are co-located. There's no
> > > > reason for them to be separated, and the assembly code entry point is
> > > > already called indirectly.
> > > >
> > > > The problem is the assembly ends up in the .text section which ends up
> > > > at the start of the binary, but depending on the compiler, functions
> > > > in .c files end up in their own sections. It would be good if, as
> > > > Dmitry has shown that it is indeed possible, to have them co-located.
> > >
> > > Why is that better? I provided a minimal fix which has zero impact on
> > > ARM builds, and minimal impact on Thumb2 builds, given that it retains
> > > the exact same semantics as before, but using a different opcode.
> >
> > I think you just described the reason there. Why should we force
> > everything to use a different opcode when a short 

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Ard Biesheuvel]

On Thu, 22 Oct 2020 at 19:38, Russell King - ARM Linux admin
 wrote:
>
> On Thu, Oct 22, 2020 at 07:34:38PM +0300, Dmitry Osipenko wrote:
> > 22.10.2020 19:23, Russell King - ARM Linux admin пишет:
> > > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > >> On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > >>  wrote:
> > >>>
> > >>> On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> >  On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  wrote:
> > >
> > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > >> On Thu, 22 Oct 2020 at 05:30, Kees Cook  
> > >> wrote:
> > >>>
> > >>> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> >  22.10.2020 02:40, Kees Cook пишет:
> > > On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> > >> The vfp_kmode_exception() function now is unreachable using 
> > >> relative
> > >> branching in THUMB2 kernel configuration, resulting in a 
> > >> "relocation
> > >> truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > >> `vfp_kmode_exception'"
> > >> linker error. Let's use long jump in order to fix the issue.
> > >
> > > Eek. Is this with gcc or clang?
> > 
> >  GCC 9.3.0
> > 
> > >> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input 
> > >> sections")
> > >
> > > Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing 
> > > sections") ?
> > > That commit may have implicitly moved the location of 
> > > .vfp11_veneer,
> > > though I thought I had chosen the correct position.
> > 
> >  I re-checked that the fixes tag is correct.
> > 
> > >> Signed-off-by: Dmitry Osipenko 
> > >> ---
> > >>  arch/arm/vfp/vfphw.S | 3 ++-
> > >>  1 file changed, 2 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > >> index 4fcff9f59947..6e2b29f0c48d 100644
> > >> --- a/arch/arm/vfp/vfphw.S
> > >> +++ b/arch/arm/vfp/vfphw.S
> > >> @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > >>ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP 
> > >> exceptions
> > >>and r3, r3, #MODE_MASK  @ are supported in kernel mode
> > >>teq r3, #USR_MODE
> > >> -  bne vfp_kmode_exception @ Returns through lr
> > >> +  ldr r1, =vfp_kmode_exception
> > >> +  bxner1  @ Returns through lr
> > >>
> > >>VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> > >>DBGSTR1 "fpexc %08x", r1
> > >
> > > This seems like a workaround though? I suspect the vfp11_veneer 
> > > needs
> > > moving?
> > >
> > 
> >  I don't know where it needs to be moved. Please feel free to make a
> >  patch if you have a better idea, I'll be glad to test it.
> > >>>
> > >>> I might have just been distracted by the common "vfp" prefix. It's
> > >>> possible that the text section shuffling just ended up being very 
> > >>> large,
> > >>> so probably this patch is right then!
> > >>>
> > >>
> > >> I already sent a fix for this issue:
> > >>
> > >> https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > >>
> > >
> > > The offending commit contains stable tag, so I assume that fixes tag 
> > > is
> > > mandatory. Yours patch misses the fixes tag.
> > 
> >  Russell, mind adding that? Or would you like me to update the patch in
> >  the patch system?
> > >>>
> > >>> Rather than adding the IT, I'm suggesting that we solve it a different
> > >>> way - ensuring that the two bits of code are co-located. There's no
> > >>> reason for them to be separated, and the assembly code entry point is
> > >>> already called indirectly.
> > >>>
> > >>> The problem is the assembly ends up in the .text section which ends up
> > >>> at the start of the binary, but depending on the compiler, functions
> > >>> in .c files end up in their own sections. It would be good if, as
> > >>> Dmitry has shown that it is indeed possible, to have them co-located.
> > >>
> > >> Why is that better? I provided a minimal fix which has zero impact on
> > >> ARM builds, and minimal impact on Thumb2 builds, given that it retains
> > >> the exact same semantics as before, but using a different opcode.
> > >
> > > I think you just described the reason there. Why should we force
> > > everything to use a different opcode when a short jump _should_
> > > suffice?
> > >
> > > Your patch may be a single line, but it has a slightly greater
> > > impact than the alternative two line solution.
> > >
> >
> > But the two line change isn't portable to stable kernels 

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Russell King - ARM Linux admin]

On Thu, Oct 22, 2020 at 07:34:38PM +0300, Dmitry Osipenko wrote:
> 22.10.2020 19:23, Russell King - ARM Linux admin пишет:
> > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> >> On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> >>  wrote:
> >>>
> >>> On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
>  On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  wrote:
> >
> > 22.10.2020 10:06, Ard Biesheuvel пишет:
> >> On Thu, 22 Oct 2020 at 05:30, Kees Cook  wrote:
> >>>
> >>> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
>  22.10.2020 02:40, Kees Cook пишет:
> > On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> >> The vfp_kmode_exception() function now is unreachable using 
> >> relative
> >> branching in THUMB2 kernel configuration, resulting in a 
> >> "relocation
> >> truncated to fit: R_ARM_THM_JUMP19 against symbol 
> >> `vfp_kmode_exception'"
> >> linker error. Let's use long jump in order to fix the issue.
> >
> > Eek. Is this with gcc or clang?
> 
>  GCC 9.3.0
> 
> >> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input 
> >> sections")
> >
> > Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing 
> > sections") ?
> > That commit may have implicitly moved the location of .vfp11_veneer,
> > though I thought I had chosen the correct position.
> 
>  I re-checked that the fixes tag is correct.
> 
> >> Signed-off-by: Dmitry Osipenko 
> >> ---
> >>  arch/arm/vfp/vfphw.S | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> >> index 4fcff9f59947..6e2b29f0c48d 100644
> >> --- a/arch/arm/vfp/vfphw.S
> >> +++ b/arch/arm/vfp/vfphw.S
> >> @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> >>ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP 
> >> exceptions
> >>and r3, r3, #MODE_MASK  @ are supported in kernel mode
> >>teq r3, #USR_MODE
> >> -  bne vfp_kmode_exception @ Returns through lr
> >> +  ldr r1, =vfp_kmode_exception
> >> +  bxner1  @ Returns through lr
> >>
> >>VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> >>DBGSTR1 "fpexc %08x", r1
> >
> > This seems like a workaround though? I suspect the vfp11_veneer 
> > needs
> > moving?
> >
> 
>  I don't know where it needs to be moved. Please feel free to make a
>  patch if you have a better idea, I'll be glad to test it.
> >>>
> >>> I might have just been distracted by the common "vfp" prefix. It's
> >>> possible that the text section shuffling just ended up being very 
> >>> large,
> >>> so probably this patch is right then!
> >>>
> >>
> >> I already sent a fix for this issue:
> >>
> >> https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> >>
> >
> > The offending commit contains stable tag, so I assume that fixes tag is
> > mandatory. Yours patch misses the fixes tag.
> 
>  Russell, mind adding that? Or would you like me to update the patch in
>  the patch system?
> >>>
> >>> Rather than adding the IT, I'm suggesting that we solve it a different
> >>> way - ensuring that the two bits of code are co-located. There's no
> >>> reason for them to be separated, and the assembly code entry point is
> >>> already called indirectly.
> >>>
> >>> The problem is the assembly ends up in the .text section which ends up
> >>> at the start of the binary, but depending on the compiler, functions
> >>> in .c files end up in their own sections. It would be good if, as
> >>> Dmitry has shown that it is indeed possible, to have them co-located.
> >>
> >> Why is that better? I provided a minimal fix which has zero impact on
> >> ARM builds, and minimal impact on Thumb2 builds, given that it retains
> >> the exact same semantics as before, but using a different opcode.
> > 
> > I think you just described the reason there. Why should we force
> > everything to use a different opcode when a short jump _should_
> > suffice?
> > 
> > Your patch may be a single line, but it has a slightly greater
> > impact than the alternative two line solution.
> > 
> 
> But the two line change isn't portable to stable kernels as-is, isn't it?

Why not?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Dmitry Osipenko]

22.10.2020 19:23, Russell King - ARM Linux admin пишет:
> On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
>> On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
>>  wrote:
>>>
>>> On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
 On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  wrote:
>
> 22.10.2020 10:06, Ard Biesheuvel пишет:
>> On Thu, 22 Oct 2020 at 05:30, Kees Cook  wrote:
>>>
>>> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
 22.10.2020 02:40, Kees Cook пишет:
> On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
>> The vfp_kmode_exception() function now is unreachable using relative
>> branching in THUMB2 kernel configuration, resulting in a "relocation
>> truncated to fit: R_ARM_THM_JUMP19 against symbol 
>> `vfp_kmode_exception'"
>> linker error. Let's use long jump in order to fix the issue.
>
> Eek. Is this with gcc or clang?

 GCC 9.3.0

>> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input 
>> sections")
>
> Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing 
> sections") ?
> That commit may have implicitly moved the location of .vfp11_veneer,
> though I thought I had chosen the correct position.

 I re-checked that the fixes tag is correct.

>> Signed-off-by: Dmitry Osipenko 
>> ---
>>  arch/arm/vfp/vfphw.S | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
>> index 4fcff9f59947..6e2b29f0c48d 100644
>> --- a/arch/arm/vfp/vfphw.S
>> +++ b/arch/arm/vfp/vfphw.S
>> @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
>>ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP 
>> exceptions
>>and r3, r3, #MODE_MASK  @ are supported in kernel mode
>>teq r3, #USR_MODE
>> -  bne vfp_kmode_exception @ Returns through lr
>> +  ldr r1, =vfp_kmode_exception
>> +  bxner1  @ Returns through lr
>>
>>VFPFMRX r1, FPEXC   @ Is the VFP enabled?
>>DBGSTR1 "fpexc %08x", r1
>
> This seems like a workaround though? I suspect the vfp11_veneer needs
> moving?
>

 I don't know where it needs to be moved. Please feel free to make a
 patch if you have a better idea, I'll be glad to test it.
>>>
>>> I might have just been distracted by the common "vfp" prefix. It's
>>> possible that the text section shuffling just ended up being very large,
>>> so probably this patch is right then!
>>>
>>
>> I already sent a fix for this issue:
>>
>> https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
>>
>
> The offending commit contains stable tag, so I assume that fixes tag is
> mandatory. Yours patch misses the fixes tag.

 Russell, mind adding that? Or would you like me to update the patch in
 the patch system?
>>>
>>> Rather than adding the IT, I'm suggesting that we solve it a different
>>> way - ensuring that the two bits of code are co-located. There's no
>>> reason for them to be separated, and the assembly code entry point is
>>> already called indirectly.
>>>
>>> The problem is the assembly ends up in the .text section which ends up
>>> at the start of the binary, but depending on the compiler, functions
>>> in .c files end up in their own sections. It would be good if, as
>>> Dmitry has shown that it is indeed possible, to have them co-located.
>>
>> Why is that better? I provided a minimal fix which has zero impact on
>> ARM builds, and minimal impact on Thumb2 builds, given that it retains
>> the exact same semantics as before, but using a different opcode.
> 
> I think you just described the reason there. Why should we force
> everything to use a different opcode when a short jump _should_
> suffice?
> 
> Your patch may be a single line, but it has a slightly greater
> impact than the alternative two line solution.
> 

But the two line change isn't portable to stable kernels as-is, isn't it?

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Ard Biesheuvel]

On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
 wrote:
>
> On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> >  wrote:
> > >
> > > On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > > > On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  wrote:
> > > > >
> > > > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > > > > On Thu, 22 Oct 2020 at 05:30, Kees Cook  
> > > > > > wrote:
> > > > > >>
> > > > > >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> > > > > >>> 22.10.2020 02:40, Kees Cook пишет:
> > > > >  On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> > > > > > The vfp_kmode_exception() function now is unreachable using 
> > > > > > relative
> > > > > > branching in THUMB2 kernel configuration, resulting in a 
> > > > > > "relocation
> > > > > > truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > > > > > `vfp_kmode_exception'"
> > > > > > linker error. Let's use long jump in order to fix the issue.
> > > > > 
> > > > >  Eek. Is this with gcc or clang?
> > > > > >>>
> > > > > >>> GCC 9.3.0
> > > > > >>>
> > > > > > Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input 
> > > > > > sections")
> > > > > 
> > > > >  Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing 
> > > > >  sections") ?
> > > > >  That commit may have implicitly moved the location of 
> > > > >  .vfp11_veneer,
> > > > >  though I thought I had chosen the correct position.
> > > > > >>>
> > > > > >>> I re-checked that the fixes tag is correct.
> > > > > >>>
> > > > > > Signed-off-by: Dmitry Osipenko 
> > > > > > ---
> > > > > >  arch/arm/vfp/vfphw.S | 3 ++-
> > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > > > > > index 4fcff9f59947..6e2b29f0c48d 100644
> > > > > > --- a/arch/arm/vfp/vfphw.S
> > > > > > +++ b/arch/arm/vfp/vfphw.S
> > > > > > @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > > > > >ldr r3, [sp, #S_PSR]@ Neither lazy restore nor 
> > > > > > FP exceptions
> > > > > >and r3, r3, #MODE_MASK  @ are supported in kernel 
> > > > > > mode
> > > > > >teq r3, #USR_MODE
> > > > > > -  bne vfp_kmode_exception @ Returns through lr
> > > > > > +  ldr r1, =vfp_kmode_exception
> > > > > > +  bxner1  @ Returns through lr
> > > > > >
> > > > > >VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> > > > > >DBGSTR1 "fpexc %08x", r1
> > > > > 
> > > > >  This seems like a workaround though? I suspect the vfp11_veneer 
> > > > >  needs
> > > > >  moving?
> > > > > 
> > > > > >>>
> > > > > >>> I don't know where it needs to be moved. Please feel free to make 
> > > > > >>> a
> > > > > >>> patch if you have a better idea, I'll be glad to test it.
> > > > > >>
> > > > > >> I might have just been distracted by the common "vfp" prefix. It's
> > > > > >> possible that the text section shuffling just ended up being very 
> > > > > >> large,
> > > > > >> so probably this patch is right then!
> > > > > >>
> > > > > >
> > > > > > I already sent a fix for this issue:
> > > > > >
> > > > > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > > > > >
> > > > >
> > > > > The offending commit contains stable tag, so I assume that fixes tag 
> > > > > is
> > > > > mandatory. Yours patch misses the fixes tag.
> > > >
> > > > Russell, mind adding that? Or would you like me to update the patch in
> > > > the patch system?
> > >
> > > Rather than adding the IT, I'm suggesting that we solve it a different
> > > way - ensuring that the two bits of code are co-located. There's no
> > > reason for them to be separated, and the assembly code entry point is
> > > already called indirectly.
> > >
> > > The problem is the assembly ends up in the .text section which ends up
> > > at the start of the binary, but depending on the compiler, functions
> > > in .c files end up in their own sections. It would be good if, as
> > > Dmitry has shown that it is indeed possible, to have them co-located.
> >
> > Why is that better? I provided a minimal fix which has zero impact on
> > ARM builds, and minimal impact on Thumb2 builds, given that it retains
> > the exact same semantics as before, but using a different opcode.
>
> I think you just described the reason there. Why should we force
> everything to use a different opcode when a short jump _should_
> suffice?
>

Why should a short jump suffice? The call is to vfp_kmode_exception(),
which we only call in exceptional cases. Why would we want to keep
that in close proximity?

> Your patch may be a single line, but it has a slightly greater
> impact than the alternative two line solution.
>

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Russell King - ARM Linux admin]

On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
>  wrote:
> >
> > On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > > On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  wrote:
> > > >
> > > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > > > On Thu, 22 Oct 2020 at 05:30, Kees Cook  wrote:
> > > > >>
> > > > >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> > > > >>> 22.10.2020 02:40, Kees Cook пишет:
> > > >  On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> > > > > The vfp_kmode_exception() function now is unreachable using 
> > > > > relative
> > > > > branching in THUMB2 kernel configuration, resulting in a 
> > > > > "relocation
> > > > > truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > > > > `vfp_kmode_exception'"
> > > > > linker error. Let's use long jump in order to fix the issue.
> > > > 
> > > >  Eek. Is this with gcc or clang?
> > > > >>>
> > > > >>> GCC 9.3.0
> > > > >>>
> > > > > Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input 
> > > > > sections")
> > > > 
> > > >  Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing 
> > > >  sections") ?
> > > >  That commit may have implicitly moved the location of 
> > > >  .vfp11_veneer,
> > > >  though I thought I had chosen the correct position.
> > > > >>>
> > > > >>> I re-checked that the fixes tag is correct.
> > > > >>>
> > > > > Signed-off-by: Dmitry Osipenko 
> > > > > ---
> > > > >  arch/arm/vfp/vfphw.S | 3 ++-
> > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > > > > index 4fcff9f59947..6e2b29f0c48d 100644
> > > > > --- a/arch/arm/vfp/vfphw.S
> > > > > +++ b/arch/arm/vfp/vfphw.S
> > > > > @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > > > >ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP 
> > > > > exceptions
> > > > >and r3, r3, #MODE_MASK  @ are supported in kernel mode
> > > > >teq r3, #USR_MODE
> > > > > -  bne vfp_kmode_exception @ Returns through lr
> > > > > +  ldr r1, =vfp_kmode_exception
> > > > > +  bxner1  @ Returns through lr
> > > > >
> > > > >VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> > > > >DBGSTR1 "fpexc %08x", r1
> > > > 
> > > >  This seems like a workaround though? I suspect the vfp11_veneer 
> > > >  needs
> > > >  moving?
> > > > 
> > > > >>>
> > > > >>> I don't know where it needs to be moved. Please feel free to make a
> > > > >>> patch if you have a better idea, I'll be glad to test it.
> > > > >>
> > > > >> I might have just been distracted by the common "vfp" prefix. It's
> > > > >> possible that the text section shuffling just ended up being very 
> > > > >> large,
> > > > >> so probably this patch is right then!
> > > > >>
> > > > >
> > > > > I already sent a fix for this issue:
> > > > >
> > > > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > > > >
> > > >
> > > > The offending commit contains stable tag, so I assume that fixes tag is
> > > > mandatory. Yours patch misses the fixes tag.
> > >
> > > Russell, mind adding that? Or would you like me to update the patch in
> > > the patch system?
> >
> > Rather than adding the IT, I'm suggesting that we solve it a different
> > way - ensuring that the two bits of code are co-located. There's no
> > reason for them to be separated, and the assembly code entry point is
> > already called indirectly.
> >
> > The problem is the assembly ends up in the .text section which ends up
> > at the start of the binary, but depending on the compiler, functions
> > in .c files end up in their own sections. It would be good if, as
> > Dmitry has shown that it is indeed possible, to have them co-located.
> 
> Why is that better? I provided a minimal fix which has zero impact on
> ARM builds, and minimal impact on Thumb2 builds, given that it retains
> the exact same semantics as before, but using a different opcode.

I think you just described the reason there. Why should we force
everything to use a different opcode when a short jump _should_
suffice?

Your patch may be a single line, but it has a slightly greater
impact than the alternative two line solution.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Ard Biesheuvel]

On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
 wrote:
>
> On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  wrote:
> > >
> > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > > On Thu, 22 Oct 2020 at 05:30, Kees Cook  wrote:
> > > >>
> > > >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> > > >>> 22.10.2020 02:40, Kees Cook пишет:
> > >  On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> > > > The vfp_kmode_exception() function now is unreachable using relative
> > > > branching in THUMB2 kernel configuration, resulting in a "relocation
> > > > truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > > > `vfp_kmode_exception'"
> > > > linker error. Let's use long jump in order to fix the issue.
> > > 
> > >  Eek. Is this with gcc or clang?
> > > >>>
> > > >>> GCC 9.3.0
> > > >>>
> > > > Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input 
> > > > sections")
> > > 
> > >  Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing 
> > >  sections") ?
> > >  That commit may have implicitly moved the location of .vfp11_veneer,
> > >  though I thought I had chosen the correct position.
> > > >>>
> > > >>> I re-checked that the fixes tag is correct.
> > > >>>
> > > > Signed-off-by: Dmitry Osipenko 
> > > > ---
> > > >  arch/arm/vfp/vfphw.S | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > > > index 4fcff9f59947..6e2b29f0c48d 100644
> > > > --- a/arch/arm/vfp/vfphw.S
> > > > +++ b/arch/arm/vfp/vfphw.S
> > > > @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > > >ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP 
> > > > exceptions
> > > >and r3, r3, #MODE_MASK  @ are supported in kernel mode
> > > >teq r3, #USR_MODE
> > > > -  bne vfp_kmode_exception @ Returns through lr
> > > > +  ldr r1, =vfp_kmode_exception
> > > > +  bxner1  @ Returns through lr
> > > >
> > > >VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> > > >DBGSTR1 "fpexc %08x", r1
> > > 
> > >  This seems like a workaround though? I suspect the vfp11_veneer needs
> > >  moving?
> > > 
> > > >>>
> > > >>> I don't know where it needs to be moved. Please feel free to make a
> > > >>> patch if you have a better idea, I'll be glad to test it.
> > > >>
> > > >> I might have just been distracted by the common "vfp" prefix. It's
> > > >> possible that the text section shuffling just ended up being very 
> > > >> large,
> > > >> so probably this patch is right then!
> > > >>
> > > >
> > > > I already sent a fix for this issue:
> > > >
> > > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > > >
> > >
> > > The offending commit contains stable tag, so I assume that fixes tag is
> > > mandatory. Yours patch misses the fixes tag.
> >
> > Russell, mind adding that? Or would you like me to update the patch in
> > the patch system?
>
> Rather than adding the IT, I'm suggesting that we solve it a different
> way - ensuring that the two bits of code are co-located. There's no
> reason for them to be separated, and the assembly code entry point is
> already called indirectly.
>
> The problem is the assembly ends up in the .text section which ends up
> at the start of the binary, but depending on the compiler, functions
> in .c files end up in their own sections. It would be good if, as
> Dmitry has shown that it is indeed possible, to have them co-located.
>

Why is that better? I provided a minimal fix which has zero impact on
ARM builds, and minimal impact on Thumb2 builds, given that it retains
the exact same semantics as before, but using a different opcode.

R_ARM_THM_JUMP19 only has -/+ 1 MB range, i.e., smaller than the size
of .text, and so using it for calls to external symbols is still going
to be risky, unless we create a completely separate code section for
VFP related routines. So we may need the IT instruction anyway, at
which point we don't need anything more.

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Russell King - ARM Linux admin]

On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  wrote:
> >
> > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > On Thu, 22 Oct 2020 at 05:30, Kees Cook  wrote:
> > >>
> > >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> > >>> 22.10.2020 02:40, Kees Cook пишет:
> >  On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> > > The vfp_kmode_exception() function now is unreachable using relative
> > > branching in THUMB2 kernel configuration, resulting in a "relocation
> > > truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > > `vfp_kmode_exception'"
> > > linker error. Let's use long jump in order to fix the issue.
> > 
> >  Eek. Is this with gcc or clang?
> > >>>
> > >>> GCC 9.3.0
> > >>>
> > > Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input 
> > > sections")
> > 
> >  Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing 
> >  sections") ?
> >  That commit may have implicitly moved the location of .vfp11_veneer,
> >  though I thought I had chosen the correct position.
> > >>>
> > >>> I re-checked that the fixes tag is correct.
> > >>>
> > > Signed-off-by: Dmitry Osipenko 
> > > ---
> > >  arch/arm/vfp/vfphw.S | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > > index 4fcff9f59947..6e2b29f0c48d 100644
> > > --- a/arch/arm/vfp/vfphw.S
> > > +++ b/arch/arm/vfp/vfphw.S
> > > @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > >ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP 
> > > exceptions
> > >and r3, r3, #MODE_MASK  @ are supported in kernel mode
> > >teq r3, #USR_MODE
> > > -  bne vfp_kmode_exception @ Returns through lr
> > > +  ldr r1, =vfp_kmode_exception
> > > +  bxner1  @ Returns through lr
> > >
> > >VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> > >DBGSTR1 "fpexc %08x", r1
> > 
> >  This seems like a workaround though? I suspect the vfp11_veneer needs
> >  moving?
> > 
> > >>>
> > >>> I don't know where it needs to be moved. Please feel free to make a
> > >>> patch if you have a better idea, I'll be glad to test it.
> > >>
> > >> I might have just been distracted by the common "vfp" prefix. It's
> > >> possible that the text section shuffling just ended up being very large,
> > >> so probably this patch is right then!
> > >>
> > >
> > > I already sent a fix for this issue:
> > >
> > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > >
> >
> > The offending commit contains stable tag, so I assume that fixes tag is
> > mandatory. Yours patch misses the fixes tag.
> 
> Russell, mind adding that? Or would you like me to update the patch in
> the patch system?

Rather than adding the IT, I'm suggesting that we solve it a different
way - ensuring that the two bits of code are co-located. There's no
reason for them to be separated, and the assembly code entry point is
already called indirectly.

The problem is the assembly ends up in the .text section which ends up
at the start of the binary, but depending on the compiler, functions
in .c files end up in their own sections. It would be good if, as
Dmitry has shown that it is indeed possible, to have them co-located.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Ard Biesheuvel]

On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko  wrote:
>
> 22.10.2020 10:06, Ard Biesheuvel пишет:
> > On Thu, 22 Oct 2020 at 05:30, Kees Cook  wrote:
> >>
> >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> >>> 22.10.2020 02:40, Kees Cook пишет:
>  On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> > The vfp_kmode_exception() function now is unreachable using relative
> > branching in THUMB2 kernel configuration, resulting in a "relocation
> > truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
> > linker error. Let's use long jump in order to fix the issue.
> 
>  Eek. Is this with gcc or clang?
> >>>
> >>> GCC 9.3.0
> >>>
> > Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input 
> > sections")
> 
>  Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing sections") ?
>  That commit may have implicitly moved the location of .vfp11_veneer,
>  though I thought I had chosen the correct position.
> >>>
> >>> I re-checked that the fixes tag is correct.
> >>>
> > Signed-off-by: Dmitry Osipenko 
> > ---
> >  arch/arm/vfp/vfphw.S | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > index 4fcff9f59947..6e2b29f0c48d 100644
> > --- a/arch/arm/vfp/vfphw.S
> > +++ b/arch/arm/vfp/vfphw.S
> > @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> >ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP 
> > exceptions
> >and r3, r3, #MODE_MASK  @ are supported in kernel mode
> >teq r3, #USR_MODE
> > -  bne vfp_kmode_exception @ Returns through lr
> > +  ldr r1, =vfp_kmode_exception
> > +  bxner1  @ Returns through lr
> >
> >VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> >DBGSTR1 "fpexc %08x", r1
> 
>  This seems like a workaround though? I suspect the vfp11_veneer needs
>  moving?
> 
> >>>
> >>> I don't know where it needs to be moved. Please feel free to make a
> >>> patch if you have a better idea, I'll be glad to test it.
> >>
> >> I might have just been distracted by the common "vfp" prefix. It's
> >> possible that the text section shuffling just ended up being very large,
> >> so probably this patch is right then!
> >>
> >
> > I already sent a fix for this issue:
> >
> > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> >
>
> The offending commit contains stable tag, so I assume that fixes tag is
> mandatory. Yours patch misses the fixes tag.

Russell, mind adding that? Or would you like me to update the patch in
the patch system?

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Dmitry Osipenko]

22.10.2020 10:06, Ard Biesheuvel пишет:
> On Thu, 22 Oct 2020 at 05:30, Kees Cook  wrote:
>>
>> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
>>> 22.10.2020 02:40, Kees Cook пишет:
 On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> The vfp_kmode_exception() function now is unreachable using relative
> branching in THUMB2 kernel configuration, resulting in a "relocation
> truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
> linker error. Let's use long jump in order to fix the issue.

 Eek. Is this with gcc or clang?
>>>
>>> GCC 9.3.0
>>>
> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")

 Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing sections") ?
 That commit may have implicitly moved the location of .vfp11_veneer,
 though I thought I had chosen the correct position.
>>>
>>> I re-checked that the fixes tag is correct.
>>>
> Signed-off-by: Dmitry Osipenko 
> ---
>  arch/arm/vfp/vfphw.S | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> index 4fcff9f59947..6e2b29f0c48d 100644
> --- a/arch/arm/vfp/vfphw.S
> +++ b/arch/arm/vfp/vfphw.S
> @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
>ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP 
> exceptions
>and r3, r3, #MODE_MASK  @ are supported in kernel mode
>teq r3, #USR_MODE
> -  bne vfp_kmode_exception @ Returns through lr
> +  ldr r1, =vfp_kmode_exception
> +  bxner1  @ Returns through lr
>
>VFPFMRX r1, FPEXC   @ Is the VFP enabled?
>DBGSTR1 "fpexc %08x", r1

 This seems like a workaround though? I suspect the vfp11_veneer needs
 moving?

>>>
>>> I don't know where it needs to be moved. Please feel free to make a
>>> patch if you have a better idea, I'll be glad to test it.
>>
>> I might have just been distracted by the common "vfp" prefix. It's
>> possible that the text section shuffling just ended up being very large,
>> so probably this patch is right then!
>>
> 
> I already sent a fix for this issue:
> 
> https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> 

The offending commit contains stable tag, so I assume that fixes tag is
mandatory. Yours patch misses the fixes tag.

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Dmitry Osipenko]

22.10.2020 17:57, Russell King - ARM Linux admin пишет:
> On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
>> The vfp_kmode_exception() function now is unreachable using relative
>> branching in THUMB2 kernel configuration, resulting in a "relocation
>> truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
>> linker error. Let's use long jump in order to fix the issue.
>>
>> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
>> Signed-off-by: Dmitry Osipenko 
> 
> I guess the problem is that vfp_support_entry is in .text which tends
> to be at the beginning of the text section, but vfp_kmode_exception
> is in something like .text.vfp_kmode_exception ?

Indeed, vfp_support_entry is at beginning of .text, while
vfp_kmode_exception is near the end.

> Would it be an idea just to change the section name that stuff like
> vfp_support_entry ends up in, rather than making the code less
> efficient?
> 

This works:

diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index 4fcff9f59947..65f0a2ef3613 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -65,6 +65,7 @@
 #endif
.endm

+   .pushsection .vfp11_veneer, "ax"

 @ VFP hardware support entry point.
 @
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 8c9e7f9f0277..30b83b191174 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -642,7 +642,7 @@ static int vfp_starting_cpu(unsigned int unused)
return 0;
 }

-void vfp_kmode_exception(void)
+void __section(".vfp11_veneer") vfp_kmode_exception(void)
 {
/*
 * If we reach this point, a floating point exception has been raised

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Russell King - ARM Linux admin]

On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> The vfp_kmode_exception() function now is unreachable using relative
> branching in THUMB2 kernel configuration, resulting in a "relocation
> truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
> linker error. Let's use long jump in order to fix the issue.
> 
> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
> Signed-off-by: Dmitry Osipenko 

I guess the problem is that vfp_support_entry is in .text which tends
to be at the beginning of the text section, but vfp_kmode_exception
is in something like .text.vfp_kmode_exception ?

Would it be an idea just to change the section name that stuff like
vfp_support_entry ends up in, rather than making the code less
efficient?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Ard Biesheuvel]

On Thu, 22 Oct 2020 at 05:30, Kees Cook  wrote:
>
> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> > 22.10.2020 02:40, Kees Cook пишет:
> > > On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> > >> The vfp_kmode_exception() function now is unreachable using relative
> > >> branching in THUMB2 kernel configuration, resulting in a "relocation
> > >> truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
> > >> linker error. Let's use long jump in order to fix the issue.
> > >
> > > Eek. Is this with gcc or clang?
> >
> > GCC 9.3.0
> >
> > >> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
> > >
> > > Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing sections") ?
> > > That commit may have implicitly moved the location of .vfp11_veneer,
> > > though I thought I had chosen the correct position.
> >
> > I re-checked that the fixes tag is correct.
> >
> > >> Signed-off-by: Dmitry Osipenko 
> > >> ---
> > >>  arch/arm/vfp/vfphw.S | 3 ++-
> > >>  1 file changed, 2 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > >> index 4fcff9f59947..6e2b29f0c48d 100644
> > >> --- a/arch/arm/vfp/vfphw.S
> > >> +++ b/arch/arm/vfp/vfphw.S
> > >> @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > >>ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP 
> > >> exceptions
> > >>and r3, r3, #MODE_MASK  @ are supported in kernel mode
> > >>teq r3, #USR_MODE
> > >> -  bne vfp_kmode_exception @ Returns through lr
> > >> +  ldr r1, =vfp_kmode_exception
> > >> +  bxner1  @ Returns through lr
> > >>
> > >>VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> > >>DBGSTR1 "fpexc %08x", r1
> > >
> > > This seems like a workaround though? I suspect the vfp11_veneer needs
> > > moving?
> > >
> >
> > I don't know where it needs to be moved. Please feel free to make a
> > patch if you have a better idea, I'll be glad to test it.
>
> I might have just been distracted by the common "vfp" prefix. It's
> possible that the text section shuffling just ended up being very large,
> so probably this patch is right then!
>

I already sent a fix for this issue:

https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Kees Cook]

On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> 22.10.2020 02:40, Kees Cook пишет:
> > On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> >> The vfp_kmode_exception() function now is unreachable using relative
> >> branching in THUMB2 kernel configuration, resulting in a "relocation
> >> truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
> >> linker error. Let's use long jump in order to fix the issue.
> > 
> > Eek. Is this with gcc or clang?
> 
> GCC 9.3.0
> 
> >> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
> > 
> > Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing sections") ?
> > That commit may have implicitly moved the location of .vfp11_veneer,
> > though I thought I had chosen the correct position.
> 
> I re-checked that the fixes tag is correct.
> 
> >> Signed-off-by: Dmitry Osipenko 
> >> ---
> >>  arch/arm/vfp/vfphw.S | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> >> index 4fcff9f59947..6e2b29f0c48d 100644
> >> --- a/arch/arm/vfp/vfphw.S
> >> +++ b/arch/arm/vfp/vfphw.S
> >> @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> >>ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP exceptions
> >>and r3, r3, #MODE_MASK  @ are supported in kernel mode
> >>teq r3, #USR_MODE
> >> -  bne vfp_kmode_exception @ Returns through lr
> >> +  ldr r1, =vfp_kmode_exception
> >> +  bxner1  @ Returns through lr
> >>  
> >>VFPFMRX r1, FPEXC   @ Is the VFP enabled?
> >>DBGSTR1 "fpexc %08x", r1
> > 
> > This seems like a workaround though? I suspect the vfp11_veneer needs
> > moving?
> > 
> 
> I don't know where it needs to be moved. Please feel free to make a
> patch if you have a better idea, I'll be glad to test it.

I might have just been distracted by the common "vfp" prefix. It's
possible that the text section shuffling just ended up being very large,
so probably this patch is right then!

-- 
Kees Cook

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Dmitry Osipenko]

22.10.2020 02:40, Kees Cook пишет:
> On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
>> The vfp_kmode_exception() function now is unreachable using relative
>> branching in THUMB2 kernel configuration, resulting in a "relocation
>> truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
>> linker error. Let's use long jump in order to fix the issue.
> 
> Eek. Is this with gcc or clang?

GCC 9.3.0

>> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
> 
> Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing sections") ?
> That commit may have implicitly moved the location of .vfp11_veneer,
> though I thought I had chosen the correct position.

I re-checked that the fixes tag is correct.

>> Signed-off-by: Dmitry Osipenko 
>> ---
>>  arch/arm/vfp/vfphw.S | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
>> index 4fcff9f59947..6e2b29f0c48d 100644
>> --- a/arch/arm/vfp/vfphw.S
>> +++ b/arch/arm/vfp/vfphw.S
>> @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
>>  ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP exceptions
>>  and r3, r3, #MODE_MASK  @ are supported in kernel mode
>>  teq r3, #USR_MODE
>> -bne vfp_kmode_exception @ Returns through lr
>> +ldr r1, =vfp_kmode_exception
>> +bxner1  @ Returns through lr
>>  
>>  VFPFMRX r1, FPEXC   @ Is the VFP enabled?
>>  DBGSTR1 "fpexc %08x", r1
> 
> This seems like a workaround though? I suspect the vfp11_veneer needs
> moving?
> 

I don't know where it needs to be moved. Please feel free to make a
patch if you have a better idea, I'll be glad to test it.

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

[Kees Cook]

On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> The vfp_kmode_exception() function now is unreachable using relative
> branching in THUMB2 kernel configuration, resulting in a "relocation
> truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
> linker error. Let's use long jump in order to fix the issue.

Eek. Is this with gcc or clang?

> 
> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")

Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing sections") ?
That commit may have implicitly moved the location of .vfp11_veneer,
though I thought I had chosen the correct position.

> Signed-off-by: Dmitry Osipenko 
> ---
>  arch/arm/vfp/vfphw.S | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> index 4fcff9f59947..6e2b29f0c48d 100644
> --- a/arch/arm/vfp/vfphw.S
> +++ b/arch/arm/vfp/vfphw.S
> @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
>   ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP exceptions
>   and r3, r3, #MODE_MASK  @ are supported in kernel mode
>   teq r3, #USR_MODE
> - bne vfp_kmode_exception @ Returns through lr
> + ldr r1, =vfp_kmode_exception
> + bxner1  @ Returns through lr
>  
>   VFPFMRX r1, FPEXC   @ Is the VFP enabled?
>   DBGSTR1 "fpexc %08x", r1

This seems like a workaround though? I suspect the vfp11_veneer needs
moving?

-- 
Kees Cook