linux-kernel - Re: [PATCH 3/8] sparc: prom: use property "name" directly to construct node names

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: <CAL_Jsq+VAkCmEpHKK-D8SjJ2pVuTbXuVVbLzpjKyOQY-jvmG8g@mail.gmail.com>
Date:   Fri, 9 Nov 2018 07:02:46 -0600
From:   Rob Herring <robh@...nel.org>
To:     David Miller <davem@...emloft.net>
Cc:     Frank Rowand <frowand.list@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        sparclinux@...r.kernel.org
Subject: Re: [PATCH 3/8] sparc: prom: use property "name" directly to
 construct node names

On Thu, Nov 8, 2018 at 9:13 PM David Miller <davem@...emloft.net> wrote:
>
> From: Rob Herring <robh@...nel.org>
> Date: Wed,  7 Nov 2018 16:31:46 -0600
>
> > In preparation to remove direct accesses to the device_node.name
> > pointer, retrieve the node name from the "name" property instead.
> >
> > Cc: "David S. Miller" <davem@...emloft.net>
> > Cc: sparclinux@...r.kernel.org
> > Signed-off-by: Rob Herring <robh@...nel.org>
>
> On some 32-bit sparcs, the OF runs in non-cached memory.
>
> Sucking in the OF device tree take a signficant amount of the
> boot time on such systems.
>
> And these changes are going to make it even slower.
>
> Please just put a wrapper around dp->name or whatever and use that,
> instead of making more get property OF calls which can be very
> expensive.

It's not making calls into OF. It is retrieving the property from the
kernel's copy of the DT (allocated by memblock). So the only
difference is we have to walk the struct property list to find "name".
That's perhaps offset by the fact that we'll be doing one less
property retrieval from OF when this is all done. Right now, we
retrieve "name" from OF twice per node.

Rob