From mboxrd@z Thu Jan 1 00:00:00 1970 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 C4274FA3740 for ; Mon, 31 Oct 2022 04:51:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B42666B0071; Mon, 31 Oct 2022 00:51:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF23D6B0073; Mon, 31 Oct 2022 00:51:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E10B6B0074; Mon, 31 Oct 2022 00:51:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 78BC06B0071 for ; Mon, 31 Oct 2022 00:51:08 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D71EBA0571 for ; Mon, 31 Oct 2022 04:51:06 +0000 (UTC) X-FDA: 80080020132.11.5AB5720 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf21.hostedemail.com (Postfix) with ESMTP id 43F391C0009 for ; Mon, 31 Oct 2022 04:51:03 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4DF72B810BF; Mon, 31 Oct 2022 04:51:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6100C433C1; Mon, 31 Oct 2022 04:51:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1667191861; bh=S6NM6BlIyylL81yC4r7Y3zIJpoXSiYXGE+JKiWXBHy8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=l+Bns/lebWGp4U3J7wQI11W1G+Hr3L+abkAw2e9Zpult1KnbV6Yysuj1cLAZec6np BJoYmj0bHzCy1AKUryF70Mvqeznn5zNLbPY/f2oEKwrQR+mf0AMqvqCPsDpdkBjaEb FKihWUYBCRQ9+R3/fhb6ufzzpacrKa+w7dqeNv+k= Date: Sun, 30 Oct 2022 21:51:00 -0700 From: Andrew Morton To: Brian Foster Cc: linux-mm@kvack.org Subject: Re: [PATCH] filemap: skip range writeback if end offset precedes start Message-Id: <20221030215100.f5e7116e848077c96d86591d@linux-foundation.org> In-Reply-To: <20221028125428.976549-1-bfoster@redhat.com> References: <20221028125428.976549-1-bfoster@redhat.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="l+Bns/le"; spf=pass (imf21.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667191864; a=rsa-sha256; cv=none; b=JZO7kT4MCprGf0vg5YaRWUJyFo598cAoipiVFBdE/005/in5yvd7TW0AZYQaZjt68PnKVW JczlXYOj5neZIK/Oac2FXB6GvFZKeTkBwz6s6JVQ0lAFNR8WMJMrK8ytA0kStfybAI+S5s c4XNf2oDNW5nS1iRm8YZA8vI+Q9JuKM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667191864; 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=mlyz/Z3vTax3VAMmqSj4M2KeN99bXQ9i+4GpemKmzIQ=; b=ybSp7i+/5SPP7ApX6jLozM6UP9V7uFXO7mB/3gLfdGk8KLtlU9TL3RCvCJI8YfJMF2pKln N97+w3lkWRwHL8siXaXMrpS75pXLXpQBd6syDTZFxcsP8346slO2XKxwhj+OqVo4QBVGXz mLL/ZvD19Oke9NG0Oim4KHygsffIIJM= X-Rspam-User: X-Rspamd-Queue-Id: 43F391C0009 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="l+Bns/le"; spf=pass (imf21.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Stat-Signature: h8ig9bwx1or3zbait8fz7449y1nd4ytj X-Rspamd-Server: rspam10 X-HE-Tag: 1667191863-362209 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: On Fri, 28 Oct 2022 08:54:28 -0400 Brian Foster wrote: > 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. > > ... > > --- 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); > } Is there any way in which this condition can be triggered from userspace? Or from any non-buggy kernelspace? Should we have a WARN_ON() in there to detect this?