From patchwork Mon Nov 28 15:56:31 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Foster X-Patchwork-Id: 13057733 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 2E909C433FE for ; Mon, 28 Nov 2022 15:56:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8FE6E6B0073; Mon, 28 Nov 2022 10:56:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8AD8D6B0074; Mon, 28 Nov 2022 10:56:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74DB56B0075; Mon, 28 Nov 2022 10:56:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 665C06B0073 for ; Mon, 28 Nov 2022 10:56:34 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1E6B4140700 for ; Mon, 28 Nov 2022 15:56:34 +0000 (UTC) X-FDA: 80183303508.30.B8A03D7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf20.hostedemail.com (Postfix) with ESMTP id 877961C0013 for ; Mon, 28 Nov 2022 15:56:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669650992; 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=viQTtiGPGO0sxjcDE8HtSyWXkdZEJfdwrChXGMd/PSE=; b=Z6VW9JD9zfc8DSm+0G83s4kRX+9O+uovfIP3dFYFtxpFcccQk5QYhEm4+mwRVJbI9kfezM 0J/143fP82d0SijW9R1IXZzX1yLNIj3lUrtgg/Yxn5XrhY75arRfaFRp7SmmjoajnZr9KU D9TqonFSXbliQui2xm20+OdSQpHz4bw= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-329-g0hfeyJFP9-GjRz6g7jNIQ-1; Mon, 28 Nov 2022 10:56:27 -0500 X-MC-Unique: g0hfeyJFP9-GjRz6g7jNIQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 62F0D887404; Mon, 28 Nov 2022 15:56:27 +0000 (UTC) Received: from bfoster.redhat.com (unknown [10.22.8.52]) by smtp.corp.redhat.com (Postfix) with ESMTP id 39738112132C; Mon, 28 Nov 2022 15:56:27 +0000 (UTC) From: Brian Foster To: linux-mm@kvack.org Cc: Andrew Morton , Christoph Hellwig Subject: [PATCH v2 1/2] filemap: skip write and wait if end offset precedes start Date: Mon, 28 Nov 2022 10:56:31 -0500 Message-Id: <20221128155632.3950447-2-bfoster@redhat.com> In-Reply-To: <20221128155632.3950447-1-bfoster@redhat.com> References: <20221128155632.3950447-1-bfoster@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669650993; 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=viQTtiGPGO0sxjcDE8HtSyWXkdZEJfdwrChXGMd/PSE=; b=TF+5QbK90SCxBuO0ORx1RMpb70Q2wfa2oyCTDM7kYez6FJimfm5neQo5ld5CS1jtq9OJGO pKAckuox13cvnJpUs55HBas5WbxJDke2NXBTDgb6JWUjxvp8MMG7+89GrF95U0IPAd/u4H L8JNxuQEnMxcVwrIlGhhpYTcCGdoCtw= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Z6VW9JD9; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf20.hostedemail.com: domain of bfoster@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669650993; a=rsa-sha256; cv=none; b=XF4XCCEwtD0KO3pYEE+ukwSWGaGOiqFN/rFf+ZWfHwQzn7gL4niUSYPxSXpdqMLDvD+XL9 JK3knkJJoDMbXMvDa4e/8XIcetvPUqqOlxdbVmH3v9XHGIJEP1FIQNIXkdK63dzVP0JKq2 vpq5C3bKEZIaXEYk7d0PLhX1xTVJNuk= X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Z6VW9JD9; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf20.hostedemail.com: domain of bfoster@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com X-Stat-Signature: n96i5ndpjh6wmih8n9wddp6ki97mnmdt X-Rspamd-Queue-Id: 877961C0013 X-Rspamd-Server: rspam08 X-HE-Tag: 1669650993-115998 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: A call to file[map]_write_and_wait_range() with an end offset that precedes the start offset but happens to land in the same page can trigger writeback submission but fails to wait on the submitted page. Writeback submission occurs because __filemap_fdatawrite_range() passes both offsets down into write_cache_pages(), which rounds down to page indexes before it starts processing writeback. However, __filemap_fdatawait_range() immediately returns if the byte-granular end offset precedes the start offset. This behavior was observed in the form of unpredictable latency from a frequent write and wait call with incorrect parameters. The behavior gave the impression that the fdatawait path might occasionally fail to wait on writeback, but further investigation showed the latency was from write_cache_pages() waiting on writeback state to clear for a page already under writeback. Therefore, this indicated that fdatawait actually never waits on writeback in this particular situation. The byte granular check in __filemap_fdatawait_range() goes all the way back to the old wait_on_page_writeback() helper. It originally used page offsets and so would have waited in this problematic case. That changed to byte granularity file offsets in commit 94004ed726f3 ("kill wait_on_page_writeback_range"), which subtly changed this behavior. The check itself has become somewhat redundant since the error checking code that used to follow the wait loop (at the time of the aforementioned commit) has now been removed and lifted into the higher level callers. Therefore, we can restore historical fdatawait behavior by simply removing the check. Since the current fdatawait behavior has been in place for quite some time and is consistent with other interfaces that use file offsets, instead lift the check into the file[map]_write_and_wait_range() helpers to provide consistent behavior between the write and wait. Signed-off-by: Brian Foster Reviewed-by: Christoph Hellwig --- mm/filemap.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/mm/filemap.c b/mm/filemap.c index 08341616ae7a..e7711b5a3f4c 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -506,9 +506,6 @@ static void __filemap_fdatawait_range(struct address_space *mapping, struct pagevec pvec; int nr_pages; - if (end_byte < start_byte) - return; - pagevec_init(&pvec); while (index <= end) { unsigned i; @@ -670,6 +667,9 @@ int filemap_write_and_wait_range(struct address_space *mapping, { int err = 0, err2; + if (lend < lstart) + return 0; + if (mapping_needs_writeback(mapping)) { err = __filemap_fdatawrite_range(mapping, lstart, lend, WB_SYNC_ALL); @@ -770,6 +770,9 @@ int file_write_and_wait_range(struct file *file, loff_t lstart, loff_t lend) int err = 0, err2; struct address_space *mapping = file->f_mapping; + if (lend < lstart) + return 0; + if (mapping_needs_writeback(mapping)) { err = __filemap_fdatawrite_range(mapping, lstart, lend, WB_SYNC_ALL); From patchwork Mon Nov 28 15:56:32 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Foster X-Patchwork-Id: 13057732 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 3BAEDC433FE for ; Mon, 28 Nov 2022 15:56:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5EEC06B0072; Mon, 28 Nov 2022 10:56:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 59F636B0073; Mon, 28 Nov 2022 10:56:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48E5D6B0074; Mon, 28 Nov 2022 10:56:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3C8C36B0072 for ; Mon, 28 Nov 2022 10:56:31 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id F0B3A80889 for ; Mon, 28 Nov 2022 15:56:30 +0000 (UTC) X-FDA: 80183303340.29.07797D2 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf21.hostedemail.com (Postfix) with ESMTP id 07CAF1C000C for ; Mon, 28 Nov 2022 15:56:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669650989; 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=piyPDS1x1HNQHDQuqW9bM/s+6rGUXAkfrSmFDYgGfew=; b=eRzzj5FaBao/8BkY4MU3HCTmJg/6JtjuvTnhp0T8zFLuggx0FiLuIYYkuilV5MOn7ln8Sj UC2gbbmQhiY8vfKqGzTENpj+IbJUv4aCu5JuVCqFqp5CGakU0IMjtlBjoyDaCNay7YSaxh M73Byhe8BQYXbWAs60Fqx348CdeOFRY= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-307-w7Nn7LgQNQ6kH3HIDCCTkQ-1; Mon, 28 Nov 2022 10:56:28 -0500 X-MC-Unique: w7Nn7LgQNQ6kH3HIDCCTkQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 970C829ABA11; Mon, 28 Nov 2022 15:56:27 +0000 (UTC) Received: from bfoster.redhat.com (unknown [10.22.8.52]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6FE27112132C; Mon, 28 Nov 2022 15:56:27 +0000 (UTC) From: Brian Foster To: linux-mm@kvack.org Cc: Andrew Morton , Christoph Hellwig Subject: [PATCH v2 2/2] mm/fadvise: use LLONG_MAX instead of -1 for eof Date: Mon, 28 Nov 2022 10:56:32 -0500 Message-Id: <20221128155632.3950447-3-bfoster@redhat.com> In-Reply-To: <20221128155632.3950447-1-bfoster@redhat.com> References: <20221128155632.3950447-1-bfoster@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=eRzzj5Fa; spf=pass (imf21.hostedemail.com: domain of bfoster@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669650990; a=rsa-sha256; cv=none; b=FrFXpFTQyVz64KX8w8pwdnH76O50BOmqZbo5Un7S64w2pWWAzOPGB8HTSltHdkrZE7w52y HMWhzDNS3egvKoPWfeLLVwfN+XjiT/tDPxSOD2c1rzSKuTDFLC6CeFC8yTVtArL4sJlwj+ 1hyweOTkxgWv88xHl5OITgVsZvNnICs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669650990; 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=piyPDS1x1HNQHDQuqW9bM/s+6rGUXAkfrSmFDYgGfew=; b=MTryJ0xRIwdQu1/YIJcx2UcieQADiczmusvW8UcRrtczWB7tfujFe5GCn3fSS7iHqNBqv6 ZsAZ/HZhoJBjMxfWOlGUf+3sBL8HIveLLPxgV8Kht7zHaBIEpobZ+6+KD8EW606xAmQYid FLZ0np8QUfVz5HPe9en6h1AN7dRNIoY= X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 07CAF1C000C Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=eRzzj5Fa; spf=pass (imf21.hostedemail.com: domain of bfoster@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: k1f6mrtf8dyhk6gxmeo7zbipg73s9zqc X-HE-Tag: 1669650989-125645 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: generic_fadvise() sets endbyte = -1 to specify end of file (i.e. if length == 0 is passed from userspace). Most other callers to filemap_fdatawrite_range() use LLONG_MAX for this purpose, particularly if they also call fdatawait_range() (which requires end >= start). For example, sync_file_range(), vfs_fsync() (where the range is passed down through per-fs ->fsync() callbacks), filemap_flush(), etc. generic_fadvise() does not currently wait on writeback, but fix the call up to be consistent with other callers. Signed-off-by: Brian Foster Reviewed-by: Christoph Hellwig --- mm/fadvise.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/fadvise.c b/mm/fadvise.c index c76ee665355a..bf04fec87f35 100644 --- a/mm/fadvise.c +++ b/mm/fadvise.c @@ -72,7 +72,7 @@ int generic_fadvise(struct file *file, loff_t offset, loff_t len, int advice) */ endbyte = (u64)offset + (u64)len; if (!len || endbyte < len) - endbyte = -1; + endbyte = LLONG_MAX; else endbyte--; /* inclusive */