Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp3429519rwl; Mon, 27 Mar 2023 14:03:05 -0700 (PDT) X-Google-Smtp-Source: AK7set8+s5sKdK8bM5OHd9Vfqp/d0vLGmr7RbActEEG79EyxzKCOLtK6C74gmr5oco5mlO0y0CfB X-Received: by 2002:a05:6a20:4b12:b0:db:d9b6:7fba with SMTP id fp18-20020a056a204b1200b000dbd9b67fbamr11226192pzb.47.1679950985315; Mon, 27 Mar 2023 14:03:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679950985; cv=none; d=google.com; s=arc-20160816; b=pJItduKrt2CtE32Qs2jgxR5ZJ1AydoFR8CqOwvChFiL7HmYmL3YPO2Mi3UvdVwVq+e DdQkafy2ZZ1rDmdsS6wOl0BJku7HrWLDcvKFGTkdEJfRN31bCLMSTlHOwIg1DwscDe3v 4ZsOrhzRYUBgIggRPQ+GEzj/h0iiVRiDFVhN/7DBjPNdUUB0dgpyYNiVm5ez2w0KKw/w rBYUvTUW6NXg4nBO9dXDUo7rVGmMBF7p2/i4CmtxPbqomLxqTdTx0mcgE1fu9VB1bX6o kCoUa3Z3YXo0v3kFCmJb9oo4MAfzdxwcoT264cxx0SQbtPXIW+ODiErBIFLycLzFSe5I cAKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :organization:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:dkim-signature; bh=l0k5HQijZZiTI5JKuN0wulOwFUsOATJ37PiPOJOEgWU=; b=kQGsJ3nLX661+ym8a0zeto9nZTWa4PqI8u/p34w9OVR9GdSwMoS8sEIsyswhaACwMQ gTq8BPzlx8oyQLEWon6yPnx2VcOjyDluELQwRjEYATrATfiKLNmtKe0ER7n7y+8q5BC1 Vt7DsARaTomwIchJoSMRoFVX5KftXkCY5ykpAiPnHXefU0Dc2pj8aQ8QKIBjVQtJ0NJP AQpLbbjYSKSCb211scRLgf/jQEqFbRmo/t9dZ40V57MkECcQQp0RnMVLeiPeDzl1bL9B ruurNbYv7ei2RMbSKoutFg7ZUseWHJiBN3xaMe7Lq+hgEL9CxFPol3C//mEMhgRThGGW NLCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Lngh6tTt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y193-20020a638aca000000b0050be067284bsi16670682pgd.556.2023.03.27.14.02.53; Mon, 27 Mar 2023 14:03:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Lngh6tTt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229718AbjC0U6f (ORCPT + 99 others); Mon, 27 Mar 2023 16:58:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46464 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbjC0U6e (ORCPT ); Mon, 27 Mar 2023 16:58:34 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6AD0212F for ; Mon, 27 Mar 2023 13:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679950670; 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=l0k5HQijZZiTI5JKuN0wulOwFUsOATJ37PiPOJOEgWU=; b=Lngh6tTtFRmSqToWVxm0YpFycEpyiFbDGs05CpmWRYVO5LFIRZNQuhR6jqArfb7ysXn9i8 uwW2aLvzlXlKpHHfuHdpfcTBlxq2xSgPvrYBP5lRQNdp9Yq8qg869vVe88GoqhC3RsUCe6 +ITmx9XEHpWqz9Vy53mSDrUTF0c5BI4= Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-56-zQp8aW2xNO-9cZwde1CGGA-1; Mon, 27 Mar 2023 16:57:48 -0400 X-MC-Unique: zQp8aW2xNO-9cZwde1CGGA-1 Received: by mail-pg1-f197.google.com with SMTP id d34-20020a630e22000000b005039e28b68cso2517744pgl.13 for ; Mon, 27 Mar 2023 13:57:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679950668; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=l0k5HQijZZiTI5JKuN0wulOwFUsOATJ37PiPOJOEgWU=; b=CotDZslgNpIe8MuU/z32HWmY1PdMlVHf+hpacYwTlzmZhqIfd3LdtbBmXceyNDPguH I2qF87t9NMg0RQERYzMbiyz/AkciebKZJzT9Aic7b3NzDIh1V/tZtl53jwTxWSadDXgj bjMX2vAF/r1kD+NH3wYVqnuh0Hl5lwImKHDPF24ZB0SiHxtvP7ldN3jtpmHZKjhOmzi8 xDKOLiH4TMpfJNHfEvbWsaZaWEVW2/OV1GaxcYpBZrRoBJWhJsE3+G7dFLjQDbq0HNz/ pJmHYFwHVJ09shuZ7u794Xs8nyLoFNyYxLDtSaV+b+dHdNfJ5gnNbOQkgfPy/q9NFmG/ XSUQ== X-Gm-Message-State: AO0yUKUjPZQ+fADowTKWRpC/3WyyaTB9txECHZFSkuKT5PmMqFXoSmFn phNpEasV1CK+/VZbKa0HA1sor+AHr4/cg6XzHokH2j+deRI3ODvVO0Hr9FoaDhac73KA824iQQ+ elcdAgAzQHdOSr1qT5SJHwYrW X-Received: by 2002:a17:90b:2243:b0:23f:7176:df32 with SMTP id hk3-20020a17090b224300b0023f7176df32mr13751413pjb.40.1679950667911; Mon, 27 Mar 2023 13:57:47 -0700 (PDT) X-Received: by 2002:a17:90b:2243:b0:23f:7176:df32 with SMTP id hk3-20020a17090b224300b0023f7176df32mr13751400pjb.40.1679950667631; Mon, 27 Mar 2023 13:57:47 -0700 (PDT) Received: from [172.16.65.120] ([64.114.255.114]) by smtp.gmail.com with ESMTPSA id j8-20020a17090a060800b0023d01900d7bsm7675288pjj.0.2023.03.27.13.57.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Mar 2023 13:57:47 -0700 (PDT) Message-ID: Date: Mon, 27 Mar 2023 22:57:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v3] mm/hugetlb: Fix uffd wr-protection for CoW optimization path Content-Language: en-US To: Mike Kravetz , Peter Xu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Mike Rapoport , Nadav Amit , Axel Rasmussen , Andrea Arcangeli , Muhammad Usama Anjum , linux-stable References: <20230324142620.2344140-1-peterx@redhat.com> <20230324222707.GA3046@monkey> <8a06be33-1b44-b992-f80a-8764810ebf3f@redhat.com> <20230327183438.GC4184@monkey> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20230327183438.GC4184@monkey> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27.03.23 20:34, Mike Kravetz wrote: > On 03/26/23 10:46, Peter Xu wrote: >> On Fri, Mar 24, 2023 at 11:36:53PM +0100, David Hildenbrand wrote: >>>>> @@ -5487,6 +5487,17 @@ static vm_fault_t hugetlb_wp(struct mm_struct *mm, struct vm_area_struct *vma, >>>>> unsigned long haddr = address & huge_page_mask(h); >>>>> struct mmu_notifier_range range; >>>>> + /* >>>>> + * Never handle CoW for uffd-wp protected pages. It should be only >>>>> + * handled when the uffd-wp protection is removed. >>>>> + * >>>>> + * Note that only the CoW optimization path (in hugetlb_no_page()) >>>>> + * can trigger this, because hugetlb_fault() will always resolve >>>>> + * uffd-wp bit first. >>>>> + */ >>>>> + if (!unshare && huge_pte_uffd_wp(pte)) >>>>> + return 0; >>>> >>>> This looks correct. However, since the previous version looked correct I must >>>> ask. Can we have unshare set and huge_pte_uffd_wp true? If so, then it seems >>>> we would need to possibly propogate that uffd_wp to the new pte as in v2 >> >> Good point, thanks for spotting! >> >>> >>> We can. A reproducer would share an anon hugetlb page because parent and >>> child. In the parent, we would uffd-wp that page. We could trigger unsharing >>> by R/O-pinning that page. >> >> Right. This seems to be a separate bug.. It should be triggered in >> totally different context and much harder due to rare use of RO pins, >> meanwhile used with userfault-wp. >> >> If both of you agree, I can prepare a separate patch for this bug, and I'll >> better prepare a reproducer/selftest with it. >> > > I am OK with separate patches, and agree that the R/O pinning case is less > likely to happen. Yes, the combination should be rather rare and we can fix that separately. Ideally, we'd try to mimic the same uffd code flow in hugetlb cow/unshare handling that we use in memory.c > > Since this patch addresses the issue found by Muhammad, > > Reviewed-by: Mike Kravetz Hopefully we didn't forget about yet another case :D Acked-by: David Hildenbrand -- Thanks, David / dhildenb