Re: [PATCH v3 1/3] exec: separate thread_count for files_struct

2018-09-17 Thread Eric W. Biederman
Oleg Nesterov writes: > On 09/16, Eric W. Biederman wrote: >> >> Oleg Nesterov 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

Re: [PATCH v3 1/3] exec: separate thread_count for files_struct

2018-09-17 Thread Oleg Nesterov
On 09/16, Eric W. Biederman wrote: > > Oleg Nesterov 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 a

Re: [PATCH v3 1/3] exec: separate thread_count for files_struct

2018-09-16 Thread Eric W. Biederman
Oleg Nesterov writes: > On 09/14, Jeff Layton wrote: >> >> Currently, we have a single refcount variable inside the files_struct. >> When we go to unshare the files_struct, we check this counter and if >> it's elevated, then we allocate a new files_struct instead of just >> repurposing the old on

Re: [PATCH v3 1/3] exec: separate thread_count for files_struct

2018-09-15 Thread Oleg Nesterov
On 09/14, Jeff Layton wrote: > > Currently, we have a single refcount variable inside the files_struct. > When we go to unshare the files_struct, we check this counter and if > it's elevated, then we allocate a new files_struct instead of just > repurposing the old one, under the assumption that th

[PATCH v3 1/3] exec: separate thread_count for files_struct

2018-09-14 Thread Jeff Layton
Currently, we have a single refcount variable inside the files_struct. When we go to unshare the files_struct, we check this counter and if it's elevated, then we allocate a new files_struct instead of just repurposing the old one, under the assumption that that indicates that it's shared between t