Re: + mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix-2.patch added to -mm tree

[Andrey Ryabinin <aryabinin@virtuozzo.com>]

On 07/22/2016 04:32 PM, Alexander Potapenko wrote:
> On Thu, Jul 21, 2016 at 10:48 AM, Andrey Ryabinin
> <aryabinin@virtuozzo.com> wrote:
>>
>>
>> On 07/20/2016 09:43 PM, akpm@linux-foundation.org wrote:
>>>
>>> The patch titled
>>>      Subject: mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix
>>> has been added to the -mm tree.  Its filename is
>>>      mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix-2.patch
>>>
>>> This patch should soon appear at
>>>     http://ozlabs.org/~akpm/mmots/broken-out/mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix-2.patch
>>> and later at
>>>     http://ozlabs.org/~akpm/mmotm/broken-out/mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix-2.patch
>>>
>>> Before you just go and hit "reply", please:
>>>    a) Consider who else should be cc'ed
>>>    b) Prefer to cc a suitable mailing list as well
>>>    c) Ideally: find the original patch on the mailing list and do a
>>>       reply-to-all to that, adding suitable additional cc's
>>>
>>> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>>>
>>> The -mm tree is included into linux-next and is updated
>>> there every 3-4 working days
>>>
>>> ------------------------------------------------------
>>> From: "Kirill A. Shutemov" <kirill@shutemov.name>
>>> Subject: mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix
>>>
>>
>> This should be a separate patch. Stackdepot was added in cd11016e5f5212c13c0cec7384a525edc93b4921
>> which is in v4.6.
> Andrey, do you think we need this patch?
> I've posted the link to
> http://article.gmane.org/gmane.linux.kernel/2266971 in the discussion,
> and my patch seems to have fixed the problem.

It fixed high memory consumption which is orthogonal problem.

> Adding __GFP_NOWARN will mask further problems of the similar nature,
> so I think we'd better avoid it.
> 

How warning can help to detect such situations? Allocation failure doesn't mean that stackdepot
consumes too much memory.