linux-kernel - Re: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot.

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: <CACT4Y+bF7TGFS+395kyzdw21M==ECgs+dCjV0e3Whkvm1_piDA@mail.gmail.com>
Date:   Fri, 24 Nov 2017 11:23:08 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Maninder Singh <maninder1.s@...sung.com>,
        "kstewart@...uxfoundation.org" <kstewart@...uxfoundation.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "jkosina@...e.cz" <jkosina@...e.cz>,
        "pombredanne@...b.com" <pombredanne@...b.com>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "guptap@...eaurora.org" <guptap@...eaurora.org>,
        "vinmenon@...eaurora.org" <vinmenon@...eaurora.org>,
        AMIT SAHRAWAT <a.sahrawat@...sung.com>,
        PANKAJ MISHRA <pankaj.m@...sung.com>,
        Lalit Mohan Tripathi <lalit.mohan@...sung.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Vaneet Narang <v.narang@...sung.com>,
        kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot.

On Fri, Nov 24, 2017 at 10:54 AM, Michal Hocko <mhocko@...nel.org> wrote:
> On Fri 24-11-17 09:41:08, Maninder Singh wrote:
>> Hi Michal,
>>
>> > On Wed 22-11-17 16:17:41, Maninder Singh wrote:
>> > > This patch provides interface to check all the stack enteries
>> > > saved in stackdepot so far as well as memory consumed by stackdepot.
>> > >
>> > > 1) Take current depot_index and offset to calculate end address for one
>> > >         iteration of (/sys/kernel/debug/depot_stack/depot_entries).
>> > >
>> > > 2) Fill end marker in every slab to point its end, and then use it while
>> > >         traversing all the slabs of stackdepot.
>> > >
>> > > "debugfs code inspired from page_onwer's way of printing BT"
>> > >
>> > > checked on ARM and x86_64.
>> > > $cat /sys/kernel/debug/depot_stack/depot_size
>> > > Memory consumed by Stackdepot:208 KB
>> > >
>> > > $ cat /sys/kernel/debug/depot_stack/depot_entries
>> > > stack count 1 backtrace
>> > >  init_page_owner+0x1e/0x210
>> > >  start_kernel+0x310/0x3cd
>> > >  secondary_startup_64+0xa5/0xb0
>> > >  0xffffffffffffffff
>> >
>> > Why do we need this? Who is goging to use this information and what for?
>> > I haven't looked at the code but just the diffstat looks like this
>> > should better have a _very_ good justification to be considered for
>> > merging. To be honest with you I have hard time imagine how this can be
>> > useful other than debugging stack depot...
>>
>> This interface can be used for multiple reasons as:
>>
>> 1) For debugging stackdepot for sure.
>> 2) For checking all the unique allocation paths in system.
>> 3) To check if any invalid stack is coming which is increasing
>> stackdepot memory.
>> (https://lkml.org/lkml/2017/10/11/353)
>
> OK, so debugging a debugging facility... I do not think we want to
> introduce a lot of code for something like that.
>
>> Althoutgh this needs to be taken care in ARM as replied by maintainer, but with help
>> of this interface it was quite easy to check and we added workaround for saving memory.
>>
>> 4) At some point of time to check current memory consumed by stackdepot.
>> 5) To check number of entries in stackdepot to decide stackdepot hash size for different systems.
>>    For fewer entries hash table size can be reduced from 4MB.
>
> What are you going to do with that information. It is not like you can
> reduce the memory footprint or somehow optimize anything during the
> runtime.
>
> --
> Michal Hocko
> SUSE Labs

+kasan-dev mailing list