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: <20171124094108epcms5p396558828a365a876d61205b0fdb501fd@epcms5p3>
Date:   Fri, 24 Nov 2017 09:41:08 +0000
From:   Maninder Singh <maninder1.s@...sung.com>
To:     Michal Hocko <mhocko@...nel.org>
CC:     "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>
Subject: Re: [PATCH 1/1] stackdepot: interface to check entries and size of
 stackdepot.

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)

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. 

Thanks
Maninder Singh