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 816B2C54EE9 for ; Fri, 2 Sep 2022 06:39:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C8E7800BE; Fri, 2 Sep 2022 02:39:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1791E8008D; Fri, 2 Sep 2022 02:39:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01918800BE; Fri, 2 Sep 2022 02:39:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E35D58008D for ; Fri, 2 Sep 2022 02:39:12 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BD4ACA10AC for ; Fri, 2 Sep 2022 06:39:12 +0000 (UTC) X-FDA: 79866193344.07.7260104 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 614CFC004B for ; Fri, 2 Sep 2022 06:39:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662100750; 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=smA4UY8sXEdNIEMlZ16VEJW1RuVtIcLIqTxA8bYdNhs=; b=XrzPjnevxDlFGGL/Frg9ohZYUmNoHfRkC92rnIyA8gWEruF+BW2+5CwPs5pkKBoivkixtg AUaE/JxVjOcIR9DG5aNZ7VD1OkcI0dg46EtCy3HJ9wJg3xVMtgqS+wUJ5ok6ZD1LFFKBqB kt4HrpX5HtWaDdDrUf7oofTpCIPec1c= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-529-2mu6nF1dPciU1exZJIqMSw-1; Fri, 02 Sep 2022 02:39:09 -0400 X-MC-Unique: 2mu6nF1dPciU1exZJIqMSw-1 Received: by mail-wm1-f71.google.com with SMTP id v67-20020a1cac46000000b003a615c4893dso723300wme.3 for ; Thu, 01 Sep 2022 23:39:09 -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:subject:date; bh=smA4UY8sXEdNIEMlZ16VEJW1RuVtIcLIqTxA8bYdNhs=; b=YIoBdjKT/t4fZy9NoZRhaIwuEHqbs+cAiP5o49LprubDPDsPmQtCcomzrVvk+RjMg+ QoAbAClF/rFmwCRhuvB9rDNtKP8imsjodi2G4njaX8UZNsuQO28y7t6CO7oG/bgRMLBV x8f4UfSBzwktKmZLL8yse1UbPJ8eKw8k2WcbnK4G1SBlaYTw1zOJFENd91SEuMqC4zxN wBGgzAL6yxEAolLE8eVkpdCvXStlsyo42q5WSUlYgkbhtGUG5lx+ydqa5z+2K25pO47L m6/Q+ndWthcXde1qN/ZVNVznrD9I9a/60UeBKDsdJXVxT9MtjyXIbAN5hDR+un5bXdTl 14Sg== X-Gm-Message-State: ACgBeo1aOb/Uag5SYeG2suDsHyIwHHh0FSCFxGICy7Tu38VcMA/VHARL xPynwlTcbgrOywOvD1nDPd2bkgKWxfBOlStUOUWMbPdY9+m20H4jyB+YJgPeK2zxFa55GdboSml s8Ktol/V1+lk= X-Received: by 2002:a5d:610b:0:b0:226:d241:65e8 with SMTP id v11-20020a5d610b000000b00226d24165e8mr15587288wrt.703.1662100748760; Thu, 01 Sep 2022 23:39:08 -0700 (PDT) X-Google-Smtp-Source: AA6agR4673nHlMv5dt9gE/7vE0SOdJcW2bMT36NxYTzGlempi8dS8+MsdN3h8BPFY6RtS6/7A+bz8A== X-Received: by 2002:a5d:610b:0:b0:226:d241:65e8 with SMTP id v11-20020a5d610b000000b00226d24165e8mr15587271wrt.703.1662100748500; Thu, 01 Sep 2022 23:39:08 -0700 (PDT) Received: from ?IPV6:2003:cb:c714:4800:2077:1bf6:40e7:2833? (p200300cbc714480020771bf640e72833.dip0.t-ipconnect.de. [2003:cb:c714:4800:2077:1bf6:40e7:2833]) by smtp.gmail.com with ESMTPSA id f1-20020a7bcd01000000b003a35516ccc3sm1169265wmj.26.2022.09.01.23.39.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Sep 2022 23:39:08 -0700 (PDT) Message-ID: <1688bcf0-01b2-0f89-68db-d9d66e207bc6@redhat.com> Date: Fri, 2 Sep 2022 08:39:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 To: Yang Shi , Peter Xu Cc: kirill.shutemov@linux.intel.com, jhubbard@nvidia.com, jgg@nvidia.com, hughd@google.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220901222707.477402-1-shy828301@gmail.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm: gup: fix the fast GUP race against THP collapse In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662100751; a=rsa-sha256; cv=none; b=huveU3kKH+SLTZPE6YPI5BXdJMZzyDgoc8GDwTrnk9yANBfki6wbBT6ZH5FIfwh6AXB+XI 1cfeCV566KYWGc1fTegvgN0sMf9wF5hO9YW9HEzzfHKe4xicIBazoqkmu1s3kZH4MJ1Gba DwfV5xs5Ma2596iwPtUFNc8R2tL8yNE= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XrzPjnev; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662100751; 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=smA4UY8sXEdNIEMlZ16VEJW1RuVtIcLIqTxA8bYdNhs=; b=njIlTmnQI9buDvAreymzKwqZhKdnkiOrrWqmSEl249ZAmSig7dBppdF+mPPMHq4sPN53n8 cR84XVIMWZgxurM5vItrUvBks+II6zwbbofxrIBY/mJUuLdqQS0F3eeK/QGtN/shnoYzt4 frAH9wlWcTcQJclMaeqdN3QQOXfQUiY= X-Rspamd-Server: rspam09 Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XrzPjnev; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com X-Rspam-User: X-Stat-Signature: czeadpej656hgozbxw14h3gjibu9es86 X-Rspamd-Queue-Id: 614CFC004B X-HE-Tag: 1662100751-332797 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 02.09.22 01:50, Yang Shi wrote: > On Thu, Sep 1, 2022 at 4:26 PM Peter Xu wrote: >> >> Hi, Yang, >> >> On Thu, Sep 01, 2022 at 03:27:07PM -0700, Yang Shi wrote: >>> Since general RCU GUP fast was introduced in commit 2667f50e8b81 ("mm: >>> introduce a general RCU get_user_pages_fast()"), a TLB flush is no longer >>> sufficient to handle concurrent GUP-fast in all cases, it only handles >>> traditional IPI-based GUP-fast correctly. >> >> If TLB flush (or, IPI broadcasts) used to work to protect against gup-fast, >> I'm kind of confused why it's not sufficient even if with RCU gup? Isn't >> that'll keep working as long as interrupt disabled (which current fast-gup >> will still do)? > > Actually the wording was copied from David's commit log for his > PageAnonExclusive fix. My understanding is the IPI broadcast still > works, but it may not be supported by all architectures and not > preferred anymore. So we should avoid depending on IPI broadcast IIUC. Right. Not all architectures perform an IPI broadcast on TLB flush. IPI broadcasts will continue working until we use RCU instead of disabling local interrupts in GUP-fast. >>> CPU A CPU B >>> THP collapse fast GUP >>> gup_pmd_range() <-- see valid pmd >>> gup_pte_range() <-- work on pte >>> pmdp_collapse_flush() <-- clear pmd and flush >>> __collapse_huge_page_isolate() >>> check page pinned <-- before GUP bump refcount >>> pin the page >>> check PTE <-- no change >>> __collapse_huge_page_copy() >>> copy data to huge page >>> ptep_clear() >>> install huge pmd for the huge page >>> return the stale page >>> discard the stale page >>> >>> The race could be fixed by checking whether PMD is changed or not after >>> taking the page pin in fast GUP, just like what it does for PTE. If the >>> PMD is changed it means there may be parallel THP collapse, so GUP >>> should back off. >> >> Could the race also be fixed by impl pmdp_collapse_flush() correctly for >> the archs that are missing? Do you know which arch(s) is broken with it? > > Yes, and this was suggested by me in the first place, but per the > suggestion from John and David, this is not the preferred way. I think > it is because: > > Firstly, using IPI to serialize against fast GUP is not recommended > anymore since fast GUP does check PTE then back off so we should avoid > it. > Secondly, if checking PMD then backing off could solve the problem, > why do we still need broadcast IPI? It doesn't sound performant. I'd say, using an IPI is the old-styled way of doing things. Sure, using an IPI broadcast will work (and IMHO it's a lot easier to not-get-wrong). But it somewhat contradicts to the new way of doing things. >> >> It's just not clear to me whether this patch is an optimization or a fix, >> if it's a fix whether the IPI broadcast in ppc pmdp_collapse_flush() would >> still be needed. > > It is a fix and the fix will make IPI broadcast not useful anymore. I'd wonder how "easy" adding the IPI broadcast would be -- IOW, if the IPI fix has a real advantage. -- Thanks, David / dhildenb