On Sat, 16 Jun 2018, john.hubbard@xxxxxxxxx wrote: > I've come up with what I claim is a simple, robust fix, but...I'm > presuming to burn a struct page flag, and limit it to 64-bit arches, in > order to get there. Given that the problem is old (Jason Gunthorpe noted > that RDMA has been living with this problem since 2005), I think it's > worth it. > > Leaving the new page flag set "nearly forever" is not great, but on the > other hand, once the page is actually freed, the flag does get cleared. > It seems like an acceptable tradeoff, given that we only get one bit > (and are lucky to even have that). This is not robust. Multiple processes may register a page with the RDMA subsystem. How do you decide when to clear the flag? I think you would need an additional refcount for the number of times the page was registered. I still think the cleanest solution here is to require mmu notifier callbacks and to not pin the page in the first place. If a NIC does not support a hardware mmu then it can still simulate it in software by holding off the ummapping the mmu notifier callback until any pending operation is complete and then invalidate the mapping so that future operations require a remapping (or refaulting). -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
