On Mon, 2016-08-15 at 13:53 +0100, Chris Wilson wrote: > > So it is really just what happens to commands for this client when it > dies/exits. The kneejerk reaction is to say the pages should be kept > alive as they are now for !svm. We could be faced with a situation where > the client copies onto a shared buffer (obtaining a fence), passes that > fence over to the server scheduling an update, and die abruptly. Which pages? Until the moment you actually do the DMA, you don't have "pages". They might not even exist in RAM. All you have is (a PASID and) a userspace linear address. When you actually the DMA, *then* we might fault in the appropriate pages from disk. Or might not, depending on whether the address is valid or not. Between the time when it hands you the linear address, and the time that you use it, the process could have done anything. we are currently talking about the case where it exits uncleanly. But it could also munmap() the linear address in question. Or mmap() something else over it. Obviously those would be bugs... but so is an unclean exit. So it doesn't seem to make much sense to ask if you accept the change in behaviour. You don't really have much choice; it's implicit in the SVM model of doing DMA directly to userspace addresses. You just *don't* get to lock things down and trust that the buffers will still be there when you finally get round to using them. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
