From patchwork Fri Oct 28 12:54:28 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Foster X-Patchwork-Id: 13023572 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 B33A9C38A02 for ; Fri, 28 Oct 2022 12:54:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 146246B0072; Fri, 28 Oct 2022 08:54:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F67D6B0073; Fri, 28 Oct 2022 08:54:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F00246B0074; Fri, 28 Oct 2022 08:54:35 -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 E0DD96B0072 for ; Fri, 28 Oct 2022 08:54:35 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id AC8CD4130D for ; Fri, 28 Oct 2022 12:54:35 +0000 (UTC) X-FDA: 80070352110.29.C8B749D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id 2EED81C0019 for ; Fri, 28 Oct 2022 12:54:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666961673; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=1wRYo6ogME3Bhex5eWhy3JsKLssIPh4+i6i/Tgx+8/E=; b=EEnjT50/1DTc6MSfIKX5nF6mwb7UjHj7PMeEBpbo0Gk1BXCmimGGHkX9wUykhc9ToFQb1T I62OWz4TuJBGGaEPL4JjNeklprfPsJUMvsh+wkcNXiVZaeCR2GMmUscBJmUpiote8pa7eD WB+IdeRllJ+510n6SHc4rR9YnemMDw0= 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-646-BIhsrnXjNti58cksprLBQg-1; Fri, 28 Oct 2022 08:54:23 -0400 X-MC-Unique: BIhsrnXjNti58cksprLBQg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B84F91C09C86 for ; Fri, 28 Oct 2022 12:54:22 +0000 (UTC) Received: from bfoster.redhat.com (unknown [10.22.16.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id A1A1E2166B26 for ; Fri, 28 Oct 2022 12:54:22 +0000 (UTC) From: Brian Foster To: linux-mm@kvack.org Subject: [PATCH] filemap: skip range writeback if end offset precedes start Date: Fri, 28 Oct 2022 08:54:28 -0400 Message-Id: <20221028125428.976549-1-bfoster@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 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=1666961674; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=1wRYo6ogME3Bhex5eWhy3JsKLssIPh4+i6i/Tgx+8/E=; b=qat/4IVsmOe7ltrTcqiTrw0Aq/wwLUj1XBndwz3yAE2yi/mNve2eq2KeL+20oNWQPgT74K jgWyHFNKbZXJg9c4OlGlui7t/oKS5DB3r4ibvTceQILb6bu90TOWxYftu8nfw4stB5FrTY 0Qa2iY00GYsgGb8rc2aNKJPFXrFTjZg= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="EEnjT50/"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf21.hostedemail.com: domain of bfoster@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666961674; a=rsa-sha256; cv=none; b=PdVFlTcXZWeTBvDbp4AwKZWB+svzTP3UxiPp1LCmYUO4Y8jf+x2K8GfgWFvV+P0zOidXpV RmjDW/dkJIpoEjrEDE0YeD7E51wgIF0N+I6tHBcvuk/ieo2ypLYBV/Yy8uanik/6Wm9YU3 gd5IKr3Eup4TG/ZPRu1jQgCgo6SFxXM= X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 2EED81C0019 X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="EEnjT50/"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf21.hostedemail.com: domain of bfoster@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com X-Stat-Signature: swc3sff3dz51qrks77e9wtug8uqds499 X-HE-Tag: 1666961674-243671 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 fail 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. __filemap_fdatawait_range() immediately returns if the specified end offset precedes the start offset, however. I suspect these checks are primarily intended to handle overflow conditions. I happened to notice this behavior when investigating an unrelated problem and observed that a filemap_write_and_wait_range() call with unexpected parameters had seemingly unpredictable latency. That latency turned out to be the submission path occasionally waiting on writeback state of the page (i.e. from write_cache_pages()) before issuing the currently requested writepage and then unconditionally failing to wait on the latter via __filemap_fdatawait_range(). This could probably be reasonably fixed to either elide the submission, as this patch does, or modify the fdatawait path to check the page indexes instead of the unaligned offsets. After poking around a bit, it seemed more consistent with various other filemap interfaces to check the offsets in the write path and return if the end offset is not >= the start. For example, filemap_range_has_page() and filemap_range_has_writeback() both include similar byte granularity checks. Signed-off-by: Brian Foster --- mm/filemap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/filemap.c b/mm/filemap.c index 08341616ae7a..99d8686c9f5c 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -418,6 +418,9 @@ int __filemap_fdatawrite_range(struct address_space *mapping, loff_t start, .range_end = end, }; + if (end < start) + return 0; + return filemap_fdatawrite_wbc(mapping, &wbc); }