[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cbd20bc4-84ee-fd39-875b-75426bc61219@nvidia.com>
Date: Tue, 26 Oct 2021 11:01:56 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Pasha Tatashin <pasha.tatashin@...een.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-m68k@...ts.linux-m68k.org, anshuman.khandual@....com,
willy@...radead.org, akpm@...ux-foundation.org,
william.kucharski@...cle.com, mike.kravetz@...cle.com,
vbabka@...e.cz, geert@...ux-m68k.org, schmitzmic@...il.com,
rostedt@...dmis.org, mingo@...hat.com, hannes@...xchg.org,
guro@...com, songmuchun@...edance.com, weixugc@...gle.com,
gthelen@...gle.com
Subject: Re: [RFC 3/8] mm: Avoid using set_page_count() in
set_page_recounted()
On 10/26/21 10:53, John Hubbard wrote:
> On 10/26/21 10:38, Pasha Tatashin wrote:
>> set_page_refcounted() converts a non-refcounted page that has
>> (page->_refcount == 0) into a refcounted page by setting _refcount to 1,
>>
>> Use page_ref_inc_return() instead to avoid unconditionally overwriting
>> the _refcount value.
>>
>> Signed-off-by: Pasha Tatashin <pasha.tatashin@...een.com>
>> ---
>> mm/internal.h | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/internal.h b/mm/internal.h
>> index cf3cb933eba3..cf345fac6894 100644
>> --- a/mm/internal.h
>> +++ b/mm/internal.h
>> @@ -91,9 +91,12 @@ static inline bool page_evictable(struct page *page)
>> */
>> static inline void set_page_refcounted(struct page *page)
>> {
>> + int refcnt;
>> +
>> VM_BUG_ON_PAGE(PageTail(page), page);
>> VM_BUG_ON_PAGE(page_ref_count(page), page);
>> - set_page_count(page, 1);
>> + refcnt = page_ref_inc_return(page);
>> + VM_BUG_ON_PAGE(refcnt != 1, page);
>
> Hi Pavel,
ohhh, s/Pavel/Pasha/ !
Huge apologies for the name mixup, I had just seen another email...
very sorry about that mistake.
thanks,
--
John Hubbard
NVIDIA
>
> I am acutely uncomfortable with this change, because it changes the
> meaning and behavior of the function to something completely different,
> while leaving the function name unchanged. Furthermore, in relies upon
> debug assertions, rather than a return value (for example) to verify
> that all is well.
>
> I understand where this patchset is going, but this intermediate step is
> not a good move.
>
> Also, for the overall series, if you want to change from
> "set_page_count()" to "inc_and_verify_val_equals_one()", then the way to
> do that is *not* to depend solely on VM_BUG*() to verify. Instead,
> return something like -EBUSY if incrementing the value results in a
> surprise, and let the caller decide how to handle it.
>
> thanks,
Powered by blists - more mailing lists