On Sun, Feb 05, 2017 at 11:22:12PM -0800, Cong Wang wrote: > On Tue, Jan 31, 2017 at 10:14 AM, Mateusz Guzik <mgu...@redhat.com> wrote: > > On Mon, Jan 30, 2017 at 10:44:03PM -0800, Cong Wang wrote: > >> Mind being more specific? > > > > Consider 2 threads which bind the same socket, but with different paths. > > > > Currently exactly one file will get created, the one used to bind. > > > > With your patch both threads can succeed creating their respective > > files, but only one will manage to bind. The other one must error out, > > but it already created a file it is unclear what to do with. > > In this case, it simply puts the path back: > > err = -EINVAL; > if (u->addr) > goto out_up; > [...] > > out_up: > mutex_unlock(&u->bindlock); > out_put: > if (err) > path_put(&path); > out: > return err; > > > Which is what unix_release_sock() does too: > > if (path.dentry) > path_put(&path);
Yes, but unix_release_sock is expected to leave the file behind. Note I'm not claiming there is a leak, but that racing threads will be able to trigger a condition where you create a file and fail to bind it. What to do with the file now? Untested, but likely a working solution would rework the code so that e.g. a flag is set and the lock can be dropped.
