Oleg Nesterov <oleg@xxxxxxxxxx> writes: > On 09/16, Eric W. Biederman wrote: >> >> Oleg Nesterov <oleg@xxxxxxxxxx> writes: >> >> > As for binder.c, in this case we probably actually want to unshare ->files >> > on exec so we can ignore it? >> >> Looking at the binder case it only captures ->files on mmap. Exec >> ditches the mmap. So if the order of operations are correct than >> the dropping of the old mm will also drop the count on files_struct >> held by binder. >> >> So semantically binder should not effect locks on exec, > > Agreed, but it does. > > Before your "[PATCH 0/3] exec: Moving unshare_files_struct" unshare_files() > is called before exec_mmap(). > > And even with this series we can have another CLONE_VM process. > > Howver, I think this doesn't really matter. binder does __fd_install(files), > so if it actually has a reference to execing_task->files, I think it should > be unshared anyway. > >> In short as long as we get the oder of operations correct we should be >> able to safely ignore binder, and not have binder affect the results of >> this code. > > Agreed. I may have spoken too soon. Binder uses schedule_work to call put_files_struct from munmap. So the files->count may still be elevated after the mm is put. Ick. Eric
