linux-kernel - Re: [PATCH v3 56/68] afs: Handle len being extending over page end in write_begin/write

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1828149.1639673252@warthog.procyon.org.uk>
Date:   Thu, 16 Dec 2021 16:47:32 +0000
From:   David Howells <dhowells@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>
Cc:     dhowells@...hat.com, linux-cachefs@...hat.com,
        Jeff Layton <jlayton@...nel.org>,
        Marc Dionne <marc.dionne@...istor.com>,
        linux-afs@...ts.infradead.org,
        Trond Myklebust <trondmy@...merspace.com>,
        Anna Schumaker <anna.schumaker@...app.com>,
        Steve French <sfrench@...ba.org>,
        Dominique Martinet <asmadeus@...ewreck.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Omar Sandoval <osandov@...ndov.com>,
        JeffleXu <jefflexu@...ux.alibaba.com>,
        "open list:NFS, SUNRPC, AND..." <linux-nfs@...r.kernel.org>,
        CIFS <linux-cifs@...r.kernel.org>, ceph-devel@...r.kernel.org,
        v9fs-developer@...ts.sourceforge.net,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 56/68] afs: Handle len being extending over page end in write_begin/write_end

Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> > With transparent huge pages, in the future, write_begin() and write_end()
> > may be passed a length parameter that, in combination with the offset into
> > the page, exceeds the length of that page.  This allows
> > grab_cache_page_write_begin() to better choose the size of THP to allocate.
> 
> I still think this is a fundamental bug in the caller. That
> "explanation" is weak, and the whole concept smells like week-old fish
> to me.

You really should ask Willy about this as it's multipage folio-related.

AIUI, because the page/folio may be allocated inside ->write_begin(),
generic_perform_write() tells the filesystem how much it has been asked to
write and then the folio allocation can be made to fit that.

However, at this time, ->write_begin() and ->write_end() have a page pointer
(or pointer-to-pointer), not a folio pointer, in their signature, so the
filesystem has to convert between them.

I'm working on write helpers for netfslib that absorb this out of the
filesystems that use it into its own take on generic_perform_write(), thereby
eliminating the need for ->write_begin and ->write_end.  I have this kind of
working for afs and 9p at the moment and am looking at ceph, but there's a way
to go yet.  I believe iomap does the same for block-based filesystems that use
it (such as xfs).

I think Willy's aim is to get rid of ->write_begin and ->write_end entirely.

David