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

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

[Andrey Ryabinin]

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.

> use __GFP_NOWARN for stack
> 
> Link: http://lkml.kernel.org/r/20160720151905.GB19146@node.shutemov.name
> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Michal Hocko <mhocko@suse.cz>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Mel Gorman <mgorman@techsingularity.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  lib/stackdepot.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff -puN lib/stackdepot.c~mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix-2 lib/stackdepot.c
> --- a/lib/stackdepot.c~mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix-2
> +++ a/lib/stackdepot.c
> @@ -242,6 +242,7 @@ depot_stack_handle_t depot_save_stack(st
>  		 */
>  		alloc_flags &= ~GFP_ZONEMASK;
>  		alloc_flags &= (GFP_ATOMIC | GFP_KERNEL);
> +		alloc_flags |= __GFP_NOWARN;
>  		page = alloc_pages(alloc_flags, STACK_ALLOC_ORDER);
>  		if (page)
>  			prealloc = page_address(page);
> _
> 
> Patches currently in -mm which might be from kirill@shutemov.name are
> 
> mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix-2.patch
> 

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

[Alexander Potapenko]

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.
Adding __GFP_NOWARN will mask further problems of the similar nature,
so I think we'd better avoid it.

>> use __GFP_NOWARN for stack
>>
>> Link: http://lkml.kernel.org/r/20160720151905.GB19146@node.shutemov.name
>> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
>> Cc: Alexander Potapenko <glider@google.com>
>> Cc: Michal Hocko <mhocko@suse.cz>
>> Cc: Rik van Riel <riel@redhat.com>
>> Cc: David Rientjes <rientjes@google.com>
>> Cc: Mel Gorman <mgorman@techsingularity.net>
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> ---
>>
>>  lib/stackdepot.c |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff -puN lib/stackdepot.c~mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix-2 lib/stackdepot.c
>> --- a/lib/stackdepot.c~mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix-2
>> +++ a/lib/stackdepot.c
>> @@ -242,6 +242,7 @@ depot_stack_handle_t depot_save_stack(st
>>                */
>>               alloc_flags &= ~GFP_ZONEMASK;
>>               alloc_flags &= (GFP_ATOMIC | GFP_KERNEL);
>> +             alloc_flags |= __GFP_NOWARN;
>>               page = alloc_pages(alloc_flags, STACK_ALLOC_ORDER);
>>               if (page)
>>                       prealloc = page_address(page);
>> _
>>
>> Patches currently in -mm which might be from kirill@shutemov.name are
>>
>> mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix-2.patch
>>



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

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

[Andrey Ryabinin]

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.