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] [day] [month] [year] [list]
Message-ID: <CAMj1kXFXu75cDo=rx4rG6WFwd=At+nMWRzq378EoLu7GuHU64w@mail.gmail.com>
Date:   Thu, 17 Feb 2022 20:52:30 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Atish Patra <atishp@...shpatra.org>
Cc:     Sunil V L <sunilvl@...tanamicro.com>,
        Andreas Schwab <schwab@...ux-m68k.org>,
        Heinrich Schuchardt <xypron.glpk@....de>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        linux-efi <linux-efi@...r.kernel.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
        Anup Patel <apatel@...tanamicro.com>,
        "# 3.4.x" <stable@...r.kernel.org>
Subject: Re: [PATCH] riscv/efi_stub: Fix get_boot_hartid_from_fdt() return value

On Thu, 17 Feb 2022 at 20:47, Atish Patra <atishp@...shpatra.org> wrote:
>
> On Thu, Feb 17, 2022 at 2:55 AM Sunil V L <sunilvl@...tanamicro.com> wrote:
> >
> > On Mon, Feb 14, 2022 at 12:09:05PM +0100, Andreas Schwab wrote:
> > > On Feb 14 2022, Heinrich Schuchardt wrote:
> > >
> > > > On 2/14/22 11:15, Andreas Schwab wrote:
> > > >> On Feb 14 2022, Heinrich Schuchardt wrote:
> > > >>
> > > >>> set_boot_hartid() implies that the caller can change the boot hart ID.
> > > >>> As this is not a case this name obviously would be a misnomer.
> > > >>
> > > >> initialize_boot_hartid would fit better.
> > > >>
> > > >
> > > > Another misnomer.
> > >
> > > But the best fit so far.
> >
> > Can we use the name init_boot_hartid_from_fdt()? While I understand
> > Heinrich's point, I think since we have "_from_fdt", this may be fine.
> >
>
> init_boot_hartid_from_fdt or parse_boot_hartid_from_fdt
>
> are definitely much better than the current one.
>
> > I didn't rename the function since it was not recommended to do multiple
> > things in a "Fix" patch. If we can consider this as not very serious
> > issue which needs a "Fix" patch, then I can combine this patch with the
> > RISCV_EFI_BOOT_PROTOCOL patch series.
> >
>
> IMHO, it is okay to include this in the RISCV_EFI_BOOT_PROTOCOL series
> as we are not going to have hartid U32_MAX in a few months :)
>
>
> > Hi Ard, let me know your suggestion on how to proceed with this.
> >

The patch is fine as it is. I agree that naming is important, but for
a helper function that is only used a single time right in the same
source file, it doesn't matter that much.

I have queued this up now.

Thanks,
Ard.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ