linux-kernel - Re: [PATCH v2 4/4] mm, page_owner, debug_pagealloc: save and dump freeing stack trace

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: <7098e036-c955-4ccb-6bce-fedf82ad0b1b@suse.cz>
Date:   Tue, 24 Sep 2019 17:15:01 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Michal Hocko <mhocko@...nel.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v2 4/4] mm, page_owner, debug_pagealloc: save and dump
 freeing stack trace

On 9/24/19 1:42 PM, Kirill A. Shutemov wrote:
>> --- a/mm/page_owner.c
>> +++ b/mm/page_owner.c
>> @@ -24,6 +24,9 @@ struct page_owner {
>>  	short last_migrate_reason;
>>  	gfp_t gfp_mask;
>>  	depot_stack_handle_t handle;
>> +#ifdef CONFIG_DEBUG_PAGEALLOC
>> +	depot_stack_handle_t free_handle;
>> +#endif
> 
> I think it's possible to add space for the second stack handle at runtime:
> adjust page_owner_ops->size inside the ->need().

Uh that would complicate the code needlessly? The extra memory overhead
isn't that much for a scenario that's already a debugging one
(page_owner), I was more concerned about the cpu overhead, thus the
static key.

> The second stack might be
> useful beyond CONFIG_DEBUG_PAGEALLOC. We probably should not tie these
> features.

Yeah I generalized it later, as KASAN guys wanted the same thing:

https://lore.kernel.org/linux-arm-kernel/d98bf550-367d-0744-025a-52307248ec82@suse.cz/

Perhaps as it's still mmotm I can squash it here.