Re: [PATCH -next] ovl: respect underlying filesystem's get_unmapped_area()

[Matthew Wilcox <willy@infradead.org>]

On Tue, Dec 10, 2024 at 03:13:21PM +0800, Jinjiang Tu wrote:
> 在 2024/12/9 21:33, Matthew Wilcox 写道:
> > On Mon, Dec 09, 2024 at 02:43:08PM +0800, Jinjiang Tu wrote:
> > > 在 2024/12/6 21:58, Matthew Wilcox 写道:
> > > > On Thu, Dec 05, 2024 at 10:30:38PM +0800, Jinjiang Tu wrote:
> > > > > During our tests in containers, there is a read-only file (i.e., shared
> > > > Show your test.
> > > I mmap an overlayfs file with PROT_READ, and call madvise(MADV_COLLAPSE), the code
> > > is as follows:
> > > 
> > > 	fd = open(path, O_RDONLY);
> > > 	addr = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
> > > 	ret = madvise(addr, size, MADV_COLLAPSE);
> > > 
> > > The addr isn't THP-aligned and ret is -1, errno is EINVAL.
> > Then your test is buggy.
> > 
> >           * Check alignment for file vma and size for both file and anon vma by
> >           * filtering out the unsuitable orders.
> > 
> > You didn't align your mmap, so it's expected to fail.
> 
> When mmap an ext4 file, since ext4_file_operations defines ".get_unmapped_area = thp_get_unmapped_area", it calls thp_get_unmapped_area() in __get_unmapped_area to
> mmap at a THP-aligned address.
> 
> For overlayfs file, it's underlying filesystem may be ext4, which supports large folio. For this situation, should we mmap at a THP-aligned address too, to map
> THP?

Actually, ext4 doesn't support large folios.  thp_get_unmapped_area()
was added for DAX in 2016 (dbe6ec815641).