Re: fs, net: deadlock between bind/splice on af_unix

On Sun, Feb 05, 2017 at 11:22:12PM -0800, Cong Wang wrote:

On Tue, Jan 31, 2017 at 10:14 AM, Mateusz Guzik [off-list ref] wrote:

quoted

On Mon, Jan 30, 2017 at 10:44:03PM -0800, Cong Wang wrote:

quoted

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.