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 C6BF5C43334 for ; Mon, 18 Jul 2022 13:15:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 56B528E0001; Mon, 18 Jul 2022 09:15:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 51AB56B0075; Mon, 18 Jul 2022 09:15:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 430E38E0001; Mon, 18 Jul 2022 09:15:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 33CEB6B0074 for ; Mon, 18 Jul 2022 09:15:31 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 06B3480CB9 for ; Mon, 18 Jul 2022 13:15:31 +0000 (UTC) X-FDA: 79700267262.31.25CA40E Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) by imf09.hostedemail.com (Postfix) with ESMTP id 25AAB14008C for ; Mon, 18 Jul 2022 13:15:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1658150129; x=1689686129; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=WuwN+DpRDQCRT2t6w+txR2Q5PHcMEbq4bLidubJqWvc=; b=t0FpLOzj85Cn5cbptqWrsL3H2SIe6GGyT9xGHfxhg/iNZvY1yIDYPW9k 3ycCMQxA1wKv7aF5vxDNe792skN/i03fioY6LWLQTHaTQe8TxpeMBIv+3 SrTp3dPYPDna+jkLxTdYBkppTYglN9WGMHFDpFQ486g/xlDlzMgvIxcoh w=; 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:15:27 -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:15:27 -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:15:27 -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:15:22 -0700 Message-ID: Date: Mon, 18 Jul 2022 18:45:19 +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: Pavan Kondeti CC: , , , , , , , , , , , , References: <1657810063-28938-1-git-send-email-quic_charante@quicinc.com> <20220718061120.GA8922@hu-pkondeti-hyd.qualcomm.com> From: Charan Teja Kalla In-Reply-To: <20220718061120.GA8922@hu-pkondeti-hyd.qualcomm.com> 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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658150129; a=rsa-sha256; cv=none; b=TeVRYDaBQSWEwaOAbLISKpHjOsjqpHaP4SU8ehk40e0H2I53jqY4sjevTEc50HWOyW1IIj Jrg6z3LsCqp3uW8Ybtnk/ZOXcuDGtWk/SxvLY3wcNXp7Xjz4aK/5GAzzNpydZdlXIxZpkJ f9mzTDy5GpDWiLd9rZNNKJYETW6Q0aw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcdkim header.b=t0FpLOzj; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf09.hostedemail.com: domain of quic_charante@quicinc.com designates 199.106.114.38 as permitted sender) smtp.mailfrom=quic_charante@quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658150129; 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=WuwN+DpRDQCRT2t6w+txR2Q5PHcMEbq4bLidubJqWvc=; b=P3Pb+JXGbzVX/ljtiPWzWH8veN+V4K4YejTkrd4h3uO/LumIFADqnyMm4jg6eNB5U4iFhA D4ZrfPslisvT8RSS7mc599emVYVLhobn6R5OF5ZaAIB8O4kv44JwHKYNmf5+lC6CvXb//f adLJ0s1dzMIs2S8IJEvyeMjdZ1w2PzM= X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcdkim header.b=t0FpLOzj; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf09.hostedemail.com: domain of quic_charante@quicinc.com designates 199.106.114.38 as permitted sender) smtp.mailfrom=quic_charante@quicinc.com X-Rspamd-Queue-Id: 25AAB14008C X-Rspamd-Server: rspam12 X-Stat-Signature: 15o1nhr8bry9gjkermk3imuy9ik1h7zy X-HE-Tag: 1658150128-827914 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 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