On 04/11/13 15:38, Roger Pau Monne wrote: > The new GNTTABOP_unmap_and_duplicate operation doesn't zero the > mapping passed in new_addr, allowing us to perform batch unmaps in p2m > code without requiring the use of a multicall.
I have recently investigated some problems that were caused by a user space process using gntdev. It was unmapping page that still had outstanding I/O. This caused a number of failures: 1. Oopses due to swiotlb_bounce() attempting to memcpy() back to a page that now has a read-only mapping to a scratch page MFN. 2. Bad page errors due to the balloon page being freed by gntdev while the page count > 1 and the balloon driver setting page count to 1 and freeing the page. I think we need to take a step back and look at the design of the gntdev device to make it handle misbehaved or crashing programs. In particular, I think we need to use regular (non-ballooned) pages and restore their original direct mappings when grant unmapping. My initial thoughts are that this would require a GNTTABOP_unmap_and_replace variant that takes a GFN direct instead of a finding the GFN via a virtual address. I think it is best to hold off on any optimization attempts here until we get the gntdev design right. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
