Messages in this thread | | | From | (Eric W. Biederman) | Date | Mon, 17 Sep 2018 22:45:09 +0200 | Subject | Re: [PATCH v3 1/3] exec: separate thread_count for files_struct |
| |
Oleg Nesterov <oleg@redhat.com> writes:
> On 09/16, Eric W. Biederman wrote: >> >> Oleg Nesterov <oleg@redhat.com> 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
| |