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 B1BB8C43334 for ; Thu, 21 Jul 2022 11:28:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 378C98E0005; Thu, 21 Jul 2022 07:28:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 328688E0003; Thu, 21 Jul 2022 07:28:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A2438E0005; Thu, 21 Jul 2022 07:28:25 -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 0879D8E0003 for ; Thu, 21 Jul 2022 07:28:25 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 020BB80870 for ; Thu, 21 Jul 2022 07:52:46 +0000 (UTC) X-FDA: 79710340374.25.0FBA88F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 917EB40061 for ; Thu, 21 Jul 2022 07:52:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658389966; 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=ympW0l5TEN2Nsekd5CSeop03YpoeoLoLPeGIZF8GuHQ=; b=Tcx88k3u882c12KgZLBSODAN7PXNy1DEALSM986eMtMG2jNkKvzkveBEhRWXWxSKyhPkoK mFdi8D2I4G4XM/KXKT3JCAity5cyUw7b4X19f5Z8Vlo2sxTGe0W9x+YPc7K4vxAjwNCQES nVR7izzfRxYbzhcWkLgwyiZeuDi+f5o= 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.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-90-_B75ZjmLOTOzXOxqnq5dGw-1; Thu, 21 Jul 2022 03:52:42 -0400 X-MC-Unique: _B75ZjmLOTOzXOxqnq5dGw-1 Received: by mail-wm1-f71.google.com with SMTP id 189-20020a1c02c6000000b003a2d01897e4so638075wmc.9 for ; Thu, 21 Jul 2022 00:52:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=ympW0l5TEN2Nsekd5CSeop03YpoeoLoLPeGIZF8GuHQ=; b=2ZxjB8VVtKW4oh3FvRh0LfNoRg3eOvxKtVr0zm6yJgUyrFCGFOhmcFC72NApY5J8rq ejG/g2o0MI42D2cceoNCmh16BPT5HyDrtm2CJpxFb6FkgjVpUxtFYYYUispFw1X0LlQS T02yozSSgPHBnwAuglG3ehb/l8D11ax1SSB/hIfvb2RXBAVRGmCe2Z2HEvJCn+pApG7K T0N6CDTCCtEbHMH4czwDiBQGeArtfL55FueL3XyxcpcQw9WjzJBLYMJ+hFAdFYWskCss N67bSKH9xcxuA7SrXZvZDt+ulryhduAWlGGeiFsh7NtjlWOfjvyj8QyLq0ghurOkevxt Qo1A== X-Gm-Message-State: AJIora+DTu92FydI9eIq3pm3Xvxv94XBj/ZXmk1HrzayP1/DOHwuSxqm f74FobfWmOF0Ks8bhDZYjrwbo06j3VGjJ1VogkM42tzsgWFLtX3FI+Dq9kQ3TBHdxOuR+4U/0YW KtdI5B7seu+g= X-Received: by 2002:a7b:ce8f:0:b0:3a2:ff2d:915f with SMTP id q15-20020a7bce8f000000b003a2ff2d915fmr7048956wmj.165.1658389961081; Thu, 21 Jul 2022 00:52:41 -0700 (PDT) X-Google-Smtp-Source: AGRyM1ssjBWh3oOChsS/UFwoCcK+5ph/pbNsIaDTBjdeprH77HexNXk/oFpy8K8wyoV+CshlC8T2Fw== X-Received: by 2002:a7b:ce8f:0:b0:3a2:ff2d:915f with SMTP id q15-20020a7bce8f000000b003a2ff2d915fmr7048935wmj.165.1658389960733; Thu, 21 Jul 2022 00:52:40 -0700 (PDT) Received: from ?IPV6:2003:cb:c707:e000:25d3:15fa:4c8b:7e8d? (p200300cbc707e00025d315fa4c8b7e8d.dip0.t-ipconnect.de. [2003:cb:c707:e000:25d3:15fa:4c8b:7e8d]) by smtp.gmail.com with ESMTPSA id a21-20020a05600c349500b003a317ee3036sm1065118wmq.2.2022.07.21.00.52.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Jul 2022 00:52:40 -0700 (PDT) Message-ID: <8e2dcae3-5f50-cd59-7588-b8f566549ad4@redhat.com> Date: Thu, 21 Jul 2022 09:52:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [RFC PATCH 01/14] userfaultfd: set dirty and young on writeprotect To: Nadav Amit Cc: Peter Xu , Linux MM , LKML , Andrew Morton , Mike Rapoport , Axel Rasmussen , Andrea Arcangeli , Andrew Cooper , Andy Lutomirski , Dave Hansen , Peter Zijlstra , Thomas Gleixner , Will Deacon , Yu Zhao , Nick Piggin References: <20220718120212.3180-1-namit@vmware.com> <20220718120212.3180-2-namit@vmware.com> <017facf0-7ef8-3faf-138d-3013a20b37db@redhat.com> <2b4393ce-95c9-dd3e-8495-058a139e771e@redhat.com> <69022bad-d6f1-d830-224d-eb8e5c90d5c7@redhat.com> <4ad140b5-1d5b-2486-0893-7886a9cdfd76@redhat.com> <95320077-52CF-4CB0-92F9-523E1AE74A3D@gmail.com> <468a7114-7541-0d5e-c1fc-083bbb95e78d@redhat.com> From: David Hildenbrand Organization: Red Hat 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: 8bit ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Tcx88k3u; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf07.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658389966; 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=ympW0l5TEN2Nsekd5CSeop03YpoeoLoLPeGIZF8GuHQ=; b=fSnYaI54wy5WElLG8jSz2x+rHIOD+qzJEiroWvpnHkB0FiOgFEB4wW0Cy/Xj2pR50BmSGs 9sz5S5oUYUe+mi2lQU1XA9aLrYc1enYefvO6P7VfEAMpRcxI2KFdUkopZeJ3cPzohxjZkU Uwzo8p4lldeHLZSYW0WcYAQSxGX/A9E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658389966; a=rsa-sha256; cv=none; b=fPE1QRF9Sh6pvlYj1P8a62xoLiLxzX+0o3Fqd5VPWEgOZebVebXtP3dNaeofZIBEk6Jvsb hMznIl/9hvMCRXuJOseQXfg8ZBOg3Zrl1HCLGSbzhaZvVeQVuGD0axQZhZso3UQgrxjtwu VvGqw6LozfyVtrJWzZdDIgtjCms+s/k= X-Rspamd-Queue-Id: 917EB40061 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Tcx88k3u; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf07.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 3k9skta1d3gcbwya4d9xot5dazj4ntny X-HE-Tag: 1658389966-466749 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: >> Yes. Especially for any MAP_PRIVATE mappings. >> >> If you want to write to something that's not mapped writable in a >> MAP_PRIVATE mapping it >> a) Has to be an exclusive anonymous page >> b) The pte has to be dirty > > Do you need both conditions to be true? I thought (a) is sufficient (if > the soft-dirty and related checks succeed). If we force-write to a page, we need it to be dirty to tell reclaim code that the content stale. We can either mark the pte dirty manually, or just let the write fault handler deal with it to simplify GUP code. This needs some more thought, but that's my understanding. > >> >> In any other case, you clearly missed to COW or the modifications might >> get lost if the PTE is not dirty. >> >> MAP_SHARED is a bit more involved. But whether the pte is dirty might be >> good enough ... but this needs a lot more care. >> >>>> But yeah, it's all confusing so I might just be wrong regarding >>>> pagecache pages. >>> >>> Just to note: I am not very courageous and I did not intend to change >>> condition for when non-anonymous pages are set as writable. That’s the >>> reason I did not change the dirty for non-writable non-anonymous entries (as >>> Peter said). And that’s the reason that setting the dirty bit (at least as I >>> should have done it) is only performed after we made the decision on the >>> write-bit. >> >> Good. As long as we stick to anonymous pages I roughly know what we we >> can and cannot do at this point :) >> >> >> The problem I see is that detection whether we can write requires the >> dirty bit ... and whether to set the dirty bit requires the information >> whether we can write. >> >> Again, for anonymous pages we should be able to relax the "dirty" >> requirement when detecting whether we can write. > > That’s all I wanted to do there. > >> >>> IOW, after you made your decision about the write-bit, then and only then >>> you may be able to set the dirty bit for writable entries. Since the entry >>> is already writeable (i.e., can be written without a fault later directly >>> from userspace), there should be no concern of correctness when you set it. >> >> That makes sense to me. What keeps confusing me are architectures with >> and without a hw-managed dirty bit ... :) > > I don’t know which arch you have in your mind. But the moment a PTE is > writable, then marking it logically/architecturally as dirty should be > fine. > > But… if the Exclusive check is not good enough for private+anon without > the “logical” dirty bit, then there would be a problem. I think we are good for anonymous pages. -- Thanks, David / dhildenb