linux-kernel - Re: [PATCH] of: reserved-mem: expose reserved-mem details via debugfs

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230207210458.GA4142905-robh@kernel.org>
Date:   Tue, 7 Feb 2023 15:04:58 -0600
From:   Rob Herring <robh@...nel.org>
To:     Martin Liu <liumartin@...gle.com>
Cc:     frowand.list@...il.com, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, surenb@...gle.com,
        minchan@...nel.org, tkjos@...gle.com
Subject: Re: [PATCH] of: reserved-mem: expose reserved-mem details via debugfs

On Wed, Feb 08, 2023 at 01:05:25AM +0800, Martin Liu wrote:
> On Mon, Feb 6, 2023 at 11:12 PM Rob Herring <robh+dt@...nel.org> wrote:
> >
> > On Mon, Feb 6, 2023 at 8:27 AM Martin Liu <liumartin@...gle.com> wrote:
> > >
> > > It's important to know reserved-mem information in mobile world
> > > since reserved memory via device tree keeps increased in platform
> > > (e.g., 45% in our platform). Therefore, it's crucial to know the
> > > reserved memory sizes breakdown for the memory accounting.
> > >
> > > This patch shows the reserved memory breakdown under debugfs to
> > > make them visible.
> > >
> > > Below is an example output:
> > > cat $debugfs/reserved_mem/show
> > > 0x00000009fc400000..0x00000009ffffffff (   61440 KB )   map     reusable test1
> > > 0x00000009f9000000..0x00000009fc3fffff (   53248 KB )   map     reusable test2
> > > 0x00000000ffdf0000..0x00000000ffffffff (    2112 KB )   map non-reusable test3
> > > 0x00000009f6000000..0x00000009f8ffffff (   49152 KB )   map     reusable test4
> > > ...
> > > 0x00000000fd902000..0x00000000fd909fff (      32 KB ) nomap non-reusable test38
> > > 0x00000000fd90a000..0x00000000fd90bfff (       8 KB ) nomap non-reusable test39
> > > Total 39 regions, 1446140 KB
> >
> > This information is pretty much static, why not just print it during
> > boot? It's also just spitting out information that's straight from the
> > DT which is also available to userspace (flattened and unflattened).
> 
> IIUC, for dynamic allocation cases, we can't get actual allocation layout
> from DT.

Right, so whomever does the allocation should print that out.

>  Also, there could be some adjustment from memblock
> (ex. alignment). Therefore, printing it out from the reserved_mem would
> be more clear.

If memblock is adjusting, then shouldn't memblock print out the 
addresses?

> However, as you mentioned, once the allocation is done, it should be pretty
> static. Thus, printing it during boot should be reasonable. If so, we
> could print
> them out in fdt_init_reserved_mem() like below. Is my understanding correct?

That looks mostly fine to me. If we can do it with the unflattened tree, 
that would be better. I'm not sure off hand if that works here and you 
are just incorrectly using of_get_flat_dt_prop() still, or if it is 
indeed too early.

Rob