Re: [RFC PATCH 0/7] block, fs: convert Direct IO to FOLL_PIN
From: John Hubbard <jhubbard@nvidia.com>
Date: 2022-02-25 19:36:45
Also in:
linux-fsdevel, linux-mm, linux-xfs, lkml
From: John Hubbard <jhubbard@nvidia.com>
Date: 2022-02-25 19:36:45
Also in:
linux-fsdevel, linux-mm, linux-xfs, lkml
On 2/25/22 04:05, Jan Kara wrote: ...
quoted
After quite some time exploring and consulting with people as well, it is clear that this cannot be done in just one patchset. That's because, not only is this large and time-consuming (for example, Chaitanya Kulkarni's first reaction, after looking into the details, was, "convert the remaining filesystems to use iomap, *then* convert to FOLL_PIN..."), but it is also spread across many filesystems.With having modified fs/direct-io.c and fs/iomap/direct-io.c which filesystems do you know are missing conversion? Or is it that you just want to make sure with audit everything is fine? The only fs I could find unconverted by your changes is ceph. Am I missing something? Honza
There are a few more filesystems that call iov_iter_get_pages() or iov_iter_get_pages_alloc(), plus networking things as well, plus some others that are hard to categorize, such as vhost. So we have: * ceph * rds * cifs * p9 * net: __zerocopy_sg_from_iter(), tls_setup_from_iter(), * crypto: af_alg_make_sg() (maybe N/A) * vmsplice() (as David Hildenbrand mentioned) * vhost: vhost_scsi_map_to_sgl() In addition to that, I was also worried that maybe the blockdev_direct_IO() or iomap filesystems might be breaking encapsulation occasionally, by calling put_page() on the direct IO user page buffer. Perhaps in error paths. Are you pretty sure that that last concern is not valid? That would be a welcome bit of news. thanks, -- John Hubbard NVIDIA