On Sun, 6 Mar 2022, Christoph Hellwig wrote: > On Fri, Mar 04, 2022 at 09:09:01PM -0800, Hugh Dickins wrote: > > It's not quite as simple as just removing the test (as Mikulas did): > > xfstests generic/013 hung because splice from tmpfs failed on page not > > up-to-date and page mapping unset. That can be fixed just by marking > > the ZERO_PAGE as Uptodate, which of course it is; doing so here in > > shmem_file_read_iter() is distasteful, but seems to be the best way. > > Shouldn't we set ZERO_PAGE uptodate during early init code as it, uh, > is per definition uptodate all the time? You're right, that does look hacky there. I was too unsure of when and how the different architectures set up ZERO_PAGE, so kept away. But looking through, pagecache_init() seems late enough in initialization and early enough in running, and an appropriate place to do it - tmpfs may be the first to need it, but it could be useful to others. Just on ZERO_PAGE(0), the one used all over: never mind the other colours of zero page, on those architectures which have multiple. v2 coming up. > > > > > My intention, though, was to stop using the ZERO_PAGE here altogether: > > surely iov_iter_zero() is better for this case? Sadly not: it relies > > on clear_user(), and the x86 clear_user() is slower than its copy_user(): > > https://lore.kernel.org/lkml/2f5ca5e4-e250-a41c-11fb-a7f4ebc7e1c9@xxxxxxxxxx/ > > Oh, that's sad as just using clear_user would be the right thing to > here. > > > But while we are still using the ZERO_PAGE, let's stop dirtying its > > struct page cacheline with unnecessary get_page() and put_page(). > > > > Reported-by: Mikulas Patocka <mpatocka@xxxxxxxxxx> > > Reported-by: Lukas Czerner <lczerner@xxxxxxxxxx> > > Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx> > > But except for maybe making sure that ZERO_PAGE is always marked > uptodate this does looks good to me. Thanks a lot for looking through. Hugh
