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]

Date:   Fri, 24 Nov 2017 11:57:07 +0000
From:   Vaneet Narang <v.narang@...sung.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>,
        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>,
        kasan-dev <kasan-dev@...glegroups.com>
Subject: RE: Re: [PATCH 1/1] stackdepot: interface to check entries and size
 of stackdepot.

Hi Michal,


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

On low memory system where page owner entries are in range of 3k ~ 4k, its
a waste to keep hash table size of 4MB. It can be modified to some 128KB to
save memory footprint of stackdepot. So stackdepot entry count is important.

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

Entry 1:
 __alloc_pages_nodemask+0xec/0x200
 page_frag_alloc+0x84/0x140
 __napi_alloc_skb+0x83/0xe0
 rtl8169_poll+0x1e5/0x670
 net_rx_action+0x122/0x380          
 __do_softirq+0xce/0x298            
 irq_exit+0xa3/0xb0
 -------------------
 do_IRQ+0x72/0xc0
 ret_from_intr+0x0/0x14
 rw_copy_check_uvector+0x8a/0x100
 import_iovec+0x27/0xc0
 copy_msghdr_from_user+0xc0/0x120
 ___sys_recvmsg+0x76/0x210
 __sys_recvmsg+0x39/0x70
 entry_SYSCALL_64_fastpath+0x13/

 Entry 2:
  __alloc_pages_nodemask+0xec/0x200
 page_frag_alloc+0x84/0x140
 __napi_alloc_skb+0x83/0xe0
 rtl8169_poll+0x1e5/0x670
 net_rx_action+0x122/0x380
 __do_softirq+0xce/0x298
 irq_exit+0xa3/0xb0    
 -------------------
 smp_apic_timer_interrupt+0x5b/0x110
 apic_timer_interrupt+0x89/0x90
 cpuidle_enter_state+0x95/0x2c0
 do_idle+0x163/0x1a0
 cpu_startup_entry+0x14/0x20
 secondary_startup_64+0xa5/0xb0

 Actual Allocation Path is
 __alloc_pages_nodemask+0xec/0x200
 page_frag_alloc+0x84/0x140
 __napi_alloc_skb+0x83/0xe0
 rtl8169_poll+0x1e5/0x670
 net_rx_action+0x122/0x380          
 __do_softirq+0xce/0x298            
 irq_exit+0xa3/0xb0

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.

Regards,
Vaneet Narang