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 X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97E72C433F5 for ; Fri, 3 Sep 2021 20:00:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1D3B960FD7 for ; Fri, 3 Sep 2021 20:00:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1D3B960FD7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 603D56B0071; Fri, 3 Sep 2021 16:00:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58C886B0072; Fri, 3 Sep 2021 16:00:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 45E886B0073; Fri, 3 Sep 2021 16:00:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id 2FF256B0071 for ; Fri, 3 Sep 2021 16:00:38 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A8D0D1854B9F2 for ; Fri, 3 Sep 2021 20:00:37 +0000 (UTC) X-FDA: 78547329714.39.9EB8A69 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf27.hostedemail.com (Postfix) with ESMTP id 4611B70000B8 for ; Fri, 3 Sep 2021 20:00:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630699236; 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: in-reply-to:in-reply-to:references:references; bh=x9PgDg0VuadlLxntBrqQGmujU+0XAeFQSKsJZr0kO/w=; b=KUuRLNkhFPMiIDgDl9Tpcr9sVhKUyzY6KxKp38Oy9ofj9xhVo65r60p1l2bW+K13rHonRk t/OIoxoxeFiN1hm1hgWL3WcbEnxFaYpqwshYbqiwIloJejVhJGmGKcenq2LKuXJodfzuRm 6+yyx2M8+KS1G+1nAobhCw1SIUm2vyw= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-300-dovUTEgtP6KOHBFjffAVsQ-1; Fri, 03 Sep 2021 16:00:35 -0400 X-MC-Unique: dovUTEgtP6KOHBFjffAVsQ-1 Received: by mail-qv1-f70.google.com with SMTP id dv7-20020ad44ee7000000b0036fa79fd337so710972qvb.6 for ; Fri, 03 Sep 2021 13:00:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=x9PgDg0VuadlLxntBrqQGmujU+0XAeFQSKsJZr0kO/w=; b=hRu/Hr3xTZil+pyTL/24FjVsk3Ps2OdiIob9fT5T8H/jvR994a1cftcv9pW3MqMI3E GHz3ubm/Sr7masR/aNkKnIKIDUAg8BfOpSwB7lAnE+RsUfwsveP7vFe+amXsfW1Pzque fpFZMSvxINWNm1euYigOcTYOZuBH3KwHkv3lwTjPQYj071VK92ks9bdKf9HI3XihvjLy oaHrtqzVjVVRvUXnpjZS0AWh3Xy0y/s57mmVrg1+Uo/Fo1zQRnwRfkTd12UR4bzhHCnN jIxQd5m/Ij40jmmEp4T2WRTkh/jf9VV3FaawNS/X7Yd2H0sXW5JVxbl10NfMwK+vBj/K ryXA== X-Gm-Message-State: AOAM533yXQ17LO3S9INXv5lcaCnkyEt1aTdTXehIrFQXVWdkogmN2UBW kv0f1aDWIGRSopgdbDhseN4Ja77eUyxW1PcP9UTGoTu5qAiUtfFR24SimvZaYe/uFhDgQTBx1dN fR/jXlbp/9eo= X-Received: by 2002:ac8:51cd:: with SMTP id d13mr673241qtn.49.1630699235040; Fri, 03 Sep 2021 13:00:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJye/lyjzu//z90V1ZPCWF2igim5y/x1oB909G3x2WTTet8of7sXkSA//xTu7Jgi3hdUtDTKGg== X-Received: by 2002:ac8:51cd:: with SMTP id d13mr673211qtn.49.1630699234768; Fri, 03 Sep 2021 13:00:34 -0700 (PDT) Received: from t490s ([2607:fea8:56a3:500::ad7f]) by smtp.gmail.com with ESMTPSA id a189sm133760qkf.114.2021.09.03.13.00.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Sep 2021 13:00:34 -0700 (PDT) Date: Fri, 3 Sep 2021 16:00:32 -0400 From: Peter Xu To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, Andrew Morton , Hugh Dickins , linux-mm@kvack.org, Andrea Arcangeli , Yang Shi , Matthew Wilcox , Jerome Glisse , Mike Rapoport , "Kirill A . Shutemov" , Miaohe Lin , Alistair Popple , Axel Rasmussen Subject: Re: [PATCH v2 1/5] mm/shmem: Unconditionally set pte dirty in mfill_atomic_install_pte Message-ID: References: <20210902201721.52796-1-peterx@redhat.com> <20210902201721.52796-2-peterx@redhat.com> <2f1bfe82-9bb7-957c-2b32-2ccf8a48e70a@redhat.com> MIME-Version: 1.0 In-Reply-To: <2f1bfe82-9bb7-957c-2b32-2ccf8a48e70a@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=KUuRLNkh; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf27.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 4611B70000B8 X-Stat-Signature: f9zmnppebaytdk5yjdqecuyomrxsgpsy X-HE-Tag: 1630699237-99945 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 Fri, Sep 03, 2021 at 09:42:34AM +0200, David Hildenbrand wrote: > On 02.09.21 22:17, Peter Xu wrote: > > It was conditionally done previously, as there's one shmem special case that we > > use SetPageDirty() instead. However that's not necessary and it should be > > easier and cleaner to do it unconditionally in mfill_atomic_install_pte(). > > > > The most recent discussion about this is here, where Hugh explained the history > > of SetPageDirty() and why it's possible that it's not required at all: > > > > https://lore.kernel.org/lkml/alpine.LSU.2.11.2104121657050.1097@eggly.anvils/ > > > > Currently mfill_atomic_install_pte() has three callers: > > > > 1. shmem_mfill_atomic_pte > > 2. mcopy_atomic_pte > > 3. mcontinue_atomic_pte > > > > After the change: case (1) should have its SetPageDirty replaced by the dirty > > bit on pte (so we unify them together, finally), case (2) should have no > > functional change at all as it has page_in_cache==false, case (3) may add a > > dirty bit to the pte. However since case (3) is UFFDIO_CONTINUE for shmem, > > it's merely 100% sure the page is dirty after all, so should not make a real > > difference either. > > Would it be worth adding VM_BUG_ON() to make sure that "100%" is really the > case? I won't be able to make it 100% sure (and that's where I put it "merely"). The example discussed between Axel and me in the other thread could be an outlier (when two processes, uffd target, and uffd minor resolver, map the region as RO), it's just that neither do I think that's a great matter, nor do I think it would be worth a BUG_ON(), not to mention we use BUG_ON so carefully. > > > > > This should make it much easier to follow on which case will set dirty for > > uffd, as we'll simply set it all now for all uffd related ioctls. Meanwhile, > > no special handling of SetPageDirty() if there's no need. > > To me this all sounds sane, but I'm certainly not an expert on that code, so > ... No problem. I hope this patch didn't bring much headache to a lot of people. It's just that I do think this is the right thing to do so I will insist until someone says no to me. Already appreciate a lot for all the comments and r-bs! -- Peter Xu