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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ