Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > But can you please also take care of the legacy direct I/O code? I'd really > hate to leave yet another unfinished transition around. I've been poking at it this afternoon, but it doesn't look like it's going to be straightforward, unfortunately. The mm folks have been withdrawing access to the pinning API behind the ramparts of the mm/ dir. Further, the dio code will (I think), under some circumstances, arbitrarily insert the zero_page into a list of things that are maybe pinned or maybe unpinned, but I can (I think) also be given a pinned zero_page from the GUP code if the page tables point to one and a DIO-write is requested - so just doing if page == zero_page isn't sufficient. What I'd like to do is to make the GUP code not take a ref on the zero_page if, say, FOLL_DONT_PIN_ZEROPAGE is passed in, and then make the bio cleanup code always ignore the zero_page. Alternatively, I can drop the pin immediately if I get given one on the zero_page - it's not going anywhere, after all. I also need to be able to take an additional pin on a folio that gets split across multiple bio submissions to replace the get_page() that's there now. Alternatively to that, I can decide how much data I'm willing to read/write in one batch, call something like netfs_extract_user_iter() to decant that portion of the parameter iterator into an bvec[] and let that look up the overlapping page multiple times. However, I'm not sure if this would work well for a couple of reasons: does a single bio have to refer to a contiguous range of disk blocks? and we might expend time on getting pages we then have to give up because we hit a hole. Something that I noticed is that the dio code seems to wangle to page bits on the target pages for a DIO-read, which seems odd, but I'm not sure I fully understand the code yet. David
