From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3CF6C43334 for ; Mon, 18 Jul 2022 13:58:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 270356B0072; Mon, 18 Jul 2022 09:58:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 21E7C6B0073; Mon, 18 Jul 2022 09:58:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E82D6B0074; Mon, 18 Jul 2022 09:58:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0074B6B0072 for ; Mon, 18 Jul 2022 09:58:24 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id CD065120CFC for ; Mon, 18 Jul 2022 13:58:24 +0000 (UTC) X-FDA: 79700375328.20.808E20A Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) by imf28.hostedemail.com (Postfix) with ESMTP id 1DC28C0080 for ; Mon, 18 Jul 2022 13:58:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1658152703; x=1689688703; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=vf4REEPL4Gjd3BgNJelj9yn/G1FQopQlzM8XP/ubJLU=; b=rdbupcgnMhZ17W4rkPVe5I1owpGmtfIz5PTc4Z860i2IN99Dx56YsDav 2rfxvGH5Vqh7X11dCQaKbv0IM4kx6JcDCxF6u3Y8ThdM/S3rc23MyVCBu OEAn7o0XzCsGX/unw5uLofmkpMAEiG4MeTjueINBYAxADZvxR9nID5WbI 4=; Received: from unknown (HELO ironmsg02-sd.qualcomm.com) ([10.53.140.142]) by alexa-out-sd-01.qualcomm.com with ESMTP; 18 Jul 2022 06:58:22 -0700 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg02-sd.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2022 06:58:21 -0700 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Mon, 18 Jul 2022 06:58:21 -0700 Received: from [10.216.50.214] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Mon, 18 Jul 2022 06:58:16 -0700 Message-ID: Date: Mon, 18 Jul 2022 19:28:13 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH] mm: fix use-after free of page_ext after race with memory-offline Content-Language: en-US To: Michal Hocko CC: , , , , , , , , , , , , "iamjoonsoo.kim@lge.com" References: <1657810063-28938-1-git-send-email-quic_charante@quicinc.com> From: Charan Teja Kalla In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658152703; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vf4REEPL4Gjd3BgNJelj9yn/G1FQopQlzM8XP/ubJLU=; b=jHRTlqZ3kqos+L0AofcUorb80AeWjS8Xwk04YE/TqC2OzZkny//Ea/CDtDeWIMIPJtgsMe 8S7nuaQ+LEZdc74kVgF8+HhcgIj4Gl0mcJN8DtG9QCANdkvRlAF9y1/uh5VepNzF6Y5UQa r/ZZXFGye0MP4umqe1AlSDrwI/3joP0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658152703; a=rsa-sha256; cv=none; b=bU3F/KQBZVt7YFD56QsCiEjkUINzLuWobrsJV0GhpSkODjUK7MPKhokmOaRyGdgYQ/xyGj 0knFUjtmsREZJ1hD037ky7e8YVwpfI+LSGcXpxCXd5k3yKj59D2UZK1LrnYYFr5It9C/Go yd/DUc4+aq51MwBmL0PwXw0hWEhr35I= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcdkim header.b=rdbupcgn; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf28.hostedemail.com: domain of quic_charante@quicinc.com designates 199.106.114.38 as permitted sender) smtp.mailfrom=quic_charante@quicinc.com X-Stat-Signature: uo9f3tjknyy5emxbcqq8fthikzod777d X-Rspam-User: X-Rspamd-Queue-Id: 1DC28C0080 X-Rspamd-Server: rspam10 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcdkim header.b=rdbupcgn; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf28.hostedemail.com: domain of quic_charante@quicinc.com designates 199.106.114.38 as permitted sender) smtp.mailfrom=quic_charante@quicinc.com X-HE-Tag: 1658152702-294289 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Thanks Michal for the comments!! On 7/18/2022 5:20 PM, Michal Hocko wrote: >> The above mentioned race is just one example __but the problem persists >> in the other paths too involving page_ext->flags access(eg: >> page_is_idle())__. Since offline waits till the last reference on the >> page goes down i.e. any path that took the refcount on the page can make >> the memory offline operation to wait. Eg: In the migrate_pages() >> operation, we do take the extra refcount on the pages that are under >> migration and then we do copy page_owner by accessing page_ext. For >> >> Fix those paths where offline races with page_ext access by maintaining >> synchronization with rcu lock. > Please be much more specific about the synchronization. How does RCU > actually synchronize the offlining and access? Higher level description > of all the actors would be very helpful not only for the review but also > for future readers. I will improve the commit message about this synchronization change using RCU's. > > Also, more specifically > [...] >> diff --git a/mm/page_ext.c b/mm/page_ext.c >> index 3dc715d..5ccd3ee 100644 >> --- a/mm/page_ext.c >> +++ b/mm/page_ext.c >> @@ -299,8 +299,9 @@ static void __free_page_ext(unsigned long pfn) >> if (!ms || !ms->page_ext) >> return; >> base = get_entry(ms->page_ext, pfn); >> - free_page_ext(base); >> ms->page_ext = NULL; >> + synchronize_rcu(); >> + free_page_ext(base); >> } > So you are imposing the RCU grace period for each page_ext! This can get > really expensive. Have you tried to measure the effect? > I didn't really measure the effect. Let me measure it and post these in V2. > Is there any reason why page_ext is freed during offlining rather when > it is hotremoved? This is something I am struggling to get the answer. IMO, this is even wrong design where I don't have page_ext but page. Moving the freeing of page_ext to hotremove path actually solves the problem but somehow this idea didn't liked[1]. copying the excerpt here: "> > 3) Change the design where the page_ext is valid as long as the struct > page is alive. :/ Doesn't spark joy." @Joonsoo : We see that you did commit eefa864b701d ("mm/page_ext: resurrect struct page extending code for debugging"). Any reason why the page_ext is chosen to free at offline operation rather than the remove operation of a memory block? [1] https://lore.kernel.org/linux-mm/8fefe59d-c893-39f4-3225-65343086c867@redhat.com/ > > Thanks!