linux-kernel - Re: [PATCH] oom: print nodemask in the oom report

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: <6fc2bb5f-a91c-f4e8-8d3c-029e2bdb3526@suse.cz>
Date:   Tue, 4 Oct 2016 17:02:42 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        David Rientjes <rientjes@...gle.com>,
        Sellami Abdelkader <abdelkader.sellami@....com>,
        linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] oom: print nodemask in the oom report

On 10/04/2016 04:16 PM, Michal Hocko wrote:
> On Tue 04-10-16 15:24:53, Vlastimil Babka wrote:
>> On 09/30/2016 11:41 PM, Michal Hocko wrote:
> [...]
>>> Fix this by always priting the nodemask. It is either mempolicy mask
>>> (and non-null) or the one defined by the cpusets.
>>
>> I wonder if it's helpful to print the cpuset one when that's printed
>> separately, and seeing both pieces of information (nodemask and cpuset)
>> unmodified might tell us more. Is it to make it easier to deal with NULL
>> nodemask? Or to make sure the info gets through pr_warn() and not pr_info()?
>
> I am not sure I understand the question. I wanted to print the nodemask
> separatelly in the same line with all other allocation request
> parameters like order and gfp mask because that is what the page
> allocator got (via policy_nodemask). cpusets builds on top - aka applies
> __cpuset_zone_allowed on top of the nodemask. So imho it makes sense to
> look at the cpuset as an allocation domain while the mempolicy as a
> restriction within this domain.
>
> Does that answer your question?

Ah, I wasn't clear. What I questioned is the fallback to cpusets for 
NULL nodemask:

nodemask_t *nm = (oc->nodemask) ? oc->nodemask : 
&cpuset_current_mems_allowed;

>>> The new output for
>>> the above oom report would be
>>>
>>> PoolThread invoked oom-killer: gfp_mask=0x280da(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=0, order=0, oom_adj=0, oom_score_adj=0
>>>
>>> This patch doesn't touch show_mem and the node filtering based on the
>>> cpuset node mask because mempolicy is always a subset of cpusets and
>>> seeing the full cpuset oom context might be helpful for tunning more
>>> specific mempolicies inside cpusets (e.g. when they turn out to be too
>>> restrictive). To prevent from ugly ifdefs the mask is printed even
>>> for !NUMA configurations but this should be OK (a single node will be
>>> printed).
>>>
>>> Reported-by: Sellami Abdelkader <abdelkader.sellami@....com>
>>> Signed-off-by: Michal Hocko <mhocko@...e.com>
>>
>> Other than that,
>>
>> Acked-by: Vlastimil Babka <vbabka@...e.cz>
>
> Thanks!
>