[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4faedb4d-f16c-1917-9eaa-b0f9c169fa50@suse.cz>
Date: Tue, 10 Sep 2019 13:53:23 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Andrey Ryabinin <aryabinin@...tuozzo.com>,
walter-zh.wu@...iatek.com, Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Will Deacon <will@...nel.org>,
Andrey Konovalov <andreyknvl@...gle.com>,
Arnd Bergmann <arnd@...db.de>,
Thomas Gleixner <tglx@...utronix.de>,
Michal Hocko <mhocko@...nel.org>, Qian Cai <cai@....pw>
Cc: linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com,
linux-mm@...ck.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, wsd_upstream@...iatek.com
Subject: Re: [PATCH v2 0/2] mm/kasan: dump alloc/free stack for page allocator
On 9/10/19 12:50 PM, Andrey Ryabinin wrote:
>
>
> For slab objects we memorize both alloc and free stacks. You'll never know in advance what information will be usefull
> to fix an issue, so it usually better to provide more information. I don't think we should do anything different for pages.
Exactly, thanks.
> Given that we already have the page_owner responsible for providing alloc/free stacks for pages, all that we should in KASAN do is to
> enable the feature by default. Free stack saving should be decoupled from debug_pagealloc into separate option so that it can be enabled
> by KASAN and/or debug_pagealloc.
Right. Walter, can you do it that way, or should I?
Thanks,
Vlastimil
Powered by blists - more mailing lists