From: Luis Chamberlain <mcgrof@kernel.org>
To: "Darrick J. Wong" <djwong@kernel.org>, da.gomez@samsung.com
Cc: fstests@vger.kernel.org, linux-fsdevel@vger.kernel.org,
willy@infradead.org, p.raghav@samsung.com, hare@suse.de,
john.g.garry@oracle.com, linux-xfs@vger.kernel.org,
patches@lists.linux.dev
Subject: Re: [RFC] fstests: add mmap page boundary tests
Date: Tue, 4 Jun 2024 21:40:13 -0700 [thread overview]
Message-ID: <Zl_sLbUlHu_RiMPY@bombadil.infradead.org> (raw)
In-Reply-To: <ZlZYG7-9-3NR4tdv@bombadil.infradead.org>
On Tue, May 28, 2024 at 03:18:03PM -0700, Luis Chamberlain wrote:
> On Mon, Apr 15, 2024 at 08:58:25AM -0700, Darrick J. Wong wrote:
> > On Mon, Apr 15, 2024 at 01:10:54AM -0700, Luis Chamberlain wrote:
> > > + # This is not true for tmpfs.
> >
> > Er... is this file size change a bug?
>
> There is no filesize bug, the comment about tmpfs always ensuring seeing
> the actual data since, well, there its kind of write-through. Since we
> share the same filemap_map_pages() I'd expect the rest should behave the
> same with tmpfs, but since I didn't test that the test skips it for now.
>
> We'll test it, with all the patch "filemap: cap PTE range to be
> created to allowed zero fill in folio_map_range()" on tmpfs, and see if
> we can just enable this test there too. Might as well as we're driving
> by and sprinkling large folios there too.
Turns out our patch "filemap: cap PTE range to be created to allowed
zero fill in folio_map_range()" ends up fixing this on tmpfs for huge
pages. So consider this now tested on tmpfs as well, I'll adjust the
test for that.
Luis
next prev parent reply other threads:[~2024-06-05 4:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 8:10 [RFC] fstests: add mmap page boundary tests Luis Chamberlain
2024-04-15 15:58 ` Darrick J. Wong
2024-04-22 14:09 ` Pankaj Raghav (Samsung)
2024-05-28 22:18 ` Luis Chamberlain
2024-06-05 4:40 ` Luis Chamberlain [this message]
2024-04-15 20:05 ` Zorro Lang
2024-05-28 22:23 ` Luis Chamberlain
2024-04-22 14:12 ` Pankaj Raghav (Samsung)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zl_sLbUlHu_RiMPY@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=da.gomez@samsung.com \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=hare@suse.de \
--cc=john.g.garry@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=p.raghav@samsung.com \
--cc=patches@lists.linux.dev \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox