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] [day] [month] [year] [list]
Date:   Tue, 10 Oct 2017 05:00:50 +0800
From:   "Yang Shi" <yang.s@...baba-inc.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
        iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when
 unreclaimable slabs > user memory



On 10/9/17 11:53 AM, Yang Shi wrote:
> 
> 
> On 10/8/17 11:36 PM, Michal Hocko wrote:
>> On Mon 09-10-17 08:33:16, Michal Hocko wrote:
>>> On Sat 07-10-17 00:37:55, Yang Shi wrote:
>>>>
>>>>
>>>> On 10/6/17 2:37 AM, Michal Hocko wrote:
>>>>> On Thu 05-10-17 05:29:10, Yang Shi wrote:
>>> [...]
>>>>>> +    list_for_each_entry_safe(s, s2, &slab_caches, list) {
>>>>>> +        if (!is_root_cache(s) || (s->flags & SLAB_RECLAIM_ACCOUNT))
>>>>>> +            continue;
>>>>>> +
>>>>>> +        memset(&sinfo, 0, sizeof(sinfo));
>>>>>
>>>>> why do you zero out the structure. All the fields you are printing are
>>>>> filled out in get_slabinfo.
>>>>
>>>> No special reason, just wipe out the potential stale data on the stack.
>>>
>>> Do not add code that has no meaning. The OOM killer is a slow path but
>>> that doesn't mean we should throw spare cycles out of the window.
>>
>> With this fixed and the compile fix [1] folded, feel free to add my
>> Acked-by: Michal Hocko <mhocko@...e.com>
>>
>> [1] 
>> http://lkml.kernel.org/r/1507492085-42264-1-git-send-email-yang.s@alibaba-inc.com 
>>
> 
> Did some more thorough test and took the code a little deeper, it sounds 
> !CONFIG_SLOB is not enough. Some data structure and functions depends on 
> CONFIG_SLUB_DEBUG, i.e. kmem_cache_node->total_objects and 
> node_nr_objs(), which are essential of get_slabinfo().
> 
> So, I'm supposed it makes more sense to protect the related slab stats 
> code and the unreclaimable slabinfo dump with CONFIG_SLAB || 
> CONFIG_SLUB_DEBUG.

This is needed to solve compile error when CONFIG_SLUB && !CONFIG_SLUB_DEBUG

Yang

> 
> Thanks,
> Yang
> 
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ