From: Miklos Szeredi <mszeredi@redhat.com>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Nikolay Borisov <kernel@kyup.com>,
"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
netdev@vger.kernel.org
Subject: Re: kernel BUG at net/unix/garbage.c:149!"
Date: Tue, 30 Aug 2016 11:18:10 +0200 [thread overview]
Message-ID: <CAOssrKcfncAYsQWkfLGFgoOxAQJVT2hYVWdBA6Cw7hhO8RJ_wQ@mail.gmail.com> (raw)
In-Reply-To: <CAOssrKedUEAcZThhd2FB9UPzhr+5ErLjB=3+1z1XdnFeP6wvmg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]
On Tue, Aug 30, 2016 at 12:37 AM, Miklos Szeredi <mszeredi@redhat.com> wrote:
> On Sat, Aug 27, 2016 at 11:55 AM, Miklos Szeredi <mszeredi@redhat.com> wrote:
> crash> list -H gc_inflight_list unix_sock.link -s unix_sock.inflight |
> grep counter | cut -d= -f2 | awk '{s+=$1} END {print s}'
> 130
> crash> p unix_tot_inflight
> unix_tot_inflight = $2 = 135
>
> We've lost track of a total of five inflight sockets, so it's not a
> one-off thing. Really weird... Now off to sleep, maybe I'll dream of
> the solution.
Okay, found one bug: gc assumes that in-flight sockets that don't have
an external ref can't gain one while unix_gc_lock is held. That is
true because unix_notinflight() will be called before detaching fds,
which takes unix_gc_lock. Only MSG_PEEK was somehow overlooked. That
one also clones the fds, also keeping them in the skb. But through
MSG_PEEK an external reference can definitely be gained without ever
touching unix_gc_lock.
Not sure whether the reported bug can be explained by this. Can you
confirm the MSG_PEEK was used in the setup?
Does someone want to write a stress test for SCM_RIGHTS + MSG_PEEK?
Anyway, attaching a fix that works by acquiring unix_gc_lock in case
of MSG_PEEK also. It is trivially correct, but I haven't tested it.
Thanks,
Miklos
[-- Attachment #2: af_unix-fix-garbage-collect-vs-msg_peek.patch --]
[-- Type: text/x-patch, Size: 2518 bytes --]
From: Miklos Szeredi <mszeredi@redhat.com>
Subject: af_unix: fix garbage collect vs. MSG_PEEK
Gc assumes that in-flight sockets that don't have an external ref can't
gain one while unix_gc_lock is held. That is true because
unix_notinflight() will be called before detaching fds, which takes
unix_gc_lock.
Only MSG_PEEK was somehow overlooked. That one also clones the fds, also
keeping them in the skb. But through MSG_PEEK an external reference can
definitely be gained without ever touching unix_gc_lock.
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Cc: <stable@vger.kernel.org>
---
include/net/af_unix.h | 1 +
net/unix/af_unix.c | 15 +++++++++++++--
net/unix/garbage.c | 6 ++++++
3 files changed, 20 insertions(+), 2 deletions(-)
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -10,6 +10,7 @@ void unix_inflight(struct user_struct *u
void unix_notinflight(struct user_struct *user, struct file *fp);
void unix_gc(void);
void wait_for_unix_gc(void);
+void unix_gc_barrier(void);
struct sock *unix_get_socket(struct file *filp);
struct sock *unix_peer_get(struct sock *);
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1563,6 +1563,17 @@ static int unix_attach_fds(struct scm_co
return max_level;
}
+static void unix_peek_fds(struct scm_cookie *scm, struct sk_buff *skb)
+{
+ scm->fp = scm_fp_dup(UNIXCB(skb).fp);
+ /*
+ * During garbage collection it is assumed that in-flight sockets don't
+ * get a new external reference. So we need to wait until current run
+ * finishes.
+ */
+ unix_gc_barrier();
+}
+
static int unix_scm_to_skb(struct scm_cookie *scm, struct sk_buff *skb, bool send_fds)
{
int err = 0;
@@ -2195,7 +2206,7 @@ static int unix_dgram_recvmsg(struct soc
sk_peek_offset_fwd(sk, size);
if (UNIXCB(skb).fp)
- scm.fp = scm_fp_dup(UNIXCB(skb).fp);
+ unix_peek_fds(&scm, skb);
}
err = (flags & MSG_TRUNC) ? skb->len - skip : size;
@@ -2435,7 +2446,7 @@ static int unix_stream_read_generic(stru
/* It is questionable, see note in unix_dgram_recvmsg.
*/
if (UNIXCB(skb).fp)
- scm.fp = scm_fp_dup(UNIXCB(skb).fp);
+ unix_peek_fds(&scm, skb);
sk_peek_offset_fwd(sk, chunk);
--- a/net/unix/garbage.c
+++ b/net/unix/garbage.c
@@ -266,6 +266,12 @@ void wait_for_unix_gc(void)
wait_event(unix_gc_wait, gc_in_progress == false);
}
+void unix_gc_barrier(void)
+{
+ spin_lock(&unix_gc_lock);
+ spin_unlock(&unix_gc_lock);
+}
+
/* The external entry point: unix_gc() */
void unix_gc(void)
{
next prev parent reply other threads:[~2016-08-30 9:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-24 14:24 kernel BUG at net/unix/garbage.c:149!" Nikolay Borisov
2016-08-24 21:40 ` Hannes Frederic Sowa
2016-08-24 23:30 ` Nikolay Borisov
2016-08-26 20:24 ` Hannes Frederic Sowa
2016-08-27 9:55 ` Miklos Szeredi
2016-08-29 22:37 ` Miklos Szeredi
2016-08-30 9:18 ` Miklos Szeredi [this message]
2016-08-30 9:31 ` Nikolay Borisov
2016-08-30 9:39 ` Miklos Szeredi
2016-09-01 9:13 ` Hannes Frederic Sowa
2016-09-27 14:16 ` Nikolay Borisov
2016-09-27 14:43 ` Hannes Frederic Sowa
2016-09-28 2:05 ` David Miller
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=CAOssrKcfncAYsQWkfLGFgoOxAQJVT2hYVWdBA6Cw7hhO8RJ_wQ@mail.gmail.com \
--to=mszeredi@redhat.com \
--cc=hannes@stressinduktion.org \
--cc=kernel@kyup.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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).