From patchwork Fri Apr 8 20:38:41 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hugh Dickins X-Patchwork-Id: 12807196 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 CF7C2C433EF for ; Fri, 8 Apr 2022 20:38:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 10EC06B0071; Fri, 8 Apr 2022 16:38:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0BE536B0072; Fri, 8 Apr 2022 16:38:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA0F96B0073; Fri, 8 Apr 2022 16:38:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id D85F26B0071 for ; Fri, 8 Apr 2022 16:38:56 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C0B2B8249980 for ; Fri, 8 Apr 2022 20:38:55 +0000 (UTC) X-FDA: 79334875830.30.F808DC7 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by imf02.hostedemail.com (Postfix) with ESMTP id 53C8780009 for ; Fri, 8 Apr 2022 20:38:55 +0000 (UTC) Received: by mail-qk1-f169.google.com with SMTP id t207so4381920qke.2 for ; Fri, 08 Apr 2022 13:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version; bh=9HwDppLqHaQcBs/UBe2aw4cxWmdlTn3unTRBCytLFO0=; b=kDWT7DbLIXeryuqgzJKXPRooe+DFb5VrAV9s8VQQh3/+L/jkAAOBZkzbwMa9Y+oos5 xnxE+TBlfk7ynX1+gqkkuP3JzEVI8mo5QCIzJjw4NrdeaKKiBsjlQPa32LF4zQlR8CMo qxfJz6xxrivp2BwcN71Gyk/3z0QMnL9Gmeu3Da1e3QfE4v/4pQSGcCwMiLyOcku5wgHf CZfBgZObe0vK4UJoPcPOS8TbVZaWAoObLYWjFjYFc3HV77ztvqr9DZRoGtYuTW224KS0 nv+SXeVtLimXZK1E6e75cZMoMhsooPeZNKUKc0CnODdMdlAwq5ZZ3HIupplfob3LOqv4 T//g== 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:mime-version; bh=9HwDppLqHaQcBs/UBe2aw4cxWmdlTn3unTRBCytLFO0=; b=E2tnFXFQZW/L1BbQxHfLTJWS9rFtQNF8P+vkv6paPG8x88RoF5mn6SgqmPns2uRKKo rBx6MW4dfV7NGO7j39M+DZUwDNBj3w4LeMy0vgXUxda5bVZEMsIdrK3AzXyXXHQp4H5y +Jv5oc48M/lVzfdy+R7qM9PYUMKZ38L3dqZfmADKFnN9K269ZW+rgxtMvd8mXtoM/PMq UoQVIKwjeDShrw8aPAzR0uRG3axXxYD1L9eAW9MSTwVaIfliNxh4FallnpV9YdchSB7u 9YCPibgKu6q4/UIQ/4eUwynchX4z7gA1SIFhKedhYqhS5ATyJshZCry6PRQRzHACR09A qmTg== X-Gm-Message-State: AOAM532NikaG4nS8X+QJLa04ybpny3S1ln7jmHM4lyRpWKIll8T79Xag IkWYIdDpAtBr51/kPf6kLp46hA== X-Google-Smtp-Source: ABdhPJxNNfuUtbU+jVA4OD408wRYRnD+uHeEDWk6oAgIVTm4FABTOcVGdZuqmIMJ8LrzmwY67c43ig== X-Received: by 2002:a37:b983:0:b0:67e:c0d2:c3ca with SMTP id j125-20020a37b983000000b0067ec0d2c3camr13883611qkf.749.1649450334495; Fri, 08 Apr 2022 13:38:54 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id k2-20020a37ba02000000b0067dc1b0104asm13964961qkf.124.2022.04.08.13.38.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Apr 2022 13:38:53 -0700 (PDT) Date: Fri, 8 Apr 2022 13:38:41 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Andrew Morton cc: Hugh Dickins , Chuck Lever III , Mark Hemment , Patrice CHOTARD , Mikulas Patocka , Lukas Czerner , Christoph Hellwig , "Darrick J. Wong" , linux-mm@kvack.org, linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com Subject: [PATCH] tmpfs: fix regressions from wider use of ZERO_PAGE Message-ID: <9a978571-8648-e830-5735-1f4748ce2e30@google.com> MIME-Version: 1.0 Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=kDWT7DbL; spf=pass (imf02.hostedemail.com: domain of hughd@google.com designates 209.85.222.169 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 53C8780009 X-Stat-Signature: 4zwt7cwz3zckyfcisdk561qa4ibrzfxm X-HE-Tag: 1649450335-404413 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: Chuck Lever reported fsx-based xfstests generic 075 091 112 127 failing when 5.18-rc1 NFS server exports tmpfs: bisected to recent tmpfs change. Whilst nfsd_splice_action() does contain some questionable handling of repeated pages, and Chuck was able to work around there, history from Mark Hemment makes clear that there might be similar dangers elsewhere: it was not a good idea for me to pass ZERO_PAGE down to unknown actors. Revert shmem_file_read_iter() to using ZERO_PAGE for holes only when iter_is_iovec(); in other cases, use the more natural iov_iter_zero() instead of copy_page_to_iter(). We would use iov_iter_zero() throughout, but the x86 clear_user() is not nearly so well optimized as copy to user (dd of 1T sparse tmpfs file takes 57 seconds rather than 44 seconds). And now pagecache_init() does not need to SetPageUptodate(ZERO_PAGE(0)): which had caused boot failure on arm noMMU STM32F7 and STM32H7 boards Reported-by: Patrice CHOTARD Reported-by: Chuck Lever III Fixes: 56a8c8eb1eaf ("tmpfs: do not allocate pages on read") Signed-off-by: Hugh Dickins Tested-by: Chuck Lever III --- mm/filemap.c | 6 ------ mm/shmem.c | 31 ++++++++++++++++++++----------- 2 files changed, 20 insertions(+), 17 deletions(-) --- 5.18-rc1/mm/filemap.c +++ linux/mm/filemap.c @@ -1063,12 +1063,6 @@ void __init pagecache_init(void) init_waitqueue_head(&folio_wait_table[i]); page_writeback_init(); - - /* - * tmpfs uses the ZERO_PAGE for reading holes: it is up-to-date, - * and splice's page_cache_pipe_buf_confirm() needs to see that. - */ - SetPageUptodate(ZERO_PAGE(0)); } /* --- 5.18-rc1/mm/shmem.c +++ linux/mm/shmem.c @@ -2513,7 +2513,6 @@ static ssize_t shmem_file_read_iter(struct kiocb *iocb, struct iov_iter *to) pgoff_t end_index; unsigned long nr, ret; loff_t i_size = i_size_read(inode); - bool got_page; end_index = i_size >> PAGE_SHIFT; if (index > end_index) @@ -2570,24 +2569,34 @@ static ssize_t shmem_file_read_iter(struct kiocb *iocb, struct iov_iter *to) */ if (!offset) mark_page_accessed(page); - got_page = true; + /* + * Ok, we have the page, and it's up-to-date, so + * now we can copy it to user space... + */ + ret = copy_page_to_iter(page, offset, nr, to); + put_page(page); + + } else if (iter_is_iovec(to)) { + /* + * Copy to user tends to be so well optimized, but + * clear_user() not so much, that it is noticeably + * faster to copy the zero page instead of clearing. + */ + ret = copy_page_to_iter(ZERO_PAGE(0), offset, nr, to); } else { - page = ZERO_PAGE(0); - got_page = false; + /* + * But submitting the same page twice in a row to + * splice() - or others? - can result in confusion: + * so don't attempt that optimization on pipes etc. + */ + ret = iov_iter_zero(nr, to); } - /* - * Ok, we have the page, and it's up-to-date, so - * now we can copy it to user space... - */ - ret = copy_page_to_iter(page, offset, nr, to); retval += ret; offset += ret; index += offset >> PAGE_SHIFT; offset &= ~PAGE_MASK; - if (got_page) - put_page(page); if (!iov_iter_count(to)) break; if (ret < nr) {