[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8127163.Epc2VWTDuo@basile.remlab.net>
Date: Wed, 18 Mar 2020 20:29:12 +0200
From: Rémi Denis-Courmont <remi@...lab.net>
To: Catalin Marinas <catalin.marinas@....com>
Cc: mark.rutland@....com, will@...nel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/3] arm64: clean up trampoline vector loads
Le keskiviikkona 18. maaliskuuta 2020, 20.06.30 EET Catalin Marinas a écrit :
> On Wed, Mar 18, 2020 at 05:57:09PM +0000, Catalin Marinas wrote:
> > On Mon, Mar 16, 2020 at 02:40:44PM +0200, Rémi Denis-Courmont wrote:
> > > From: Rémi Denis-Courmont <remi.denis.courmont@...wei.com>
> > >
> > > This switches from custom instruction patterns to the regular large
> > > memory model sequence with ADRP and LDR. In doing so, the ADD
> > > instruction can be eliminated in the SDEI handler, and the code no
> > > longer assumes that the trampoline vectors and the vectors address both
> > > start on a page boundary.
> > >
> > > Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@...wei.com>
> >
> > I queued the 3 trampoline patches for 5.7. Thanks.
>
> ... and removed. I applied them on top of arm64 for-next/asm-annotations
> and with defconfig I get:
>
> LD .tmp_vmlinux1
> arch/arm64/kernel/entry.o: in function `tramp_vectors':
> arch/arm64/kernel/entry.S:838:(.entry.tramp.text+0x43c): relocation
> truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol
> `__entry_tramp_data_start' defined in .rodata section in
>
> I haven't bisected to see which patch caused this issue.
Uho, right :-( It only builds with SDEI enabled :-$
I'll check further.
--
Rémi Denis-Courmont
http://www.remlab.net/
Powered by blists - more mailing lists