lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOnJCUL7=i3XXMDJ5vgnNo==3zOANxGEe3ufznAhn7LE7vVAZQ@mail.gmail.com>
Date:   Fri, 24 Jul 2020 22:26:10 -0700
From:   Atish Patra <atishp@...shpatra.org>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     Atish Patra <Atish.Patra@....com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Vincent Chen <vincent.chen@...ive.com>,
        Anup Patel <Anup.Patel@....com>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
        sudeep.holla@....com, Zong Li <zong.li@...ive.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Greentime Hu <greentime.hu@...ive.com>,
        linux-riscv <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH 1/4] RISC-V: Setup exception vector early

On Fri, Jul 24, 2020 at 10:12 PM Palmer Dabbelt <palmer@...belt.com> wrote:
>
> On Wed, 15 Jul 2020 16:30:06 PDT (-0700), Atish Patra wrote:
> > The trap vector is set only in trap_init which may be too late in some
> > cases. Early ioremap/efi spits many warning messages which may be useful.
> >
> > Setup the trap vector early so that any warning/bug can be handled before
> > generic code invokes trap_init.
> >
> > Signed-off-by: Atish Patra <atish.patra@....com>
> > ---
> >  arch/riscv/kernel/head.S    | 10 ++++++++--
> >  arch/riscv/kernel/smpboot.c |  1 -
> >  arch/riscv/kernel/traps.c   |  8 +-------
> >  3 files changed, 9 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
> > index 7ed1b22950fd..d0c5c316e9bb 100644
> > --- a/arch/riscv/kernel/head.S
> > +++ b/arch/riscv/kernel/head.S
> > @@ -77,10 +77,16 @@ relocate:
> >       csrw CSR_SATP, a0
> >  .align 2
> >  1:
> > -     /* Set trap vector to spin forever to help debug */
> > -     la a0, .Lsecondary_park
> > +     /* Set trap vector to exception handler */
> > +     la a0, handle_exception
> >       csrw CSR_TVEC, a0
> >
> > +     /*
> > +      * Set sup0 scratch register to 0, indicating to exception vector that
> > +      * we are presently executing in kernel.
> > +      */
> > +     csrw CSR_SCRATCH, zero
> > +
> >       /* Reload the global pointer */
> >  .option push
> >  .option norelax
> > diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
> > index 4e9922790f6e..5a9c127a380e 100644
> > --- a/arch/riscv/kernel/smpboot.c
> > +++ b/arch/riscv/kernel/smpboot.c
> > @@ -154,7 +154,6 @@ asmlinkage __visible void smp_callin(void)
> >       mmgrab(mm);
> >       current->active_mm = mm;
> >
> > -     trap_init();
> >       notify_cpu_starting(smp_processor_id());
> >       update_siblings_masks(smp_processor_id());
> >       set_cpu_online(smp_processor_id(), 1);
> > diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
> > index 7d95cce5e47c..ad14f4466d92 100644
> > --- a/arch/riscv/kernel/traps.c
> > +++ b/arch/riscv/kernel/traps.c
> > @@ -174,13 +174,7 @@ int is_valid_bugaddr(unsigned long pc)
> >  }
> >  #endif /* CONFIG_GENERIC_BUG */
> >
> > +/* stvec & scratch is already set from head.S */
> >  void trap_init(void)
> >  {
> > -     /*
> > -      * Set sup0 scratch register to 0, indicating to exception vector
> > -      * that we are presently executing in the kernel
> > -      */
> > -     csr_write(CSR_SCRATCH, 0);
> > -     /* Set the exception vector address */
> > -     csr_write(CSR_TVEC, &handle_exception);
> >  }
>
> While I think these are all actual fixes, it's pretty late in the cycle here so
> I'm going to a bit on the careful side and only take the patches that actually
> manifest as bugs in the current port.  Assuming this doesn't manifest until
> early_ioremap is enabled (and we don't do that yet), I've put it on for-next.
>

Yeah. early_ioremap is part of the UEFI series. So this can go into for-next.
Thanks.

> LMK if I'm wrong about this, or the following ones.
>
> Thanks!
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ