linux-kernel - Re: [PATCH mmotm] tmpfs: do not allocate pages on read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c3af6df8-af19-1b2-5f15-e4b69a31bc33@google.com>
Date:   Sun, 6 Mar 2022 14:56:16 -0800 (PST)
From:   Hugh Dickins <hughd@...gle.com>
To:     Christoph Hellwig <hch@....de>
cc:     Hugh Dickins <hughd@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mikulas Patocka <mpatocka@...hat.com>,
        Zdenek Kabelac <zkabelac@...hat.com>,
        Lukas Czerner <lczerner@...hat.com>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Miklos Szeredi <miklos@...redi.hu>,
        Borislav Petkov <bp@...e.de>, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH mmotm] tmpfs: do not allocate pages on read

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@google.com/
> 
> 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@...hat.com>
> > Reported-by: Lukas Czerner <lczerner@...hat.com>
> > Signed-off-by: Hugh Dickins <hughd@...gle.com>
> 
> 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