Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 10 Jun 2021 17:51:47 -0700 (PDT)
Subject:     Re: [PATCH] riscv: code patching only works on !XIP_KERNEL
In-Reply-To: <20210608161457.192b3ca3@xhacker.debian>
CC:     vitaly.wool@konsulko.com, jszhang3@mail.ustc.edu.cn,
        Paul Walmsley <paul.walmsley@sifive.com>,
        aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org
From:   Palmer Dabbelt <palmer@dabbelt.com>
To:     Jisheng.Zhang@synaptics.com
Message-ID: <mhng-4b3a688d-4531-46b8-9644-9e67c2d9bb03@palmerdabbelt-glaptop>
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Tue, 08 Jun 2021 01:14:57 PDT (-0700), Jisheng.Zhang@synaptics.com wrote:
> On Tue, 8 Jun 2021 09:50:00 +0200
> Vitaly Wool <vitaly.wool@konsulko.com> wrote:
>
>
>>
>>
>> Hi Jisheng,
>>
>> On Tue, Jun 8, 2021 at 9:24 AM Jisheng Zhang
>> <Jisheng.Zhang@synaptics.com> wrote:
>> >
>> > On Mon, 24 May 2021 21:32:38 +0200
>> > Vitaly Wool <vitaly.wool@konsulko.com> wrote:
>> >
>> >
>> > >
>> > >
>> > > On Sat, May 22, 2021 at 7:15 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> > > >
>> > > > On Mon, 10 May 2021 11:19:30 PDT (-0700), vitaly.wool@konsulko.com wrote:
>> > > > > On Mon, May 10, 2021 at 6:35 PM Jisheng Zhang <jszhang3@mail.ustc.edu.cn> wrote:
>> > > > >>
>> > > > >> From: Jisheng Zhang <jszhang@kernel.org>
>> > > > >>
>> > > > >> Some features which need code patching such as KPROBES, DYNAMIC_FTRACE
>> > > > >> KGDB can only work on !XIP_KERNEL. Add dependencies for these features
>> > > > >> that rely on code patching.
>> > > > >
>> > > > > Since we can define extra RW sections to place some tiny code bits in
>> > > > > RAM, I would suggest that you hold back this patch for a while.
>> > > > > I am not going to support the idea of e. g. compiling KGDB support
>> > > > > into a XIP kernel, but disabling the whole HAVE_ARCH_JUMP_LABEL is
>> > > > > hardly the way to go.
>> > > >
>> > > > Do you have any updates on this?  The SOC_SIFIVE disable thread floated
>> > > > back to the top of my inbox and I didn't see anything there.  I'd prefer
>> > > > to avoid chasing around Kconfig disables for a bunch of stuff that we're
>> > > > just going to fix soon, but if this is going to be a big change then
>> > > > it's likely for next cycle anyway so in that case I'll start picking up
>> > > > these compile disable patches.
>> > >
>> > > Sorry, was caught up in fixing other stuff but now I'm on it so expect
>> > > some updates soon.
>> >
>> > Hi Vitaly,
>> >
>> > Based on your "[PATCH] riscv: xip: support runtime trap patching", IMHO, it
>> > solves ERRATA patching issue(And it makes use of the fact that the ERRATA
>> > only touches traps at the moment), but can't make code patching tech such as
>> > KPROBES, DYNAMIC_FTRACE etc. work properly, so my patch is still needed.
>>
>> At this point it is needed, yes.
>>
>> The thing is, I thought I'd go with one problem at a time, so I posted
>> the patch which solves build issues for SOC_SIFIVE and XIP, and
>> runtime patching for ERRATA (and I hope it gets accepted and makes its
>> way into -stable, too).
>> I gathered that addressing your issue had lower priority and so it's
>
> It's at lower priority, in fact I didn't have XIP riscv platform ;)
>
>> still underway. All in all, I don't mind going on with your patch,
>> when the initial issue is addressed, we may want to revert some part
>> of it but I guess that would be ok with you, wouldn't it?
>
> We could revert some part of it later although I suspect the incompatibility
> between code patching tech and XIP could be addressed, take the KPROBES
> for example, it needs an ability to patch almost *every* can_be_kprobed insn
> this isn't achievable/necessary in XIP case.

I'm going to take the original patch in this thread.  Unless I'm missing 
something it's only turning off functionality that doesn't work (even 
with the errata fix), so it'll be necessary.  As things get fixed we can 
re-enable them, but this will at least stop enabling the broken stuff.

>
> Thanks
>
>>
>> Best regards,
>>    Vitaly
>>
>> > What do you think?
>> >
>> > Regards
>> >
>> > >
>> > > Best regards,
>> > >    Vitaly
>> > >
>> > > > Not trying to rush any thing here, just don't want to have a bunch of
>> > > > broken configs.
>> > > >
>> > > > >
>> > > > > Best regards,
>> > > > >    Vitaly
>> > > > >
>> > > > >> Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
>> > > > >> ---
>> > > > >> Hi,
>> > > > >>
>> > > > >> Currently, the RISCV_ERRATA_ALTERNATIVE also only works on !XIP_KERNEL
>> > > > >> but from the maillist it seem there's effort to make the co-exist, so
>> > > > >> I drop RISCV_ERRATA_ALTERNATIVE dependency on !XIP_KERNEL.
>> > > > >>
>> > > > >> Thanks
>> > > > >>
>> > > > >>  arch/riscv/Kconfig | 18 +++++++++---------
>> > > > >>  1 file changed, 9 insertions(+), 9 deletions(-)
>> > > > >>
>> > > > >> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> > > > >> index a8ad8eb76120..61320b94ef97 100644
>> > > > >> --- a/arch/riscv/Kconfig
>> > > > >> +++ b/arch/riscv/Kconfig
>> > > > >> @@ -60,11 +60,11 @@ config RISCV
>> > > > >>         select GENERIC_TIME_VSYSCALL if MMU && 64BIT
>> > > > >>         select HANDLE_DOMAIN_IRQ
>> > > > >>         select HAVE_ARCH_AUDITSYSCALL
>> > > > >> -       select HAVE_ARCH_JUMP_LABEL
>> > > > >> -       select HAVE_ARCH_JUMP_LABEL_RELATIVE
>> > > > >> +       select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
>> > > > >> +       select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL
>> > > > >>         select HAVE_ARCH_KASAN if MMU && 64BIT
>> > > > >>         select HAVE_ARCH_KASAN_VMALLOC if MMU && 64BIT
>> > > > >> -       select HAVE_ARCH_KGDB
>> > > > >> +       select HAVE_ARCH_KGDB if !XIP_KERNEL
>> > > > >>         select HAVE_ARCH_KGDB_QXFER_PKT
>> > > > >>         select HAVE_ARCH_MMAP_RND_BITS if MMU
>> > > > >>         select HAVE_ARCH_SECCOMP_FILTER
>> > > > >> @@ -79,9 +79,9 @@ config RISCV
>> > > > >>         select HAVE_GCC_PLUGINS
>> > > > >>         select HAVE_GENERIC_VDSO if MMU && 64BIT
>> > > > >>         select HAVE_IRQ_TIME_ACCOUNTING
>> > > > >> -       select HAVE_KPROBES
>> > > > >> -       select HAVE_KPROBES_ON_FTRACE
>> > > > >> -       select HAVE_KRETPROBES
>> > > > >> +       select HAVE_KPROBES if !XIP_KERNEL
>> > > > >> +       select HAVE_KPROBES_ON_FTRACE if !XIP_KERNEL
>> > > > >> +       select HAVE_KRETPROBES if !XIP_KERNEL
>> > > > >>         select HAVE_PCI
>> > > > >>         select HAVE_PERF_EVENTS
>> > > > >>         select HAVE_PERF_REGS
>> > > > >> @@ -230,11 +230,11 @@ config ARCH_RV64I
>> > > > >>         bool "RV64I"
>> > > > >>         select 64BIT
>> > > > >>         select ARCH_SUPPORTS_INT128 if CC_HAS_INT128 && GCC_VERSION >= 50000
>> > > > >> -       select HAVE_DYNAMIC_FTRACE if MMU && $(cc-option,-fpatchable-function-entry=8)
>> > > > >> +       select HAVE_DYNAMIC_FTRACE if !XIP_KERNEL && MMU && $(cc-option,-fpatchable-function-entry=8)
>> > > > >>         select HAVE_DYNAMIC_FTRACE_WITH_REGS if HAVE_DYNAMIC_FTRACE
>> > > > >> -       select HAVE_FTRACE_MCOUNT_RECORD
>> > > > >> +       select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
>> > > > >>         select HAVE_FUNCTION_GRAPH_TRACER
>> > > > >> -       select HAVE_FUNCTION_TRACER
>> > > > >> +       select HAVE_FUNCTION_TRACER if !XIP_KERNEL
>> > > > >>         select SWIOTLB if MMU
>> > > > >>
>> > > > >>  endchoice
>> > > > >> --
>> > > > >> 2.31.0
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> _______________________________________________