On Mon, Sep 21, 2020 at 10:35:05AM +0200, Jan Kara wrote: > > My thinking is to hit this issue you have to already be doing > > FOLL_LONGTERM, and if some driver hasn't been properly marked and > > regresses, the fix is to mark it. > > > > Remember, this use case requires the pin to extend after a system > > call, past another fork() system call, and still have data-coherence. > > > > IMHO that can only happen in the FOLL_LONGTERM case as it inhernetly > > means the lifetime of the pin is being controlled by userspace, not by > > the kernel. Otherwise userspace could not cause new DMA touches after > > fork. > > I agree that the new aggressive COW behavior is probably causing issues > only for FOLL_LONGTERM users. That being said it would be nice if even > ordinary threaded FOLL_PIN users would not have to be that careful about > fork(2) and possible data loss due to COW - we had certainly reports of > O_DIRECT IO loosing data due to fork(2) and COW exactly because it is very > subtle how it behaves... But as I wrote above this is not urgent since that > problematic behavior exists since the beginning of O_DIRECT IO in Linux. Yes, I agree - what I was thinking is to do this FOLL_LONGTERM for the rc and then a small patch to make it wider for the next cycle so it can test in linux-next for a responsible time period. Interesting to hear you confirm block has also seen subtle user problems with this as well. Jason
