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 BF4C7CDB474 for ; Tue, 17 Oct 2023 14:10:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3BE648D0111; Tue, 17 Oct 2023 10:10:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 36DEE8D000C; Tue, 17 Oct 2023 10:10:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 235E38D0111; Tue, 17 Oct 2023 10:10:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 151398D000C for ; Tue, 17 Oct 2023 10:10:31 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1C279160CE0 for ; Tue, 17 Oct 2023 14:10:30 +0000 (UTC) X-FDA: 81355138620.15.C8D89D0 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf11.hostedemail.com (Postfix) with ESMTP id 3E5B040044 for ; Tue, 17 Oct 2023 14:10:25 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=SonJUsEH; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf11.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=1697551826; 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=TyhjTT4pB9EO0fyvzA/m54aikNSBRWtwo+TTKftWgmM=; b=s9eJpKiPUvzQtHu6y3ktTZGhrwjMf1utU0J9ETXuY821eIfZGZHRRGD9GJlIat0YemUOSP NGC8bG7YG6+31nzUiBaIX2YjLZd3zLVKm5vwsC2ALiHZdf6/O1PN84C0YRZ0CjZXjPo5iR U5OsRpFoS7dCWrDx+HJCmdRVonEilWs= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=SonJUsEH; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf11.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=1697551826; a=rsa-sha256; cv=none; b=btdBxaaWeucwbh0eOYUvr2SdLrbgatw2/jCHM+4MlpRapTKagySMpA8DhNJTXRhCc957Ni eF3PQ1i5QwjwOztKuFSGGx4bqTmt/wVpfgm7M9K8uSIhi0ucBy01SeLPqeld0x4Z/Nk/VP Cmf6ULHUJRJpjiGkGORcM/cmcoHPu8w= Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39HCGXUB013219; Tue, 17 Oct 2023 14:10:24 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=TyhjTT4pB9EO0fyvzA/m54aikNSBRWtwo+TTKftWgmM=; b=SonJUsEH/X3RrorQwkBvjODhg9ojLsugwJhQ4rnzJD6mmW7vkNqvxER51yzm8PRLJ/7a KEXF7VrjZZ4S9yC5kv0w5TdMK/1YjQlBFcZwfYI9uJZ961INzlBTVzG6mx19CnwRgfgm gKZFN7g9EAqmJ/nBDzei3wQSAs2kaKEMycCfA20NmJA34MjDE4taDbgy+jR5dG6yaHCs 1QiDpcVTCFUWYyEoHsYrlDoKNzEmu7ef3prCoLpgvNzczsw2nYujrIbFiJXiVSwhAQgH eeApFkegmmdwIYFbAMjFhoBQQlaSJXhAeyo3gc8LZBO+8ap3rmFkcAQZkW3IhKy2/bqn aw== Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3tsb7xj1an-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Oct 2023 14:10:23 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 39HEAMBc026920 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Oct 2023 14:10:22 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; Tue, 17 Oct 2023 07:10:19 -0700 Message-ID: Date: Tue, 17 Oct 2023 19:40:15 +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: Pavan Kondeti CC: , , , , , , , , References: <1697202267-23600-1-git-send-email-quic_charante@quicinc.com> Content-Language: en-US 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) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: 81IvLGkGtB1TAHFuIo4t5iTuYB6uf3sl X-Proofpoint-GUID: 81IvLGkGtB1TAHFuIo4t5iTuYB6uf3sl 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-17_03,2023-10-17_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxlogscore=561 suspectscore=0 lowpriorityscore=0 spamscore=0 bulkscore=0 mlxscore=0 phishscore=0 malwarescore=0 impostorscore=0 clxscore=1015 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2310170119 X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3E5B040044 X-Stat-Signature: hb78kxx5hx7f8r37t3ykbh64qhui83by X-HE-Tag: 1697551825-700166 X-HE-Meta: U2FsdGVkX1/xOjYXzygto7WNY3VciDPnXS0maLIB+JUdS0SuLDxldREkk0K8P9xsUQKf+49bZaUdRa735LgebPLLsvQzLrnU1CVtpJ7hfb0msFcJiL2aSC+EpqeNIkvEkWT/+wp7Jco/dCRNSZMiXN9LTYEH9j6oAN9nrVgSEEWqvR89phmZ5HbaqDpNynZaoan9U911Px/XHyUs1eQyYtd4VfFxZZht4EYXgZODiS0wPpw9asfT121sSeLAqE+u6Ln2b86GNr6ZEnFwGj+whROd8ycxCeouY5yGIjzCK0ees+lr1GHVVxacdbIsvpRkq9rhvFuqc1fEaixntbMPH1dxavgmYA1foa8zQxsGYjzqSyN2R8M+f3FIyICuvwHRw4255R2glQNrBTOGq12NZv8BozNNdUHcWy5SWbACeNevNWO/lKE5x9U4KoSuGkBuEYuhbly3mk8aSAPPwfGGQhjJBHPZaI0gP1D892dkVL9YTOn+gAoGQK5I2tNFP58T2ajU66zkeXDktOvSCP0AQFRR6HaFlyGRvKAZ/UuZVzZlfhaHN8MPNU3xekpOPA95PfH9boctJcteEURwNfZDr2HUu4uct+XVjY8Jf52MFU+7Nq0EcBIVTB3nLXW8RThHfgKHxlqyBXcJzk93LpxVn2ejCzfekoyhlRD07WLJso7ztxPSCiOnGjGQ3XYqHUzVQLVFDSQwEt6BbWJV+6nXzKszAKCvyQsZQ7fahEvQJp3aDqord/X1i7UY6Tr6j25CEDdpeb7Oo5FTEdyER2Q61L9xGMG7t83dzUxHyZSZeOW3+ri3Qaw5b4ko6yp12cVSxgtKOMxs7QsDBwfTUhLmMzmSkbNMZcnjLd8HTSKkiBodGG++e1xPI32+LelifrS/0AM4pt+9xsvKrtmegQVPGw65hWvXRjNOWZXwDcQvzD3pe4YGmSBLRKi4ShI82pTGI4GrPrFj/lkc9yn26Gc lmAZNQQZ D0lnZJFKLua56CwifusNRfLdlLt6umyPEcU5G41c16XETzK6HjFVbHymAaISSFG3i1Y1cng17qamWS3icSumkVX3Ax56NcMoMjp+3WdVNk1CuFPbbMjwruYEj/ChPcxUgym4MvFoYaCgJwcjeydlgrvbV4ATtvGQXDaI2yRR7KKEFHbFXv5PtEFb+2OePhNKcTZxRohMg93Fw+MGGuiFDegcuXfyJ5F2/MNQ8CzanrnpM7Cyqlcdf3t50XYyD7YL6hCn2IayY8Y4n17Z8YbISviJ1QQ== 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!! On 10/16/2023 4:03 PM, Pavan Kondeti wrote: >> 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. >> >> Since the section_deactivate() is a rare operation and will come in the >> hot remove path, impact of synchronize_rcu() should be negligble. > struct mem_section_usage has other field like pageblock_flags. Do we > need to protect its readers with RCU? Also can we annotate usage field > in struct mem_section with __rcu and use RCU accessors like > rcu_dereference() while using memsection::usage field? Good question about the pageblock_flags!! I think we rely on the get_pageblock_bitmap() to read the ms->usage->pageblock_flags by passing struct page*. 1) All the functions that I have come across calling get_pageblock_bitmap()/get_pfnblock_flags_mask() passing the page* which it get from buddy. I think we are safe here as the device pages(from which the problem is coming will never be onlined/added to buddy) 2) There are functions in compaction which directly operate on the pfn's through pfn_to_online_page(). As for device pages, it is going to return NULL, I think we are safe here too. 3) alloc_contig_range() which also operate on the pfn's directly, and TMK, we will not pass the [start , end) values of this function to contains the hole/offlined pages. I think we are safe here too. May be David/other reviewers can help in commenting if there are some mistakes above. I am currently working on to use the __rcu accessors. > >> /* >> + * Mark the section invalid so that valid_section() >> + * return false. This prevents code from dereferencing >> + * ms->usage array. >> + */ >> + ms->section_mem_map &= ~SECTION_HAS_MEM_MAP; >> + > This trick may not be needed if we add proper NULL checks around ms->usage. We are anyway > introducing a new rule this check needs to be done under RCU lock, so why not revisit it? > I think this is for valid_section(). >> * was allocated during boot. >> */ >> if (!PageReserved(virt_to_page(ms->usage))) { >> + synchronize_rcu(); >> kfree(ms->usage); >> ms->usage = NULL; >> } > If we add NULL checks around ms->usage, this becomes > > tmp = rcu_replace_pointer(ms->usage, NULL, hotplug_locked()); > syncrhonize_rcu(); > kfree(tmp); Per David input, I am working on using kfree_rcu(). Thanks, Charan