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 1DA68CDB482 for ; Mon, 16 Oct 2023 13:38:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B0C028D0085; Mon, 16 Oct 2023 09:38:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ABC2D8D0001; Mon, 16 Oct 2023 09:38:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91E718D0085; Mon, 16 Oct 2023 09:38:13 -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 7FB988D0001 for ; Mon, 16 Oct 2023 09:38:13 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 4A0E8A06AD for ; Mon, 16 Oct 2023 13:38:13 +0000 (UTC) X-FDA: 81351428466.09.076383F Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf10.hostedemail.com (Postfix) with ESMTP id F1229C0024 for ; Mon, 16 Oct 2023 13:38:10 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=jCNGBrfe; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf10.hostedemail.com: domain of quic_charante@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_charante@quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697463491; a=rsa-sha256; cv=none; b=ueAqbyQOkyBwhMl5CWxs29qWW7859QfYJuM3fS1k12FshbjS+Q8Ey6lDsyyJZ7zcx36wBu wL5jCocYKHkgpcKh0Gxe7cpvKAAfO+e2wMHYh41l29fxc5pCenlJKe+vh7RfyO8TR8zYKl uj0RsFyrtz9/8paJ8SliGCFC/psA+hw= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=jCNGBrfe; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf10.hostedemail.com: domain of quic_charante@quicinc.com designates 205.220.180.131 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=1697463491; 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=4dUZoaXroPnIYe+E5tKQv90XkTcgsEWMUCoq+h51ths=; b=HK7hq3VNSHAmB9/AbUqA46ZH5u7NG2Hb91jhgQn2JlvRdRgle8xxUgjMvWisFJKELn/LCQ LtjTNbY/Ne3vIiUF2CDE/EM5bNVCU0160fIxtvBUlAFYB2ggkCLwSxGx/b32HgxVp9p2VA 6R6dNVlWvPlwX3jtpnDT0Cz+pFfozsw= Received: from pps.filterd (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39GBUGb8021402; Mon, 16 Oct 2023 13:38:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=4dUZoaXroPnIYe+E5tKQv90XkTcgsEWMUCoq+h51ths=; b=jCNGBrfeK2efbqEQ80cDsLzc7GKJv+TrtP0Y3w7dyrUZwwk0hyPQ8NM4ChTrh9T9hNKE S7rfW2QLj71I8p56eTjNIihc4x43LRyuFJ0W6xiBQnpADYfpWZaeoLBRzDDdi+3faDFw M/W+/CMApoJ38xAFEYYheGn/obFQqOMhv4hVSyWX6NtYeq/SHRFcJR2jkpsiyMpEf5cV Zn9b95ez2qeTJfnFlMWUX+GCyhofdpWwqjpLHfDUOdzX04jwMU4M5cOiK4QzEEhH2cOo DbfcyKsm1lMGG8U7iMCR9/mzqjaz6RaR0STwAdkz2xy6JDY56AjgG1vuJJgxzdYzjQaB 5g== Received: from nalasppmta03.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3tqk2yv6pq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Oct 2023 13:38:07 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA03.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 39GDc6DX031568 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Oct 2023 13:38:06 GMT Received: from [10.214.66.119] (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.1118.39; Mon, 16 Oct 2023 06:38:03 -0700 Message-ID: <994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com> Date: Mon, 16 Oct 2023 19:08:00 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH] mm/sparsemem: fix race in accessing memory_section->usage To: David Hildenbrand , Andrew Morton CC: , , , , , , References: <1697202267-23600-1-git-send-email-quic_charante@quicinc.com> <20231014152532.5f3dca7838c2567a1a9ca9c6@linux-foundation.org> Content-Language: en-US From: Charan Teja Kalla In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: 6PTa4NeRHXIA0iEtJNhQuIt2EdxzNnSz X-Proofpoint-ORIG-GUID: 6PTa4NeRHXIA0iEtJNhQuIt2EdxzNnSz X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-16_06,2023-10-12_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 mlxlogscore=999 mlxscore=0 clxscore=1015 phishscore=0 bulkscore=0 impostorscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2310160118 X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: F1229C0024 X-Stat-Signature: 8dbhdfji1dje4jgz5uiktdakqn1cdwno X-HE-Tag: 1697463490-970733 X-HE-Meta: U2FsdGVkX1/MONlLGqGxscC5zlc2j9+KigqvGHCWDhqw64GWzQ4prZjcq/BLMWwc/kgyv4WVwMMQt4HPaMjt/53spEyy1KXDZKmXYagN6zULMOMwgkDzQeBxTcpNXX9cxxHvPM2wk6WVtbnengfWWkeuGHUA0U13qm3zgwMaJZgPKG/NTVh1uKiQRFPGFa0GFkGzNvBBtUriL3iFvHajZRA+kjeQZFmU3hJDxl2X1Srj7XQfWHGD37dFSSNUp5sUhGhei1NNtWKg11tR7lZuNCO3oTlPIRO+asRgbxxCshBr+eYWdS4wRZOKuBqyatb0676nayfVFRCRTC92FoecFc9Ke7FlwVleoPLBEdBw2s3FcCQVUT7qmD842JrH71gRdn95Ko9CZgTw+mMizKP1egD19BSUd/9ww27eXbI+OiFHaB8zCJ/CC40EqZEy0tjVONMe2Qgao6S9huO03Jv9EujCAXUFfkYV5rTiE1dZTTvoLQT8Wq5z9QyGo7NaeiF7liyS0T5xYWshRLsOjmq2A78orIic3waEGQ1IIGyks+LYp8wun46skSfFFbjKLUpGcpcnd9LYkjz4K93wjRWTSnin7vN9L+qx/BSalIXe2DWZZdzddoTsCAP6Ai406DHO4Ldw7X+0m/kpeyh0Cge//BIuMaTbj+hLrVgp34fV3Rev+yDpeR9PY6AJzNOh7C8NVsi3hrWUWt5A0EreQeSUWIvUibDsvENyReCNTgoS88xskp0xKQ3rIa5DkZReQxsvLoHtR+WecVCADOfAvmhVPx/D3UFwgdhXcheAed/u1K38uqC/9PKITQiWcC+H7OsKEdOh7X94S+CsQ7QtAPG6Y+KxLgj8iSdOLRoUn83fxQF3+xCwjA048AGpPItDgaKkcPC6oKnCjp8qJYuH20SaB8zvUNgE/VbnUsOmJFB0HpZDHIBWlVDY00Cjsa+pljT8qZRZgl18l/LgwEps0F4 wWfk1Ffm l/FkY6WERQ3mvkYM+xrY+ZiR1L323XmNH7XzXExkfTd1urkCX9xzBrCQzN9f617H7k6SX0j2fASqTK9FuJO5WrMNncYObASZnyuEnSXHjiU2eHFGduYsAOPMTWBUrJ7pI+Z6Z/ikvNbT+gda/YBLiUBIq1EHPmUyaEMqZq5ylx3zwaCCUYxTVLr4gAIWKW+kjC6xQ7tOA7poR82D0KmzM9yB6uuWs3OV6qasvqaC2JamTK6Vbs8hmlU3+24MT+0kzpqJCm+tRzbnbuHfEg2SfDaHtBWmKcyzeCqdVSzDagyFoDv0aXnpxnZ3FuEH5WJRNZoWDXvd/aofxYDN9bOzVf/cLO9TddN+4zs7LNN2UMAwVEWshiBMvEyiz2yYFOIPa2LJ8u1dciUBSez0= 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 Andrew/David, On 10/16/2023 1:53 PM, David Hildenbrand wrote: >>> The below race is observed on a PFN which falls into the device memory >>> region with the system memory configuration where PFN's are such that >>> [ZONE_NORMAL ZONE_DEVICE  ZONE_NORMAL]. Since normal zone start and >>> end pfn contains the device memory PFN's as well, the compaction >>> triggered will try on the device memory PFN's too though they end up in >>> NOP(because pfn_to_online_page() returns NULL for ZONE_DEVICE memory >>> sections). When from other core, the section mappings are being removed >>> for the ZONE_DEVICE region, that the PFN in question belongs to, >>> on which compaction is currently being operated is resulting into the >>> kernel crash with CONFIG_SPASEMEM_VMEMAP enabled. >> >> Seems this bug is four years old, yes?  It must be quite hard to hit. > > From the description, it's not quite clear to me if this was actually > hit -- usually people include the dmesg bug/crash info. On Snapdragon SoC, with the mentioned memory configuration of PFN's as [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of issues daily while testing on a device farm. I note that from next time on wards will send the demsg bug/crash info for these type of issues. For this particular issue below is the log. Though the below log is not directly pointing to the pfn_section_valid(){ ms->usage;}, when we loaded this dump on T32 lauterbach tool, it is pointing. [ 540.578056] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 540.578068] Mem abort info: [ 540.578070] ESR = 0x0000000096000005 [ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits [ 540.578077] SET = 0, FnV = 0 [ 540.578080] EA = 0, S1PTW = 0 [ 540.578082] FSC = 0x05: level 1 translation fault [ 540.578085] Data abort info: [ 540.578086] ISV = 0, ISS = 0x00000005 [ 540.578088] CM = 0, WnR = 0 [ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) [ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c [ 540.579454] lr : compact_zone+0x994/0x1058 [ 540.579460] sp : ffffffc03579b510 [ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27: 000000000000000c [ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24: ffffffc03579b640 [ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21: 0000000000000000 [ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18: ffffffdebf66d140 [ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15: 00000000009f4bff [ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12: 0000000000000001 [ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffff897d2cd440 [ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffffffc03579b5b4 [ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 : 0000000000000001 [ 540.579518] x2 : ffffffdebf7e3940 x1 : 0000000000235c00 x0 : 0000000000235800 [ 540.579524] Call trace: [ 540.579527] __pageblock_pfn_to_page+0x6c/0x14c [ 540.579533] compact_zone+0x994/0x1058 [ 540.579536] try_to_compact_pages+0x128/0x378 [ 540.579540] __alloc_pages_direct_compact+0x80/0x2b0 [ 540.579544] __alloc_pages_slowpath+0x5c0/0xe10 [ 540.579547] __alloc_pages+0x250/0x2d0 [ 540.579550] __iommu_dma_alloc_noncontiguous+0x13c/0x3fc [ 540.579561] iommu_dma_alloc+0xa0/0x320 [ 540.579565] dma_alloc_attrs+0xd4/0x108 >>> Fix this issue by the below steps: >>> a) Clear SECTION_HAS_MEM_MAP before freeing the ->usage. >>> b) RCU protected read side critical section will either return NULL when >>> SECTION_HAS_MEM_MAP is cleared or can successfully access ->usage. >>> c) Synchronize the rcu on the write side and free the ->usage. No >>> attempt will be made to access ->usage after this as the >>> SECTION_HAS_MEM_MAP is cleared thus valid_section() return false. > > > This affects any kind of memory hotunplug. When hotunplugging memory we > will end up calling synchronize_rcu() for each and every memory section, > which sounds extremely wasteful. > > Can't we find a way to kfree_rcu() that thing and read/write the pointer > using READ?ONCE?WRITE_ONCE instead? I am inspired to use the synchronize_rcu() because of [1] where we did use it in offline_page_ext(). And my limited understanding is that, a user can trigger the offline operation more often than the unplug operation. I agree here that there is a scope to use kfree_rcu() unlike in [1]. Let me check for a way to use it. [1] https://lore.kernel.org/all/1661496993-11473-1-git-send-email-quic_charante@quicinc.com/ Thanks, Charan