Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp864827imi; Thu, 21 Jul 2022 12:30:33 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uLMgv7zwwEISEbhUqdwJD7gecMEhn7ccLnQakb+6iLC8tf4RnFdH8GZveR0n2EIkjwKuQ4 X-Received: by 2002:a05:6a00:1908:b0:525:5dad:cb1c with SMTP id y8-20020a056a00190800b005255dadcb1cmr45620781pfi.47.1658431833492; Thu, 21 Jul 2022 12:30:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658431833; cv=none; d=google.com; s=arc-20160816; b=x/ngL5J0lsVWBSirROtsQNxm7SCVLTFaGOg8UtsREh9q6BVTqMUYqqVDSKxhznggKY L1eqoy6GlXTop70zlwEkCH1OYvoQhPHqiPNPyy/Ch19KBbb4nqL/xhHjR8BQheLVv2aI SS8Xr7JKUzVuKCjKdcCbRx649qtPvagBs/EH+Je73iXsQa5BzPtXYLxUJMa4li/Bzbip V3ZRs4OTwHi7lrRaSMB2j0Yf0B4ujpom5rDAfr+6ieMxTng/yfV7k0Gfmql9x6i0T34s 4/C8sqcBVokZQC60z02k8d+4SKtPDf72z8RlMy6OepixIq78TvNuz6/Vw3hXWOLhR7KG zUVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ABlARo1q4W8MWl8fMSyyIWAkJhcwdZqRLERUMRVV8y0=; b=K2B0m7ev1r+2uLYJMZ6UPb29qgSpr3RZKQE3sUkvFsLYIl8pUAZ/7O+KXQq7V5akpk ZWQsTLpLdTQfnShOHH7d4eWoMGKZ2UDfgSesR4aRKVHAszhaVFzIe2PsYsfXWQhP56UW PvueSarL8eng0ri9/5yt+qzTIeSUuiTan/CMh65PohK3zPVFtrUR5cvYXbMQNid1UeFJ dNB2OqQRhCGchc1/ShthSDS8x/uLcas+TjpXwtHt2HAP7M9k/HhrA+jRELcHbYnJlA9V bzRcSjGFh8jh6KA2hzAJ5z3fi8UdrbzaMe8SnGQ+E9i8pJSrPrvJN/zNeph2XTYh8COW emQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=a3Dipqi7; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x83-20020a633156000000b003fc5a89b010si3059771pgx.103.2022.07.21.12.30.15; Thu, 21 Jul 2022 12:30:33 -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=@ziepe.ca header.s=google header.b=a3Dipqi7; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230060AbiGUSvV (ORCPT + 99 others); Thu, 21 Jul 2022 14:51:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229761AbiGUSvU (ORCPT ); Thu, 21 Jul 2022 14:51:20 -0400 Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B275340BDE for ; Thu, 21 Jul 2022 11:51:18 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id r21so1944267qtn.11 for ; Thu, 21 Jul 2022 11:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ABlARo1q4W8MWl8fMSyyIWAkJhcwdZqRLERUMRVV8y0=; b=a3Dipqi7DP4aUkldrHp93ne1O6cTrWtFJpNvlTOIVlXo01XvWSk4dz1tX3rtPQH3F2 jAZAdCSavV3Sqgbsz0881u6GS2ltM95tIgUSEsp0f4tJQdjSNgtsu7Jm0vYtk0N2CT3v Aif0YgWwWfuK44GRHXwEJRP03Ftyu1B4VkWa6AXBbpGhQcxyIz58MrwLQXzV7/YOGDWD JA9n9g/1CRGRGhplF8rk7GYAdQ3ph3PTTW9VPSa4A+IG/q+1eI6r6yd63bvqVxvRoThu CFd4/soAUrj26JEa+N7OTRsMBMcMiPKeKZJ6e4cI5qyemzqeYxtA9kaepAZ6wNVIN7X3 sMPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ABlARo1q4W8MWl8fMSyyIWAkJhcwdZqRLERUMRVV8y0=; b=1kHuMPg/AsUr72pZqr7wtokN5gtyZRJRDzwpIHUON7qeaA1STadXrJrGSco9JfUggU /SqGgCgWKFrSYeBoR6E/ajl19Y43AAvMznyaapzQt3g96iwS6ac1Rxh+tTAxkKhU0KGi ojUgahJMsjT6SROWuxfsBA7u8dSnvtwJZPWoIIT2pgA4UGARLlCCj2i09NBku0m50RXY KDBUaLhtOj+tqY2CrvgPfBdAd9W4S3nVThb+Lh3JZMoN7FIbjk8sRVnO4KVdldWe2jAo 4zup7PLS2gwY9g72e9m3WbLzw8TMYyw1OiT5ql5JcdCBS3Qf5N/HEgp8JKpN0WXmc/v9 Aj4g== X-Gm-Message-State: AJIora/ApA+J3g85OZLnTa6z/fXQxHl9VmL4QmUBYg4QLN/6IkQT8LlU KS1Wt9pFYke7/ZOIGWcKMAHuHw== X-Received: by 2002:ac8:5a12:0:b0:31e:f233:50f1 with SMTP id n18-20020ac85a12000000b0031ef23350f1mr15963077qta.229.1658429477857; Thu, 21 Jul 2022 11:51:17 -0700 (PDT) Received: from ziepe.ca ([142.177.133.130]) by smtp.gmail.com with ESMTPSA id q5-20020a05620a038500b006b5e833d996sm1745532qkm.22.2022.07.21.11.51.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jul 2022 11:51:17 -0700 (PDT) Received: from jgg by jggl with local (Exim 4.94) (envelope-from ) id 1oEbGW-00022g-2R; Thu, 21 Jul 2022 15:51:16 -0300 Date: Thu, 21 Jul 2022 15:51:16 -0300 From: Jason Gunthorpe To: Dan Williams Cc: Muchun Song , Matthew Wilcox , akpm@linux-foundation.org, jhubbard@nvidia.com, william.kucharski@oracle.com, jack@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, ruansy.fnst@fujitsu.com, hch@infradead.org Subject: Re: [PATCH] mm: fix missing wake-up event for FSDAX pages Message-ID: <20220721185116.GC6833@ziepe.ca> References: <20220704074054.32310-1-songmuchun@bytedance.com> <62ccded5298d8_293ff129437@dwillia2-xfh.notmuch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62ccded5298d8_293ff129437@dwillia2-xfh.notmuch> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 Mon, Jul 11, 2022 at 07:39:17PM -0700, Dan Williams wrote: > Muchun Song wrote: > > On Mon, Jul 04, 2022 at 11:38:16AM +0100, Matthew Wilcox wrote: > > > On Mon, Jul 04, 2022 at 03:40:54PM +0800, Muchun Song wrote: > > > > FSDAX page refcounts are 1-based, rather than 0-based: if refcount is > > > > 1, then the page is freed. The FSDAX pages can be pinned through GUP, > > > > then they will be unpinned via unpin_user_page() using a folio variant > > > > to put the page, however, folio variants did not consider this special > > > > case, the result will be to miss a wakeup event (like the user of > > > > __fuse_dax_break_layouts()). > > > > > > Argh, no. The 1-based refcounts are a blight on the entire kernel. > > > They need to go away, not be pushed into folios as well. I think > > > > I would be happy if this could go away. > > Continue to agree that this blight needs to end. > > One of the pre-requisites to getting back to normal accounting of FSDAX > page pin counts was to first drop the usage of get_dev_pagemap() in the > GUP path: > > https://lore.kernel.org/linux-mm/161604048257.1463742.1374527716381197629.stgit@dwillia2-desk3.amr.corp.intel.com/ > > That work stalled on notifying mappers of surprise removal events of FSDAX pfns. We already talked about this - once we have proper refcounting the above is protected naturally by the proper refcounting. The reason it is there is only because the refcount goes to 1 and the page is re-used so the natural protection in GUP doesn't work. We don't need surprise removal events to fix this, we need the FS side to hold a reference when it puts the pages into the PTEs.. > So, once I dig out from a bit of CXL backlog and review that effort the > next step that I see will be convert the FSDAX path to take typical > references vmf_insert() time. Unless I am missing a shorter path to get > this fixed up? Yeah, just do this. IIRC Christoph already did all the infrastructure now, just take the correct references and remove the special cases that turn off the new infrastructure for fsdax. When I looked at it a long while ago it seemd to require some understanding of the fsdax code and exactly what the lifecycle model was supposed to be there. Jason