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 CB25DC77B7E for ; Wed, 24 May 2023 03:12:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3CCC1280003; Tue, 23 May 2023 23:12:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 37DD3280001; Tue, 23 May 2023 23:12:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26C17280003; Tue, 23 May 2023 23:12:12 -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 1775C280001 for ; Tue, 23 May 2023 23:12:12 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CC13E12060E for ; Wed, 24 May 2023 03:12:11 +0000 (UTC) X-FDA: 80823674862.22.9EB907C Received: from out-8.mta0.migadu.com (out-8.mta0.migadu.com [91.218.175.8]) by imf30.hostedemail.com (Postfix) with ESMTP id B83B780010 for ; Wed, 24 May 2023 03:12:08 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=DGy36fVx; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf30.hostedemail.com: domain of qi.zheng@linux.dev designates 91.218.175.8 as permitted sender) smtp.mailfrom=qi.zheng@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684897929; 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=KjGgDwsaWYQjGKLlgM4P0do5d+jCOeVp4sk/adTJ35M=; b=Q6mQejrYpT0/wwOy6YVaYwPN/FKEH2We+kepwxd+WBlCuYfQO86DWEGQ0ziVcty+CfAJH7 WoP0nK4wSEbvYBA/Dtbec6A1yPwepyg2rurnCIRLmm+m0aILfatikoKzDmKRs8xAPFHp08 BzA7gmCMpEStdaL5+PAZeBHiTTPlAbU= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=DGy36fVx; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf30.hostedemail.com: domain of qi.zheng@linux.dev designates 91.218.175.8 as permitted sender) smtp.mailfrom=qi.zheng@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684897929; a=rsa-sha256; cv=none; b=dRDwh1C6Wk6sFQL6qLCCYqUBthu/LHIHhsGUyRt4UhULRuJic40X9GYgUVxxZJy45tedYP xpOT2m5GxlsltDfSxZUWdHbESMPcwQZutxIOxCfhWn0ix5MYT1OlJoB6j7U5+sBlrV8RiY umvUtkCJ/KC+zP/CTn20RDWLQWYcGA8= Message-ID: <06996a88-4248-d909-dc06-5af1ba580ef3@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1684897926; h=from:from: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; bh=KjGgDwsaWYQjGKLlgM4P0do5d+jCOeVp4sk/adTJ35M=; b=DGy36fVxR3ozLUoXI7o+2j4P+fBJx/CiDo7kPqpMCulWoJWa61A3MI1DcCwWSgIj0pbPos gqTt6zWZjG+fWWLdSMUMm80WiPHZvmVqyFa3yjoez9cyemw4dP6xHiZxiRSEVGbBiqY5zl Pu6DdNjiDQWNUKnwXraTKBEW6kEGSWc= Date: Wed, 24 May 2023 11:11:48 +0800 MIME-Version: 1.0 Subject: Re: [PATCH 04/31] mm/pgtable: allow pte_offset_map[_lock]() to fail Content-Language: en-US To: Hugh Dickins Cc: Andrew Morton , Mike Kravetz , Mike Rapoport , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Suren Baghdasaryan , Qi Zheng , Yang Shi , Mel Gorman , Peter Xu , Peter Zijlstra , Will Deacon , Yu Zhao , Alistair Popple , Ralph Campbell , Ira Weiny , Steven Price , SeongJae Park , Naoya Horiguchi , Christophe Leroy , Zack Rusin , Jason Gunthorpe , Axel Rasmussen , Anshuman Khandual , Pasha Tatashin , Miaohe Lin , Minchan Kim , Christoph Hellwig , Song Liu , Thomas Hellstrom , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <68a97fbe-5c1e-7ac6-72c-7b9c6290b370@google.com> <8218ffdc-8be-54e5-0a8-83f5542af283@google.com> <9dc72654-79db-e988-54a8-488550d235ac@linux.dev> <1efc993b-5b41-4895-a4d-20d38eb95de5@google.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Qi Zheng In-Reply-To: <1efc993b-5b41-4895-a4d-20d38eb95de5@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: B83B780010 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: atyxn3x4t9un4y3yjt9q8jatdeo33k9t X-HE-Tag: 1684897928-920589 X-HE-Meta: U2FsdGVkX192vMe9//EvMWSmL+qD3Q/4Zp4ARENnw9bvAL8ZIZlZ9GdsXM1u37kkGx23iQYg5KmkopX6jugGzC1qZVkPRW3IpWtGlVMcmhK9K25wGeFYa9bBlvewBs+gnD9NDoZnB8fu1Ueva530Kc6ZASC5Jf6xwEjodjob0JbR8ov/MAFzvuH6dvaFvifHX5+9gqbBt938MtR219uIo0VtK/wx4W/7yADmB230E0v1FPv0wFJj3MknPf3FmqsulZ8jPjVZvgyQansuzC8YEfoI39p8bFQtv/O8Ax90GkilukaTwk1ibN9NKCA3/SQzwxkkWxvWavUs6bIQYaCAG9mfR+iSxBDexwv2KJ7UFT5iJZiqmD6CFeL5tbz1u4E/xpV4MSmH2S3Rmm0B45vcnq1e/W9Fhw6Yogr+nx2ZKJGX8vRa4NUVpzJvQgh6x64D3DKRGm71+GBb0y3mks8+2a6wLXnO5f8FL1zmBHlg5HarQwMxigFmWq2ThMwA116XhvWFJ0WHDcMrcqrNYhQhEAgMCF4OrRNpOprZyJqvIRqA/xI127gaUFNNBSS/qBiej47VMTjhqHKj3+v+9iA89/olvt1PCL9U4cjqbQQpI+vMMq863hdj09nLZp4Y3IFT9mOnKVRPIu1ICw2FY9nOELMRJuhxjD5NlfwJ31/+9j29V1gBZICTBRRxpFl/PDl9Yue/hCzsBZ4uQHbF/5sjI6/d8HL2dkRO5iwHJhP2aQ4N8kn24+/j8CbBpVjIOcgHSsIt8VuaZkL6Bt3vbngNoXH1KWA5gOvrwsoPzWOOqILY5syPIfuGaSWVUNfAm9395OZR54GioNUBeOvy3G/GtGIavdCayGAUEkkbPBi2Muz2thhachu58Onn8tg87HrN5sMn26cAVq2+7kmIZhoVGGUSyY03UWJ5OO5RMzXCZ3p+1h2JmGCC1JBUIBLoRwdpQK3a0b5cuAYNxdK6lPq roj41Ue6 q178whoe0v7j9ZTPbdafNm+zlJcpbAMVck+X775cl2uzgwSObT1iwjRk8bIuMEShZ/6IBJ4Oyr0Wbet6ZK56hI/9GUztoKSY3lCbpT+YVqBM39XSfQ+ZMtwJohhmT/tqo4JQgYBioepY2d9k= 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: On 2023/5/24 10:22, Hugh Dickins wrote: > On Mon, 22 May 2023, Qi Zheng wrote: >> On 2023/5/22 12:53, Hugh Dickins wrote: >> >> [...] >> >>> @@ -229,3 +231,57 @@ pmd_t pmdp_collapse_flush(struct vm_area_struct *vma, >>> unsigned long address, >>> } >>> #endif >>> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ >>> + >>> +pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp) >>> +{ >>> + pmd_t pmdval; >>> + >>> + /* rcu_read_lock() to be added later */ >>> + pmdval = pmdp_get_lockless(pmd); >>> + if (pmdvalp) >>> + *pmdvalp = pmdval; >>> + if (unlikely(pmd_none(pmdval) || is_pmd_migration_entry(pmdval))) >>> + goto nomap; >>> + if (unlikely(pmd_trans_huge(pmdval) || pmd_devmap(pmdval))) >>> + goto nomap; >> >> Will the follow-up patch deal with the above situation specially? > > No, the follow-up patch will only insert the rcu_read_lock() and unlock(); > and do something (something!) about the PAE mismatched halves case. > >> Otherwise, maybe it can be changed to the following check method? >> >> if (unlikely(pmd_none(pmdval) || pmd_leaf(pmdval))) >> goto nomap; > > Maybe, but I'm not keen. Partly just because pmd_leaf() is quite a > (good) new invention (I came across a few instances in updating to > the current tree), whereas here I'm just following the old examples, > from zap_pmd_range() etc. I'd have to spend a while getting to know > pmd_leaf(), and its interaction with strange gotchas like pmd_present(). > > And partly because I do want as many corrupt cases as possible to > reach the pmd_bad() check below, so generating a warning (and clear). > I might be wrong, I haven't checked through the architectures and how > pmd_leaf() is implemented in each, but my guess is that pmd_leaf() > will tend to miss the pmd_bad() check. IIUC, pmd_leaf() is just for checking a leaf mapped PMD, and will not cover pmd_bad() case. Can see the examples in vmalloc_to_page() and apply_to_pmd_range(). > > But if you can demonstrate a performance improvement from using > pmd_leaf() there, I expect many people would prefer that improvement > to badness catching: send a patch later to make that change if it's > justified. Probably not a lot of performance gain, just makes the check more concise. Thanks, Qi > > Thanks a lot for all your attention to these. > > Hugh > >> >>> + if (unlikely(pmd_bad(pmdval))) { >>> + pmd_clear_bad(pmd); >>> + goto nomap; >>> + } >>> + return __pte_map(&pmdval, addr); >>> +nomap: >>> + /* rcu_read_unlock() to be added later */ >>> + return NULL; >>> +} -- Thanks, Qi