From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:60552 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751367AbcLJCiw (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Fri, 9 Dec 2016 21:38:52 -0500
Date: Sat, 10 Dec 2016 02:38:49 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-fsdevel@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>,
        Miklos Szeredi <mszeredi@redhat.com>
Subject: [RFC] vmsplice() and ->steal()
Message-ID: <20161210023849.GH1555@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

	vmsplice() generates pipe_bufs with ->steal() set to
user_page_pipe_buf_steal().  What should happen when the source pages
had code from an mmapped area and why shouldn't their ->steal()
do what page_cache_pipe_buf_release() does in that case?

	As it is, e.g. fuse_dev_splice_write() getting fed that stuff could,
AFAICS, clear MappedToDisk on such a page, scream about weird pages
(upon noticing non-NULL ->mapping) and fall back to copying (thankfully).
We don't have that many ->steal() users (as the matter of fact, I've
discovered that while trying to debug the breakage in one I'd been
trying to add), but I really wonder about the intended semantics of
->steal().

	Comments?