On 09/14, Jeff Layton wrote: > > POSIX mandates that open fds and their associated file locks should be > preserved across an execve. This works, unless the process is > multithreaded at the time that execve is called. > > In that case, we'll end up unsharing the files_struct but the locks will > still have their fl_owner set to the address of the old one. Eventually, > when the other threads die and the last reference to the old > files_struct is put, any POSIX locks get torn down since it looks like > a close occurred on them. > > The result is that all of your open files will be intact with none of > the locks you held before execve. The simple answer to this is "use OFD > locks", but this is a nasty surprise and it violates the spec. > > Fix this by doing unshare_files later during exec, See my reply to 1/3... if we can forget about the races with get_files_struct() we can probably make a much simpler patch, plus we do not need 2/2, afaics. What I really can't understand is why we need to _change_ current->files early in do_execve(). IOW. Lets ignore do_close_on_exec(), lets ignore the fact that unshare_fd() can fail and thus it makes sense to call it before point-of-no-return. Any other reason why we can't simply call unshare_files() at the end of __do_execve_file() on success? Oleg.
