linux-kernel - Re: [PATCH v11 2/3] mm: add a field to store names for private anonymous memory

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: <CAJuCfpH6Cg=CDut_9vd3BcX6U_X0WR2tFkqKePLU7aPxFO0UDw@mail.gmail.com>
Date:   Tue, 16 Nov 2021 08:29:10 -0800
From:   Suren Baghdasaryan <surenb@...gle.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     akpm@...ux-foundation.org, Alexey Alexandrov <aalexand@...gle.com>,
        ccross@...gle.com, sumit.semwal@...aro.org, dave.hansen@...el.com,
        keescook@...omium.org, willy@...radead.org,
        kirill.shutemov@...ux.intel.com, vbabka@...e.cz,
        hannes@...xchg.org, corbet@....net, viro@...iv.linux.org.uk,
        rdunlap@...radead.org, kaleshsingh@...gle.com, peterx@...hat.com,
        rppt@...nel.org, peterz@...radead.org, catalin.marinas@....com,
        vincenzo.frascino@....com, chinwen.chang@...iatek.com,
        axelrasmussen@...gle.com, aarcange@...hat.com, jannh@...gle.com,
        apopple@...dia.com, jhubbard@...dia.com, yuzhao@...gle.com,
        will@...nel.org, fenghua.yu@...el.com, thunder.leizhen@...wei.com,
        hughd@...gle.com, feng.tang@...el.com, jgg@...pe.ca, guro@...com,
        tglx@...utronix.de, krisman@...labora.com, chris.hyser@...cle.com,
        pcc@...gle.com, ebiederm@...ssion.com, axboe@...nel.dk,
        legion@...nel.org, eb@...ix.com, gorcunov@...il.com, pavel@....cz,
        songmuchun@...edance.com, viresh.kumar@...aro.org,
        thomascedeno@...gle.com, sashal@...nel.org, cxfcosmos@...il.com,
        linux@...musvillemoes.dk, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-mm@...ck.org, kernel-team@...roid.com
Subject: Re: [PATCH v11 2/3] mm: add a field to store names for private
 anonymous memory

On Tue, Nov 16, 2021 at 1:51 AM Michal Hocko <mhocko@...e.com> wrote:
>
> On Mon 15-11-21 10:59:20, Suren Baghdasaryan wrote:
> [...]
> > Hi Andrew,
> > I haven't seen any feedback on my patchset for some time now. I think
> > I addressed all the questions and comments (please correct me if I
> > missed anything).
>
> I believe the strings vs. ids have been mostly hand waved away. The
> biggest argument for the former was convenience for developers to have
> something human readable. There was no actual proposal about the naming
> convention so we are relying on some unwritten rules or knowledge of the
> code to be debugged to make human readable string human understandable
> ones. I believe this has never been properly resolved except for - this
> has been used in Android and working just fine. I am not convinced TBH.
>
> So in the end we are adding a user interface that brings a runtime and
> resource overhead that will be hard to change in the future. Reference
> counting handles a part of that and that is nice but ids simply do not
> have any of that.

I explained the way this interface is used and why ids would not work
for us in https://lore.kernel.org/all/CAJuCfpESeM_Xd8dhCj_okNggtDUXx3Nn9FpL_f9qsKXKZzCKpA@mail.gmail.com.
I explored all the proposed alternatives, all of which would be
prohibitive for our needs due to performance costs compared to this
solution. I wish I could come up with something simpler but a simpler
solution simply does not meet our needs.

It's true that this approach does not formalize how VMAs are named but
I don't see why kernel should impose a naming convention. I can see
some systems defining more formal conventions but I believe it should
be up to the userspace to do that.

>
> > Can it be accepted as is or is there something I should address
> > further?
>
> Is the above reason to nack it? No, I do not think so. I just do not
> feel like I want to ack it either. Concerns have been expressed and I
> have to say that I would like a minimalistic approach much more. Also
> extending ids into string is always possible. The other way around is
> not possible.

Unfortunately, extending ids into strings comes with the cost we can't
afford in Android. Therefore I don't see a point for me to upstream
such a solution which I can't use.
Thanks,
Suren.

>
> --
> Michal Hocko
> SUSE Labs