[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2038d28f-0f65-5629-f033-e92c5c5e9798@nvidia.com>
Date: Fri, 7 Aug 2020 15:40:21 -0700
From: John Hubbard <jhubbard@...dia.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>,
Matthew Wilcox <willy@...radead.org>
CC: Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
<cai@....pw>, <rppt@...ux.ibm.com>, <vbabka@...e.cz>,
<william.kucharski@...cle.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH v2] mm, dump_page: do not crash with bad
compound_mapcount()
On 8/7/20 9:48 AM, Kirill A. Shutemov wrote:
>> [...]
>>>> +static inline int head_mapcount(struct page *head)
>>>> +{
>>>
>>> Do we want VM_BUG_ON_PAGE(!PageHead(head), head) here?
>>
>> Well, no. That was the point of the bug report -- by the time we called
>> compound_mapcount, the page was no longer a head page.
>
> Right. VM_BUG_ON_PAGE(PageTail(head), head)?
Sorry for overlooking that feedback point. Looking at it now, I'd much
rather not put any assertions at all here. This supposed to be for
implementing the failure case, and we've moved past assertions at this
point. In other words, dump_page() is part of *implementing* an
assertion, so calling assertions from within it is undesirable.
It's better to put the assertions in code that would call these inner
routines. Then, if we want to use these routines outside of mm/debug.c,
as per the other thread, then we should provide a wrapper that has such
assertions.
thanks,
--
John Hubbard
NVIDIA
Powered by blists - more mailing lists