Re: [External] Re: [PATCH 1/3] Revert "riscv/efistub: Ensure GP-relative addressing is not used"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 6 Mar 2024 at 14:27, yunhui cui <cuiyunhui@xxxxxxxxxxxxx> wrote:
>
> Hi Ard,
>
> On Wed, Mar 6, 2024 at 9:11 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> >
> > On Wed, 6 Mar 2024 at 14:08, yunhui cui <cuiyunhui@xxxxxxxxxxxxx> wrote:
> > >
> > > Hi Jan,
> > >
> > > On Wed, Mar 6, 2024 at 8:52 PM Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote:
> > > >
> > > > On 06.03.24 09:56, Yunhui Cui wrote:
> > > > > This reverts commit afb2a4fb84555ef9e61061f6ea63ed7087b295d5.
> > > > >
> > > >
> > > > This comes without a reason - which is likely something around "will fix
> > > > this properly later". But then you regress first and only fix
> > > > afterwards. Can't that be done the other way around?
> > >
> > > Sorry, I don't quite understand what you mean. Can you help explain it
> > > more clearly? Do you mean "delete mno-relax instead of revert
> > > directly?"
> > >
> >
> > You should order your patches in a way that does not create
> > intermediate states (between 1-2 or between 2-3) where the original
> > problem is being recreated.
> >
> > So in this case, you should
> > a) fix the issue
> > b) revert the existing patches in *opposite* order
> Simply, I plan to remove "-mno-relax" and
> "\|R_RISCV_$(BITS)\|R_RISCV_RELAX" in the third patch (fix patch).
>

Why is that better than the current approach?





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux