Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 17 May 2023 08:55:27 +0100
From:   Lorenzo Stoakes <lstoakes@gmail.com>
To:     Christoph Hellwig <hch@infradead.org>
Cc:     Jan Kara <jack@suse.cz>, Jason Gunthorpe <jgg@nvidia.com>,
        "Kirill A . Shutemov" <kirill@shutemov.name>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Jens Axboe <axboe@kernel.dk>,
        Matthew Wilcox <willy@infradead.org>,
        Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>,
        Leon Romanovsky <leon@kernel.org>,
        Christian Benvenuti <benve@cisco.com>,
        Nelson Escobar <neescoba@cisco.com>,
        Bernard Metzler <bmt@zurich.ibm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Ian Rogers <irogers@google.com>,
        Adrian Hunter <adrian.hunter@intel.com>,
        Bjorn Topel <bjorn@kernel.org>,
        Magnus Karlsson <magnus.karlsson@intel.com>,
        Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
        Jonathan Lemon <jonathan.lemon@gmail.com>,
        "David S . Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Christian Brauner <brauner@kernel.org>,
        Richard Cochran <richardcochran@gmail.com>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Jesper Dangaard Brouer <hawk@kernel.org>,
        John Fastabend <john.fastabend@gmail.com>,
        linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org,
        netdev@vger.kernel.org, bpf@vger.kernel.org,
        Oleg Nesterov <oleg@redhat.com>,
        John Hubbard <jhubbard@nvidia.com>,
        Pavel Begunkov <asml.silence@gmail.com>,
        Mika Penttila <mpenttil@redhat.com>,
        David Hildenbrand <david@redhat.com>,
        Dave Chinner <david@fromorbit.com>,
        Theodore Ts'o <tytso@mit.edu>, Peter Xu <peterx@redhat.com>,
        Matthew Rosato <mjrosato@linux.ibm.com>,
        "Paul E . McKenney" <paulmck@kernel.org>,
        Christian Borntraeger <borntraeger@linux.ibm.com>
Subject: Re: [PATCH v9 0/3] mm/gup: disallow GUP writing to file-backed
 mappings by default
Message-ID: <503e92f9-fbc2-422b-b0d4-f4cabe3f6802@lucifer.local>
References: <cover.1683235180.git.lstoakes@gmail.com>
 <20230515110315.uqifqgqkzcrrrubv@box.shutemov.name>
 <7f6dbe36-88f2-468e-83c1-c97e666d8317@lucifer.local>
 <ZGIhwZl2FbLodLrc@nvidia.com>
 <ad0053a4-fa34-4b95-a262-d27942b168fd@lucifer.local>
 <20230517072920.bfs7gfo4whdmi6ay@quack3>
 <d17c0fce-679b-4f5d-9a7c-6ff7e28ad4b2@lucifer.local>
 <ZGSFptUyOko+184t@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZGSFptUyOko+184t@infradead.org>
Precedence: bulk

On Wed, May 17, 2023 at 12:43:34AM -0700, Christoph Hellwig wrote:
> On Wed, May 17, 2023 at 08:40:26AM +0100, Lorenzo Stoakes wrote:
> > > I'm not sure what you mean by "total flexibility" here. In my opinion it is
> > > also about how HW performs checksumming etc.
> >
> > I mean to say *_ops allow a lot of flexibility in how things are
> > handled. Certainly checksumming is a great example but in theory an
> > arbitrary filesystem could be doing, well, anything and always assuming
> > that only userland mappings should be modifying the underlying data.
>
> File systems need a wait to track when a page is dirtied so that it can
> be written back.  Not much to do with flexbility.

I'll try to take this in good faith because... yeah. I do get that, I mean
I literally created a repro for this situation and referenced in the commit
msg and comments this precise problem in my patch series that
addresses... this problem :P

Perhaps I'm not being clear but it was simply my intent to highlight that
yes this is the primary problem but ALSO GUP writing to ostensibly 'clean'
pages 'behind the back' of a fs is _also_ a problem.

Not least for checksumming (e.g. assume hw-reported checksum for a block ==
checksum derived from page cache) but, because VFS allows a great deal of
flexibility in how filesystems are implemented, perhaps in other respects
we haven't considered.

So I just wanted to highlight (happy to be corrected if I'm wrong) that the
PRIMARY problem is the dirty tracking breaking, but also strikes me that
arbitrary writes to 'clean' pages in the background is one too.