linux-kernel - Re: 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: <20171124124429.juonhyw4xbqc65u7@dhcp22.suse.cz>
Date:   Fri, 24 Nov 2017 13:44:29 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Vaneet Narang <v.narang@...sung.com>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        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>,
        kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: Re: [PATCH 1/1] stackdepot: interface to check entries and size
 of stackdepot.

On Fri 24-11-17 11:57:07, Vaneet Narang wrote:
[...]
> > OK, so debugging a debugging facility... I do not think we want to
> > introduce a lot of code for something like that.
> 
> We enabled stackdepot on our system and realised, in long run stack depot consumes
> more runtime memory then it actually needs. we used shared patch to debug this issue. 
> stack stores following two unique entries. Page allocation done in interrupt 
> context will generate a unique stack trace. Consider following two entries.
[...]
> We have been getting similar kind of such entries and eventually
> stackdepot reaches Max Cap. So we found this interface useful in debugging
> stackdepot issue so shared in community.

Then use it for internal debugging and provide a code which would scale
better on smaller systems. We do not need this in the kernel IMHO. We do
not merge all the debugging patches we use for internal development.

-- 
Michal Hocko
SUSE Labs