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 21BEEC43334 for ; Mon, 27 Jun 2022 16:09:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 94BDE8E0001; Mon, 27 Jun 2022 12:09:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FC1F6B0072; Mon, 27 Jun 2022 12:09:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C3888E0001; Mon, 27 Jun 2022 12:09:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 69BF66B0071 for ; Mon, 27 Jun 2022 12:09:54 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 23F4412051D for ; Mon, 27 Jun 2022 16:09:54 +0000 (UTC) X-FDA: 79624501908.13.3DE2E8D Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) by imf25.hostedemail.com (Postfix) with ESMTP id 5BF6DA0027 for ; Mon, 27 Jun 2022 16:09:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1656346193; x=1687882193; h=message-id:date:mime-version:from:subject:to:cc: content-transfer-encoding; bh=arpBUc08W6JN7v2EclQD7sfV+U15Bjx2FHnJF1KXgwc=; b=kFQbgNq3U8IVP2xCOeTwpoIGOsrxip+0cb5ObpNlbURowl4yyWrQrwtV aGorap1lmILisfXxMAOhdi1IH5K1I0ZQgwCJK6uNJlQnneyJH/F1Enomf 2bljohh9+/78/ikiHHxjV8bRGDd7YvJQUBGrqsZAa1DnuynsA8Xhr1XJE o=; Received: from unknown (HELO ironmsg-SD-alpha.qualcomm.com) ([10.53.140.30]) by alexa-out-sd-02.qualcomm.com with ESMTP; 27 Jun 2022 09:09:52 -0700 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg-SD-alpha.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2022 09:09:51 -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, 27 Jun 2022 09:09:39 -0700 Received: from [10.216.8.122] (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, 27 Jun 2022 09:09:36 -0700 Message-ID: <59edde13-4167-8550-86f0-11fc67882107@quicinc.com> Date: Mon, 27 Jun 2022 21:39:32 +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 Content-Language: en-US From: Charan Teja Kalla Subject: Discussion on race between freed page_ext access and memory offline operation To: Andrew Morton , Michal Hocko , David Hildenbrand , Vlastimil Babka , Minchan Kim CC: "linux-mm@kvack.org" , LKML 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=1656346193; 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: references:dkim-signature; bh=arpBUc08W6JN7v2EclQD7sfV+U15Bjx2FHnJF1KXgwc=; b=Nn+v067/zdQUWtD35VGUI6k7KpEe4j69b003W5eTeYP+2pbM7VdqM/JSmQ42VWmLbneOxr bE2Z/qKH1hOLQx9KPE4+2LAf9vTbc5eleMco1RXbrzzLi4NasybJm87pOiMQ/EIFfwI1V6 iVSULnDI6coWyTq6r/xaJqqGCw9QzvY= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcdkim header.b=kFQbgNq3; spf=pass (imf25.hostedemail.com: domain of quic_charante@quicinc.com designates 199.106.114.39 as permitted sender) smtp.mailfrom=quic_charante@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656346193; a=rsa-sha256; cv=none; b=4yhliAwgqkXabbrkYPfG1elB2tTWGUuk8YTq0IZ3zdNN/4e2x2c4VQpkrPEVakfOnqJeNz 3Ul3P9wIZtEuacDS71Z1K2h59wYDghq/psgl0zbAHxo3GG4JLjCC0vXHmEaJQLLk3vgeen MAQGOZzOQvEpckf0wd2V8aiqTyUHvOA= Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcdkim header.b=kFQbgNq3; spf=pass (imf25.hostedemail.com: domain of quic_charante@quicinc.com designates 199.106.114.39 as permitted sender) smtp.mailfrom=quic_charante@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: 3erreyh3aferme9ahdp366hmnggae8d3 X-Rspamd-Queue-Id: 5BF6DA0027 X-HE-Tag: 1656346193-685987 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: The below race between page_ext and online/offline of the respective memory blocks will cause use-after-free on the access of page_ext structure. process1 process2 --------- --------- a)doing /proc/page_owner doing memory offline through offline_pages b)PageBuddy check is failed thus proceed to get the page_owner information through page_ext access. page_ext = lookup_page_ext(page); migrate_pages(); ................ Since all pages are successfully migrated as part of the offline operation,send MEM_OFFLINE notification where for page_ext it calls: offline_page_ext()--> __free_page_ext()--> free_page_ext()--> vfree(ms->page_ext) mem_section->page_ext = NULL c) Check for the PAGE_EXT flags in the page_ext->flags access results into the use-after-free(leading to the translation faults). As mentioned above, there is really no synchronization between page_ext access and its freeing in the memory_offline. The above is just one example but the problem persists in the other paths too involving page_ext->flags access(eg: page_is_idle()). The memory offline steps(roughly) on a memory block is as below: 1) Isolate all the pages 2) while(1) try free the pages to buddy.(->free_list[MIGRATE_ISOLATE]) 3) delete the pages from this buddy list. 4) Then free page_ext.(Note: The struct page is still alive as it is freed only during hot remove of the memory which frees the memmap, which steps the user might not perform). This design leads to the state where struct page is alive but the struct page_ext is freed, where the later is ideally part of the former which just representing the page_flags. This seems to be a wrong design where 'struct page' as a whole is not accessible(Thanks to Minchan for pointing this out). Some solutions we think are: ---------------------------- 1) Take the mem_hotplug_lock read_lock every time page_ext access. 2) Take the extra refcount on the page every time page_ext access is made, so that parallel offline operation can't free the page to buddy. 3) Change the design where the page_ext is valid as long as the struct page is alive. Any other inputs here? PS: This bug is uncovered while fixing the same page_ext access issue with the page pinner(https://lore.kernel.org/linux-mm/20211206184730.858850-1-minchan@kernel.org/) on Andorid. Thanks, Charan