From: Charan Teja Kalla <quic_charante@quicinc.com>
To: Pavan Kondeti <quic_pkondeti@quicinc.com>
Cc: <akpm@linux-foundation.org>, <pasha.tatashin@soleen.com>,
<sjpark@amazon.de>, <sieberf@amazon.com>, <shakeelb@google.com>,
<dhowells@redhat.com>, <willy@infradead.org>, <mhocko@suse.com>,
<vbabka@suse.cz>, <david@redhat.com>, <minchan@kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: fix use-after free of page_ext after race with memory-offline
Date: Mon, 18 Jul 2022 18:45:19 +0530 [thread overview]
Message-ID: <dcb828a4-b836-37b3-5a53-cf54e681d1c1@quicinc.com> (raw)
In-Reply-To: <20220718061120.GA8922@hu-pkondeti-hyd.qualcomm.com>
Thanks Pavan for the comments!!
On 7/18/2022 11:41 AM, Pavan Kondeti wrote:
>> diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
>> index fabb2e1..df5d353 100644
>> --- a/include/linux/page_ext.h
>> +++ b/include/linux/page_ext.h
>> @@ -64,6 +64,25 @@ static inline struct page_ext *page_ext_next(struct page_ext *curr)
>> return next;
>> }
>>
>> +static inline struct page_ext *get_page_ext(struct page *page)
>> +{
>> + struct page_ext *page_ext;
>> +
>> + rcu_read_lock();
>> + page_ext = lookup_page_ext(page);
>> + if (!page_ext) {
>> + rcu_read_unlock();
>> + return NULL;
>> + }
>> +
>> + return page_ext;
>> +}
>> +
>> +static inline void put_page_ext(void)
>> +{
>> + rcu_read_unlock();
>> +}
>> +
> Would it be a harm if we make lookup_page_ext() completely a private function?
> Or is there any codepath that have the benefit of calling lookup_page_ext()
> without going through get_page_ext()? If that is the case, we should add
> RCU lockdep check inside lookup_page_ext() to make sure that this function is
> called with RCUs.
IIUC, the synchronization is really not needed in all the paths of
accessing the page_ext thus hiding the lookup_page_ext and forcing the
users to always rely on get and put functions doesn't seem correct to me.
Some example code paths where you don't need the synchronization while
accessing the page_ext are:
1) In migration (where we also migrate the page_owner information), we
take the extra refcount on the source and destination pages and then
start the migration. This extra refcount makes the test_pages_isolated()
function to fail thus retry the offline operation.
2) In free_pages_prepare(), we do reset the page_owner(through page_ext)
which again doesn't need the protection to access because the page is
already freeing (through only one path).
Thus I don't find the need of rcu lockdep check in the lookup_page_ext.
Any other paths that I am missing to add protection while page_ext
access, please let me know.
Thanks,
Charan
next prev parent reply other threads:[~2022-07-18 13:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-14 14:47 Charan Teja Kalla
2022-07-15 1:04 ` Andrew Morton
2022-07-15 12:32 ` Charan Teja Kalla
2022-07-18 6:11 ` Pavan Kondeti
2022-07-18 13:15 ` Charan Teja Kalla [this message]
2022-07-18 11:50 ` Michal Hocko
2022-07-18 13:58 ` Charan Teja Kalla
2022-07-18 14:54 ` Michal Hocko
2022-07-19 15:12 ` Charan Teja Kalla
2022-07-19 15:43 ` Michal Hocko
2022-07-19 15:54 ` David Hildenbrand
2022-07-20 15:08 ` Charan Teja Kalla
2022-07-20 15:22 ` Michal Hocko
2022-07-20 8:21 ` Pavan Kondeti
2022-07-20 9:10 ` Michal Hocko
2022-07-20 10:43 ` Charan Teja Kalla
2022-07-20 11:13 ` Michal Hocko
2022-07-19 15:19 ` David Hildenbrand
2022-07-19 15:37 ` Michal Hocko
2022-07-19 15:50 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dcb828a4-b836-37b3-5a53-cf54e681d1c1@quicinc.com \
--to=quic_charante@quicinc.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=quic_pkondeti@quicinc.com \
--cc=shakeelb@google.com \
--cc=sieberf@amazon.com \
--cc=sjpark@amazon.de \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox