On Mon, Oct 26, 2020 at 01:28:30PM +0000, Matthew Wilcox wrote: > > > It's been five years since DAX was merged, and page pinning still > > > doesn't work. How much longer before the people who are pushing it > > > realise that it's fundamentally flawed? > > > > Is this a separate rant about *only* DAX, or is general RDMA in your sights > > too? :) > > This is a case where it's not RDMA's _fault_ that there's no good API > for it to do what it needs to do. There's a lot of work needed to wean > Linux device drivers off their assumption that there's a struct page > for every byte of memory. People who care seem to have just given up and are using RDMA ODP, so I'm not optimistic this DAX issue will ever be solved. I've also almost removed all the struct page references from this flow in RDMA, so if there is some way that helps it is certainly doable. Regardless of DAX the pinning indication is now being used during fork() for some good reasons, and seems to make sense in other use cases. It just doesn't seem like a way to solve the DAX issue. More or less it seems to mean that pages pinned cannot be write protected and more broadly the kernel should not change the PTEs for those pages independently of the application. ie the more agressive COW on fork() caused data corruption regressions... I wonder if the point here is that some page owners can't/won't support DMA pinning and should just be blocked completely for them. I'd much rather have write access pin_user_pages() just fail than oops the kernel on ext4 owned VMAs, for instance. Jason
