From: Denis Kirjanov <kda@linux-powerpc.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fs: export kern_path_locked
Date: Tue, 16 Feb 2021 17:31:33 +0300 [thread overview]
Message-ID: <CAOJe8K00srtuD+VAJOFcFepOqgNUm0mC8C=hLq2=qhUFSfhpuw@mail.gmail.com> (raw)
In-Reply-To: <YClpVIfHYyzd6EWu@zeniv-ca.linux.org.uk>
On 2/14/21, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, Jan 29, 2021 at 01:18:55PM +0000, Christoph Hellwig wrote:
>> On Fri, Jan 29, 2021 at 04:11:05PM +0300, Denis Kirjanov wrote:
>> > Do you mean just:
>>
>> We'll still need to lock the parent inode.
>
> Not just "lock", we wouldd need to have the lock _held_ across the
> entire sequence. Without that there's no warranty that it will refer
> to the same object we'd created.
>
> In any case, unlink in any potentially public area is pretty much
> never the right approach. Once mknod has happened, that's it - too
> late to bail out.
>
> IIRC, most of the PITA in that area is due to unix_autobind()
> iteractions. Basically, we try to bind() an unbound socket and
> another thread does sendmsg() on the same while we are in the
> middle of ->mknod(). Who should wait for whom?
>
> ->mknod() really should be a point of no return - any games with
> "so we unlink it" are unreliable in the best case, and that's
> only if we do _not_ unlock the parent through the entire sequence.
>
> Seeing that we have separate bindlock and iolock now... How about
> this (completely untested) delta?
We had a change like that:
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date: Mon Jan 23 11:17:35 2017 -0800
af_unix: move unix_mknod() out of bindlock
Dmitry reported a deadlock scenario:
unix_bind() path:
u->bindlock ==> sb_writer
do_splice() path:
sb_writer ==> pipe->mutex ==> u->bindlock
In the unix_bind() code path, unix_mknod() does not have to
be done with u->bindlock held, since it is a pure fs operation,
so we can just move unix_mknod() out.
>
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 41c3303c3357..c21038b15836 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -1034,6 +1034,14 @@ static int unix_bind(struct socket *sock, struct
> sockaddr *uaddr, int addr_len)
> goto out;
> addr_len = err;
>
> + err = mutex_lock_interruptible(&u->bindlock);
> + if (err)
> + goto out;
> +
> + err = -EINVAL;
> + if (u->addr)
> + goto out_up;
> +
> if (sun_path[0]) {
> umode_t mode = S_IFSOCK |
> (SOCK_INODE(sock)->i_mode & ~current_umask());
> @@ -1041,18 +1049,10 @@ static int unix_bind(struct socket *sock, struct
> sockaddr *uaddr, int addr_len)
> if (err) {
> if (err == -EEXIST)
> err = -EADDRINUSE;
> - goto out;
> + goto out_up;
> }
> }
>
> - err = mutex_lock_interruptible(&u->bindlock);
> - if (err)
> - goto out_put;
> -
> - err = -EINVAL;
> - if (u->addr)
> - goto out_up;
> -
> err = -ENOMEM;
> addr = kmalloc(sizeof(*addr)+addr_len, GFP_KERNEL);
> if (!addr)
> @@ -1090,7 +1090,6 @@ static int unix_bind(struct socket *sock, struct
> sockaddr *uaddr, int addr_len)
> spin_unlock(&unix_table_lock);
> out_up:
> mutex_unlock(&u->bindlock);
> -out_put:
> if (err)
> path_put(&path);
> out:
>
next prev parent reply other threads:[~2021-02-16 14:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210125154937.26479-1-kda@linux-powerpc.org>
[not found] ` <20210127175742.GA1744861@infradead.org>
[not found] ` <CAOJe8K0MC-TCURE2Gpci1SLnLXCbUkE7q6SS0fznzBA+Pf-B8Q@mail.gmail.com>
[not found] ` <20210129082524.GA2282796@infradead.org>
[not found] ` <CAOJe8K0iG91tm8YBRmE_rdMMMbc4iRsMGYNxJk0p9vEedNHEkg@mail.gmail.com>
[not found] ` <20210129131855.GA2346744@infradead.org>
2021-02-14 18:17 ` [PATCH] fs: export kern_path_locked Al Viro
2021-02-16 14:31 ` Denis Kirjanov [this message]
2021-02-16 18:00 ` Al Viro
2021-02-19 4:11 ` Al Viro
2021-02-19 4:19 ` [PATCH 1/8] af_unix: take address assignment/hash insertion into a new helper Al Viro
2021-02-20 19:12 ` Cong Wang
2021-02-20 19:32 ` Al Viro
2021-02-20 20:31 ` Cong Wang
2021-02-20 21:08 ` Al Viro
2021-02-22 19:06 ` [PATCHSET] making unix_bind() undo mknod on failure Al Viro
2021-02-22 19:12 ` [PATCH 1/8] af_unix: take address assignment/hash insertion into a new helper Al Viro
2021-02-22 19:12 ` [PATCH 2/8] unix_bind(): allocate addr earlier Al Viro
2021-02-22 19:12 ` [PATCH 3/8] unix_bind(): separate BSD and abstract cases Al Viro
2021-02-22 19:12 ` [PATCH 4/8] unix_bind(): take BSD and abstract address cases into new helpers Al Viro
2021-02-22 19:12 ` [PATCH 5/8] fold unix_mknod() into unix_bind_bsd() Al Viro
2021-02-22 19:12 ` [PATCH 6/8] unix_bind_bsd(): move done_path_create() call after dealing with ->bindlock Al Viro
2021-02-22 19:12 ` [PATCH 7/8] unix_bind_bsd(): unlink if we fail after successful mknod Al Viro
2021-02-22 19:12 ` [PATCH 8/8] __unix_find_socket_byname(): don't pass hash and type separately Al Viro
2021-02-22 19:12 ` [PATCHSET] making unix_bind() undo mknod on failure Al Viro
2021-02-22 19:24 ` Al Viro
2021-02-24 0:40 ` Jakub Kicinski
2021-02-19 4:20 ` [PATCH 2/8] unix_bind(): allocate addr earlier Al Viro
2021-02-19 4:21 ` [PATCH 3/8] unix_bind(): separate BSD and abstract cases Al Viro
2021-02-19 4:21 ` [PATCH 4/8] unix_bind(): take BSD and abstract address cases into new helpers Al Viro
2021-02-19 4:22 ` [PATCH 5/8] fold unix_mknod() into unix_bind_bsd() Al Viro
2021-02-19 4:22 ` [PATCH 6/8] unix_bind_bsd(): move done_path_create() call after dealing with ->bindlock Al Viro
2021-02-19 4:23 ` [PATCH 7/8] unix_bind_bsd(): unlink if we fail after successful mknod Al Viro
2021-02-19 4:23 ` [PATCH 8/8] __unix_find_socket_byname(): don't pass hash and type separately Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOJe8K00srtuD+VAJOFcFepOqgNUm0mC8C=hLq2=qhUFSfhpuw@mail.gmail.com' \
--to=kda@linux-powerpc.org \
--cc=hch@infradead.org \
--cc=kuba@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).