On 2018-01-30 12:28 PM, Christian König wrote: > Am 30.01.2018 um 12:02 schrieb Michel Dänzer: >> On 2018-01-30 11:40 AM, Christian König wrote: >>> Am 30.01.2018 um 10:43 schrieb Michel Dänzer: >>>> [SNIP] >>>>> Would it be ok to hang onto potentially arbitrary mmget references >>>>> essentially forever? If that's ok I think we can do your process based >>>>> account (minus a few minor inaccuracies for shared stuff perhaps, >>>>> but no >>>>> one cares about that). >>>> Honestly, I think you and Christian are overthinking this. Let's try >>>> charging the memory to every process which shares a buffer, and go from >>>> there. >>> My problem is that this needs to be bullet prove. >>> >>> For example imagine an application which allocates a lot of BOs, then >>> calls fork() and let the parent process die. The file descriptor lives >>> on in the child process, but the memory is not accounted against the >>> child. >> What exactly are you referring to by "the file descriptor" here? > > The file descriptor used to identify the connection to the driver. In > other words our drm_file structure in the kernel. > >> What happens to BO handles in general in this case? If both parent and >> child process keep the same handle for the same BO, one of them >> destroying the handle will result in the other one not being able to use >> it anymore either, won't it? > Correct. > > That usage is actually not useful at all, but we already had > applications which did exactly that by accident. > > Not to mention that somebody could do it on purpose. Can we just prevent child processes from using their parent's DRM file descriptors altogether? Allowing it seems like a bad idea all around. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
