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 EACA8C00140 for ; Wed, 24 Aug 2022 07:31:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D55C940008; Wed, 24 Aug 2022 03:31:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 683F9940007; Wed, 24 Aug 2022 03:31:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54C29940008; Wed, 24 Aug 2022 03:31:17 -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 468BC940007 for ; Wed, 24 Aug 2022 03:31:17 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 18200A0306 for ; Wed, 24 Aug 2022 07:31:17 +0000 (UTC) X-FDA: 79833665394.08.42F87F7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 9522D180060 for ; Wed, 24 Aug 2022 07:31:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661326276; 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=WT+7R10vk0aNE0rrUknR4gGXjPX6HeX45SVq2JF94dM=; b=Ed1QTD9IzwgxhaGY7IsjIbkfHSS9wHXGN2LwuOh5LOtsh+t4HKhhlPUNt/9HeqaoVNP/rF UmTHJzGUJWLoXmcggBeHxhJqTpifF8Bp+d8O+JV77bYRDf/Hxm+PFGiW/g3dq4xqzWkgDL K0uk0S+x/8G84rmS9nkxFMyrFtryjPE= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-593-j17N4FbmMZq2dMtuzPT6CA-1; Wed, 24 Aug 2022 03:31:15 -0400 X-MC-Unique: j17N4FbmMZq2dMtuzPT6CA-1 Received: by mail-wm1-f72.google.com with SMTP id a17-20020a05600c349100b003a545125f6eso444858wmq.4 for ; Wed, 24 Aug 2022 00:31:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=WT+7R10vk0aNE0rrUknR4gGXjPX6HeX45SVq2JF94dM=; b=3Zz/EcA/Yj9AKC+wZFk63Z18bEeLTfnzAqDLV0dpolBWhQjiVoGVskStgm3zk4ETAu NJ1Jl5SM/ZELr4BjHTdCMD5Ieyo223p+QMRRsce0QtQ8/Vow6ro92oRJsbS2rQuutXQi 4HSMnNBKwENbvfBxgwrryxCk3467ugEGhPF+9ZLX4z+s11TNkMhv1TtLJ5XMYF1cPMgI j/KpgKRlvMmyRLN9GeM3KWC8Wf6jr5Mj8QeodWVDKDHnjGa6CIf3OeDIWx8MOGodC85B WTpHpM4hbZMgfiWf4kCTmRSxcNDl3kxLseEVcwHQwcDrh2ApDI5B3veISirnbOwIR2D1 nPJg== X-Gm-Message-State: ACgBeo3I/NmZ7V4PCJLd5Pd1fcEIdqhTSxO66EzWzJAUOLsDfLQWxej+ 1Efxjv2Jtpi+58qQjSnlwLY233Fpz9E3o4VePPUTUKgvoNiYk33a437HiiSuyVb2yOH9ocC3Bay 3EfIlPoyj2kc= X-Received: by 2002:a05:6000:1541:b0:222:cf65:18d7 with SMTP id 1-20020a056000154100b00222cf6518d7mr14983037wry.659.1661326273825; Wed, 24 Aug 2022 00:31:13 -0700 (PDT) X-Google-Smtp-Source: AA6agR7OD3lnFqJrfNvSSIMKPzccca+q0/+SvVbupvakHoiMYt8Uz2ObMdjTZycv71GlM/2xZ23TxA== X-Received: by 2002:a05:6000:1541:b0:222:cf65:18d7 with SMTP id 1-20020a056000154100b00222cf6518d7mr14983020wry.659.1661326273536; Wed, 24 Aug 2022 00:31:13 -0700 (PDT) Received: from ?IPV6:2003:cb:c707:c500:5445:cf40:2e32:6e73? (p200300cbc707c5005445cf402e326e73.dip0.t-ipconnect.de. [2003:cb:c707:c500:5445:cf40:2e32:6e73]) by smtp.gmail.com with ESMTPSA id j27-20020a05600c1c1b00b003a5ce167a68sm1062881wms.7.2022.08.24.00.31.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Aug 2022 00:31:13 -0700 (PDT) Message-ID: <7ee73879-e402-9175-eae8-41471d80d59e@redhat.com> Date: Wed, 24 Aug 2022 09:31:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 To: Baolin Wang , Mike Kravetz Cc: akpm@linux-foundation.org, songmuchun@bytedance.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <0e5d92da043d147a867f634b17acbcc97a7f0e64.1661240170.git.baolin.wang@linux.alibaba.com> <4c24b891-04ce-2608-79d2-a75dc236533f@redhat.com> <376d2e0a-d28a-984b-903c-1f6451b04a15@linux.alibaba.com> <7d4e7f47-30a5-3cc6-dc9f-aa89120847d8@redhat.com> <64669c0a-4a6e-f034-a15b-c4a8deea9e5d@linux.alibaba.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2 1/5] mm/hugetlb: fix races when looking up a CONT-PTE size hugetlb page In-Reply-To: <64669c0a-4a6e-f034-a15b-c4a8deea9e5d@linux.alibaba.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661326276; 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=WT+7R10vk0aNE0rrUknR4gGXjPX6HeX45SVq2JF94dM=; b=Pl4vI36qs/B5wRMqpxNPWHHlahnBas14DHObQCrfX2T9p5YQHh0fxyjxct1kh5/Z/6OzIx cP1Kr9Y0UDjTqC4Quz6IGKitA4b9D5C1rnbV+XG/yvmhk+P0xsqlaDj1DKH8I06Jbi4Ex7 JPfZt3txbb6QZ/289Zn6Z26tECYx4ZA= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ed1QTD9I; spf=pass (imf24.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661326276; a=rsa-sha256; cv=none; b=cu2GNU5gGXhrAwL9j0f3jRqV6QVHVHXYwSO25U4PFpAo94UQyiR4ijn6br6AbWo0k8fuYM l7fNtgP0/LmKbHjofCjMnItbEczw9y8w1Ynuec3A+lG2ldVLp/6Dw9cAzpHNoz/m5H5B0e ErZPOPZk7Q7nHOq++cZmrbo+tJn32AM= X-Rspam-User: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ed1QTD9I; spf=pass (imf24.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9522D180060 X-Stat-Signature: nwufntddw1dqgbaq3g551dqu5wp3hb5t X-HE-Tag: 1661326276-854724 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: >>>> >>>> IMHO, these follow_huge_xxx() functions are arch-specified at first and >>>> were moved into the common hugetlb.c by commit 9e5fc74c3025 ("mm: >>>> hugetlb: Copy general hugetlb code from x86 to mm"), and now there are >>>> still some arch-specified follow_huge_xxx() definition, for example: >>>> ia64: follow_huge_addr >>>> powerpc: follow_huge_pd >>>> s390: follow_huge_pud >>>> >>>> What I mean is that follow_hugetlb_page() is a common and >>>> not-arch-specified function, is it suitable to change it to be >>>> arch-specified? >>>> And thinking more, can we rename follow_hugetlb_page() as >>>> hugetlb_page_faultin() and simplify it to only handle the page faults of >>>> hugetlb like the faultin_page() for normal page? That means we can make >>>> sure only follow_page_mask() can handle hugetlb. >>>> >> >> Something like that might work, but you still have two page table walkers >> for hugetlb. I like David's idea (if I understand it correctly) of > > What I mean is we may change the hugetlb handling like normal page: > 1) use follow_page_mask() to look up a hugetlb firstly. > 2) if can not get the hugetlb, then try to page fault by > hugetlb_page_faultin(). > 3) if page fault successed, then retry to find hugetlb by > follow_page_mask(). That implies putting more hugetlbfs special code into generic GUP, turning it even more complicated. But of course, it depends on how the end result looks like. My gut feeling was that hugetlb is better handled in follow_hugetlb_page() separately (just like we do with a lot of other page table walkers). > > Just a rough thought, and I need more investigation for my idea and > David's idea. > >> using follow_hugetlb_page for both cases. As noted, it will need to be >> taught how to not trigger faults in the follow_page_mask case. > > Anyway, I also agree we need some cleanup, and firstly I think we should > cleanup these arch-specified follow_huge_xxx() on some architectures > which are similar with the common ones. I will look into these. There was a recent discussion on that, e.g.: https://lkml.kernel.org/r/20220818135717.609eef8a@thinkpad > > However, considering cleanup may need more investigation and > refactoring, now I prefer to make these bug-fix patches of this patchset > into mainline firstly, which are suitable to backport to old version to > fix potential race issues. Mike and David, how do you think? Could you > help to review these patches? Thanks. Patch #1 certainly add more special code just to handle another hugetlb corner case (CONT pages), and maybe just making it all use follow_hugetlb_page() would be even cleaner and less error prone. I agree that locking is shaky, but I'm not sure if we really want to backport this to stable trees: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html "It must fix a real bug that bothers people (not a, “This could be a problem...” type thing)." Do we actually have any instance of this being a real (and not a theoretical) problem? If not, I'd rather clean it all up right away. -- Thanks, David / dhildenb