On Fri, Jan 27, 2023 at 12:44:08AM +0100, David Hildenbrand wrote:

On 26.01.23 23:36, Al Viro wrote:

quoted

On Thu, Jan 26, 2023 at 09:59:36PM +0000, Al Viro wrote:

quoted

On Thu, Jan 26, 2023 at 02:16:20PM +0000, David Howells wrote:

quoted

+/**
+ * iov_iter_extract_will_pin - Indicate how pages from the iterator will be retained
+ * @iter: The iterator
+ *
+ * Examine the iterator and indicate by returning true or false as to how, if
+ * at all, pages extracted from the iterator will be retained by the extraction
+ * function.
+ *
+ * %true indicates that the pages will have a pin placed in them that the
+ * caller must unpin.  This is must be done for DMA/async DIO to force fork()
+ * to forcibly copy a page for the child (the parent must retain the original
+ * page).
+ *
+ * %false indicates that no measures are taken and that it's up to the caller
+ * to retain the pages.
+ */
+static inline bool iov_iter_extract_will_pin(const struct iov_iter *iter)
+{
+	return user_backed_iter(iter);
+}
+

Wait a sec; why would we want a pin for pages we won't be modifying?
A reference - sure, but...

After having looked through the earlier iterations of the patchset -
sorry, but that won't fly for (at least) vmsplice().  There we can't
pin those suckers;

We'll need a way to pass FOLL_LONGTERM to pin_user_pages_fast() to handle
such long-term pinning as vmsplice() needs. But the release path (unpin)
will be the same.

Umm...  Are you saying that if the source area contains DAX mmaps, vmsplice()
from it will fail?