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: <CAOnJCULtHzQKJNE4OO_U2NMaW6pX38Pw7dLywGc9og1BuuAYNQ@mail.gmail.com>
Date:   Fri, 28 Aug 2020 18:11:50 -0700
From:   Atish Patra <atishp@...shpatra.org>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Atish Patra <atish.patra@....com>,
        Zong Li <zong.li@...ive.com>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Will Deacon <will@...nel.org>, linux-arch@...r.kernel.org,
        Rob Herring <robh@...nel.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Ganapatrao Kulkarni <gkulkarni@...ium.com>,
        Steven Price <steven.price@....com>, linux-pci@...r.kernel.org,
        Greentime Hu <greentime.hu@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Arnd Bergmann <arnd@...db.de>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Nick Hu <nickhu@...estech.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Anup Patel <Anup.Patel@....com>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mike Rapoport <rppt@...nel.org>
Subject: Re: [RFC/RFT PATCH 3/6] arm64, numa: Move pcibus_to_node definition
 to generic numa code

On Fri, Aug 28, 2020 at 9:15 AM Bjorn Helgaas <helgaas@...nel.org> wrote:
>
> On Fri, Aug 28, 2020 at 10:48:30AM +0100, Jonathan Cameron wrote:
> > On Fri, 14 Aug 2020 14:47:22 -0700
> > Atish Patra <atish.patra@....com> wrote:
> >
> > > pcibus_to_node is used only when numa is enabled and does not depend
> > > on ISA. Thus, it can be moved the generic numa implementation.
> > >
> > > Signed-off-by: Atish Patra <atish.patra@....com>
> >
> > From a more general unification point of view, there seem to
> > be two ways architectures implement this.
> > Either
> >
> > bus->sysdata.node
> >
> > Or as here.
> > There are weird other options, but let us ignore those :)
> >
> > That is going to take a bit of unwinding should we
> > want to take this unification further and perhaps we want to think
> > about doing this in pci generic code rather than here?
> >
> > Perhaps this is one we are better keeping architecture specific for
> > now?
> >
> > +CC Bjorn and Linux-pci
> >
> >
> > > ---
> > >  arch/arm64/kernel/pci.c  | 10 ----------
> > >  drivers/base/arch_numa.c | 11 +++++++++++
> > >  2 files changed, 11 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > > index 1006ed2d7c60..07c122946c11 100644
> > > --- a/arch/arm64/kernel/pci.c
> > > +++ b/arch/arm64/kernel/pci.c
> > > @@ -54,16 +54,6 @@ int raw_pci_write(unsigned int domain, unsigned int bus,
> > >     return b->ops->write(b, devfn, reg, len, val);
> > >  }
> > >
> > > -#ifdef CONFIG_NUMA
> > > -
> > > -int pcibus_to_node(struct pci_bus *bus)
> > > -{
> > > -   return dev_to_node(&bus->dev);
> > > -}
> > > -EXPORT_SYMBOL(pcibus_to_node);
> > > -
> > > -#endif
> > > -
> > >  #ifdef CONFIG_ACPI
> > >
> > >  struct acpi_pci_generic_root_info {
> > > diff --git a/drivers/base/arch_numa.c b/drivers/base/arch_numa.c
> > > index 83341c807240..4ab1b20a615d 100644
> > > --- a/drivers/base/arch_numa.c
> > > +++ b/drivers/base/arch_numa.c
> > > @@ -11,6 +11,7 @@
> > >  #include <linux/acpi.h>
> > >  #include <linux/memblock.h>
> > >  #include <linux/module.h>
> > > +#include <linux/pci.h>
> > >  #include <linux/of.h>
> > >
> > >  #ifdef CONFIG_ARM64
> > > @@ -60,6 +61,16 @@ EXPORT_SYMBOL(cpumask_of_node);
> > >
> > >  #endif
> > >
> > > +#ifdef CONFIG_PCI
> > > +
> > > +int pcibus_to_node(struct pci_bus *bus)
> > > +{
> > > +   return dev_to_node(&bus->dev);
> > > +}
> > > +EXPORT_SYMBOL(pcibus_to_node);
> > > +
> > > +#endif
>
> I certainly agree that this should not be arch-specific, but I'm not
> really in favor of adding this PCI gunk in drivers/base.
>
> I think we can do better (eventually) by getting rid of
> pcibus_to_node() completely.  It's not used very much except by
> cpumask_of_pcibus(), which itself is hardly used at all.
>
I am a bit confused here. A quick grep suggested that pcibus_to_node()
is also called from generic pci probe,
controller and few drivers(block, infiniband) as well. Maybe I am
missing something here ?

We can move the pcibus_to_node to arch specific code for now if that's
what is preferred.

> > >  static void numa_update_cpu(unsigned int cpu, bool remove)
> > >  {
> > >     int nid = cpu_to_node(cpu);
> >
> >
>
> _______________________________________________
> 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