Re: kernel BUG at net/unix/garbage.c:149!"
From: Nikolay Borisov <hidden>
Date: 2016-09-27 14:16:41
Also in:
lkml
[Added Dave Miller to see what's the status of this patch] On 08/30/2016 12:18 PM, Miklos Szeredi wrote:
On Tue, Aug 30, 2016 at 12:37 AM, Miklos Szeredi [off-list ref] wrote:quoted
On Sat, Aug 27, 2016 at 11:55 AM, Miklos Szeredi [off-list ref] wrote:quoted
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
Dave, What's the status of https://patchwork.ozlabs.org/patch/664062/ , is this going to be picked up ? Regards, Nikolay