Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1708597pxp; Mon, 7 Mar 2022 00:09:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJxu9E/2vP57aQC+dy0YwgbH1mU3j1ZN6HJKu07HgTY/bn92VkWDby0NUrS9wlAdg2NtI5Bv X-Received: by 2002:a17:906:3117:b0:6cd:f81b:e295 with SMTP id 23-20020a170906311700b006cdf81be295mr7804305ejx.511.1646640564004; Mon, 07 Mar 2022 00:09:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646640563; cv=none; d=google.com; s=arc-20160816; b=Jo3AAI0wWuR/SXPzhcsaeidw3fLlr4dH7gT14HeP/vZ/jROJI0cIeY1ZcYVOXMWDVB n9abbijt8MIQGjKAjEXDcVYfc5bHcAvfh+gmWx8vltdfskOAQCFT47lW9N5qdMc3IAsg kbszCF9Ok1pDOMiumrHV5GsJMZS2qguj99WATnFxOSreLRJZJS3ZA7n8B+9VL1oor7so s3rl2MDSLiF7uIRL+rxXJotq+CD6myoOAc/jokeBrkisnoIZ0miR18X6JqeLBAkmpozO 1szWCbH65n7uVpFY8a/4zJcG+8+VsyDaugI+eHyWSKQ/qcqdpG7J3uxVSRDortw/XGdi CDTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=p2tmJ1/oLk3iHkWz87vI/+/w4H7ny9w2xS9wQSSoKks=; b=bxvPm8/p5jscqMNcCeD7lm2/QcEF3mgjUiOv6Gsb4C32G8EyVP5nWQee5bBc6ArNSh bC4mol/sy9BmgJtSOJRuvnibCs4KK4ukwpCbsY+KmMLORXU+GciIQ9kHu9mD4/jpRFhn mi/XDDUVye0ro8VRJPDIjqGBdh7Nyl9XMtjNCn8jAxz7mBjxZeJQGQFkHFqaJaJ5zbno uU023JFqm8JgAOV0H2Pjyc2F2rFTKjLsU7xlBgLm4J00HhYsUBkZ4XL/cpF1gabv4A4t LJLvIc/mQGVlZ0LgiPIobOgAFqwEJThcIFoDvJev6hWk90JBV5mSWU1HWd9B/BlBqVH1 ImbA== ARC-Authentication-Results: i=1; mx.google.com; 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 y17-20020a1709063db100b006ae9c063293si7233297ejh.445.2022.03.07.00.09.02; Mon, 07 Mar 2022 00:09:23 -0800 (PST) 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; 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 S233075AbiCFJ2G (ORCPT + 99 others); Sun, 6 Mar 2022 04:28:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229614AbiCFJ2F (ORCPT ); Sun, 6 Mar 2022 04:28:05 -0500 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A3BE434B5; Sun, 6 Mar 2022 01:27:14 -0800 (PST) Received: by verein.lst.de (Postfix, from userid 2407) id 40D9867373; Sun, 6 Mar 2022 10:27:10 +0100 (CET) Date: Sun, 6 Mar 2022 10:27:09 +0100 From: Christoph Hellwig To: Hugh Dickins Cc: Andrew Morton , Mikulas Patocka , Zdenek Kabelac , Lukas Czerner , "Darrick J. Wong" , Miklos Szeredi , Christoph Hellwig , Borislav Petkov , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH mmotm] tmpfs: do not allocate pages on read Message-ID: <20220306092709.GA22883@lst.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE 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 Fri, Mar 04, 2022 at 09:09:01PM -0800, Hugh Dickins wrote: > It's not quite as simple as just removing the test (as Mikulas did): > xfstests generic/013 hung because splice from tmpfs failed on page not > up-to-date and page mapping unset. That can be fixed just by marking > the ZERO_PAGE as Uptodate, which of course it is; doing so here in > shmem_file_read_iter() is distasteful, but seems to be the best way. Shouldn't we set ZERO_PAGE uptodate during early init code as it, uh, is per definition uptodate all the time? > > My intention, though, was to stop using the ZERO_PAGE here altogether: > surely iov_iter_zero() is better for this case? Sadly not: it relies > on clear_user(), and the x86 clear_user() is slower than its copy_user(): > https://lore.kernel.org/lkml/2f5ca5e4-e250-a41c-11fb-a7f4ebc7e1c9@google.com/ Oh, that's sad as just using clear_user would be the right thing to here. > But while we are still using the ZERO_PAGE, let's stop dirtying its > struct page cacheline with unnecessary get_page() and put_page(). > > Reported-by: Mikulas Patocka > Reported-by: Lukas Czerner > Signed-off-by: Hugh Dickins But except for maybe making sure that ZERO_PAGE is always marked uptodate this does looks good to me.