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 BA6F4C27C65 for ; Tue, 11 Jun 2024 18:10:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 52FF36B0085; Tue, 11 Jun 2024 14:10:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4DF7B6B00B4; Tue, 11 Jun 2024 14:10:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CEC06B00B7; Tue, 11 Jun 2024 14:10:19 -0400 (EDT) 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 1B1696B0085 for ; Tue, 11 Jun 2024 14:10:19 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id ABA58C151D for ; Tue, 11 Jun 2024 18:10:18 +0000 (UTC) X-FDA: 82219397316.23.4394DEE Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf29.hostedemail.com (Postfix) with ESMTP id 812C3120012 for ; Tue, 11 Jun 2024 18:10:16 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=IV9DMC+d; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=none (imf29.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718129417; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+8C4K0O1VTsIQOpcPvEVKsLduwUIDh16culMImH4PiU=; b=1b4QDGHMDzx6yJVE+/IubuUSW5M+pqKY2n2qRJkqSWDveUNH1s3kE4XizqsuSCDks6AZ8T QB5nRrDp+954UuJuy8w7nViDEGwOPL8DinKuToR8Caezc6Xljo7bkPaP88uMsAIsAHd9sv GwFIovvVGkWccISkQu/JY5vKmkyIHO0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=IV9DMC+d; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=none (imf29.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718129417; a=rsa-sha256; cv=none; b=tgAVlMUQ3k92Oh60qdjcCAZlfdCw/aMw6QyIDgeJ+NYDUQ8MrRetJaf1/bgiuiCvDFiurO WCw8aVW5or+zfSfnCo9AWetUgGdjkCgiIf2f4qEKDFvogJUxojPdZ2lte8borll5gsPOpb vn1n0qCbmueS9DNBG0c7u0A2xy19h8c= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=+8C4K0O1VTsIQOpcPvEVKsLduwUIDh16culMImH4PiU=; b=IV9DMC+d4/XGWyQOMmgwz5lThB k1bwJPc+XqT4q8ySl+fZcn+YjxvudTtEObDHCBK4qVjHbeCNxVOMDdg80DTYncSwKYjvdC68zQL0r a8/S9sdw22sXmZARPejwc9N4BGj8W0bYrRcexqbbZ9YrSsFZIuoHBjw+yb5EFOxG7Zlpv/xBluUk8 nPGFDNYFBsVVCM/rumJgnKCQJEO2XAMZRe1i1B0d1omSBOIxgENDPzBncsB/7lNKeQPkckT29D1fd chyJWQMtMdbYVzF/ULMKPxPo96e4vwXwOaNO26fL7uhoZ7LHpu6M8oAStZ2mdT4/kzuM7Es86AeR1 CnRLlHRA==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sH5wj-00000009nRZ-3nNX; Tue, 11 Jun 2024 18:10:13 +0000 Date: Tue, 11 Jun 2024 11:10:13 -0700 From: Luis Chamberlain To: "Darrick J. Wong" Cc: patches@lists.linux.dev, fstests@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org, ziy@nvidia.com, vbabka@suse.cz, seanjc@google.com, willy@infradead.org, david@redhat.com, hughd@google.com, linmiaohe@huawei.com, muchun.song@linux.dev, osalvador@suse.de, p.raghav@samsung.com, da.gomez@samsung.com, hare@suse.de, john.g.garry@oracle.com Subject: Re: [PATCH 2/5] fstests: add mmap page boundary tests Message-ID: References: <20240611030203.1719072-1-mcgrof@kernel.org> <20240611030203.1719072-3-mcgrof@kernel.org> <20240611164811.GL52977@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240611164811.GL52977@frogsfrogsfrogs> X-Rspamd-Queue-Id: 812C3120012 X-Stat-Signature: zzayuqzjsc6dsb8hpicb515rnnjcixsd X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1718129416-277023 X-HE-Meta: U2FsdGVkX1/mE0OJl0OVNwO4k96sdgl4VVHTry1AQPi8pS3doQNA04wVAwvS3Fy3aLL7swHos8feypjq1DPSQWc7zpbJVzuPajrTJbk5i8w7pVmr2cnqXJakQ5ef+6fMqCl0Je9f32TeJNGLbAeUzvBR6Ac5ln83R79YeGwPn0VAFARUEtwauJRolURcijg31FZZ6xJ99/X81H91vyzBVyRMYDOekqzPj/nQHq9UM1lq+b/Zj9UIR0COGv1FPvb1a+I6iniDCamlAMzB91BNzHzMLT8to9XDtupLY+K5Zkk0R7BdOR6umXxseoGkf/nL4t9O/ZFd7nkrLjyaIEXspi/fd5jJAnOvSwMmFXjpbDzjHXvdKRkZgJSZLPf0TqBbNH9eOvv0SfnYqdYDUq0fdNnytAs1Kg2KthmyhG69hr+Zaqrqg4PmF6XjJSJcjMDFO/ucr8q8cn9qabaS46NPgZBw+0A3ZvEPHbqZso3yk50QO+gToR5T7GsFhNuH1Pn1SQRHbEWa3Eald1finGtS8oGa8QElqYNpIXelR4NZ86nspTtXBYKe078YcDqTaHs6pCJkVfnZX5NNn0FsNLvXiPGM9EEA5Lx2jVjrgB39ibsi0yP24H8QRw7mptTx4O8DGfVsokocZIHn/5vKKeKWf/4rDBtJ2VYRTp9vhXyG9IF0iAnCmbvp+aOKf0mWQqHKxLKqOtygWsly37GV/0RFTM9AAeSVcn7iaFiX2Z7MOcvT8IAUwQZobIgtLearNT4HY6R/ZwL/uyVqpxCcoyt5E5aXgnT7nrPeq+OvD8cVJwJCVrvCorJGaeQGpVfHzPOr2vil8kx4GhtcqBi3NEjZERDQyBTMlO576Me78Xz4R4Pkhy2jtmTn5/AmfV7tECr8eBY7XXAu1AvXsL2Dl2KYPePun/t86b2vzmvKb1GBcF8I+91GBZRQDSKNVK6vK4MGITiJLd2RMGWucjECJ53 JEyW0N74 oaWIfTR1v7/1TNLh56CEBv77t2u3VepScsjtbvOqiCTHb6+/M9G/fKO6IAb2yTtLknqowf6uCH4TjAUT7OCvcohtBZNSrtZuVOZAmRRy/jaZQL8MHO1wCoI6Zkbho6Vp66HzDGJ3brKmcFu2o/bY5MYcC7T3dEKoUU9uEn+r4W6Opuc/IjNAm24TsTX48Ws3f9dADWWennKcyRQEzcYjz/8dYlB9AOQidAHNGnjtWTuSygOGjlDan4WDV3+20PRy6e/zOskzWQ6PF2hVW4XzfCoLwygS+dHXOVr/60XxAgsi0d4UcGmmCo0JyVw== 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: List-Subscribe: List-Unsubscribe: On Tue, Jun 11, 2024 at 09:48:11AM -0700, Darrick J. Wong wrote: > On Mon, Jun 10, 2024 at 08:01:59PM -0700, Luis Chamberlain wrote: > > +# As per POSIX NOTES mmap(2) maps multiples of the system page size, but if the > > +# data mapped is not multiples of the page size the remaining bytes are zeroed > > +# out when mapped and modifications to that region are not written to the file. > > +# On Linux when you write data to such partial page after the end of the > > +# object, the data stays in the page cache even after the file is closed and > > +# unmapped and even though the data is never written to the file itself, > > +# subsequent mappings may see the modified content. If you go *beyond* this > > Does this happen (mwrite data beyond eof sticks around) with large > folios as well? That corner case of checking to see if it stays is not tested by this test, but we could / should extend this test later for that. But then the question becomes, what is right, given we are in grey area, if we don't have any defined standard for it, it seems odd to test for it. So the test currently only tests for correctness of what we expect for POSIX and what we all have agreed for Linux. Hurding everyone to follow suit for the other corner cases is something perhaps we should do. Do we have a "strict fail" ? So that perhaps we can later add a test case for it and so that onnce and if we get consensus on what we do we can enable say a "strict-Linux" mode where we are pedantic about a new world order? > > + rm -rf "${SCRATCH_MNT:?}"/* > > rm -f $SCRATCH_MNT/file ? Sure. > > + # A couple of mmap() tests: > > + # > > + # We are allowed to mmap() up to the boundary of the page size of a > > + # data object, but there a few rules to follow we must check for: > > + # > > + # a) zero-fill test for the data: POSIX says we should zero fill any > > + # partial page after the end of the object. Verify zero-fill. > > + # b) do not write this bogus data to disk: on Linux, if we write data > > + # to a partially filled page, it will stay in the page cache even > > + # after the file is closed and unmapped even if it never reaches the > > + # file. Subsequent mappings *may* see the modified content, but it > > + # also can get other data. Since the data read after the actual > > What other data? Beats me, got that from the man page bible on mmap. I think its homework for us to find out who is spewing that out, which gives a bit more value to the idea of that strict-linux thing. How else will we find out? > > + # object data can vary we just verify the filesize does not change. > > + if [[ $map_len -gt $new_filelen ]]; then > > + zero_filled_data_len=$((map_len - new_filelen)) > > + _scratch_cycle_mount > > + expected_zero_data="00" > > + zero_filled_data=$($XFS_IO_PROG -r $test_file \ > > + -c "mmap -r 0 $map_len" \ > > + -c "mread -v $new_filelen $zero_filled_data_len" \ > > + -c "munmap" | \ > > + filter_xfs_io_data_unique) > > + if [[ "$zero_filled_data" != "$expected_zero_data" ]]; then > > + echo "Expected data: $expected_zero_data" > > + echo " Actual data: $zero_filled_data" > > + _fail "Zero-fill expectations with mmap() not respected" > > + fi > > + > > + _scratch_cycle_mount > > + $XFS_IO_PROG $test_file \ > > + -c "mmap -w 0 $map_len" \ > > + -c "mwrite $new_filelen $zero_filled_data_len" \ > > + -c "munmap" > > + sync > > + csum_post="$(_md5_checksum $test_file)" > > + if [[ "$csum_orig" != "$csum_post" ]]; then > > + echo "Expected csum: $csum_orig" > > + echo " Actual csum: $csum_post" > > + _fail "mmap() write up to page boundary should not change actual file contents" > > Do you really want to stop the test immediately? Or keep going and see > what other errors fall out? (i.e. s/_fail/echo/ here) Good point. We could go on, I'll change on the next v2. Thanks! Luis