Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1491931 > unrolled thread

Re: kernel BUG at net/unix/garbage.c:149!"

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: kernel BUG at net/unix/garbage.c:149!" Nikolay Borisov <kernel@kyup.com> - 2016-09-27 16:20 +0200
    Re: kernel BUG at net/unix/garbage.c:149!" Hannes Frederic Sowa <hannes@stressinduktion.org> - 2016-09-27 16:50 +0200
    Re: kernel BUG at net/unix/garbage.c:149!" David Miller <davem@davemloft.net> - 2016-09-28 04:10 +0200

#1491931 — Re: kernel BUG at net/unix/garbage.c:149!"

[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 <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
> 


Dave,

What's the status of https://patchwork.ozlabs.org/patch/664062/ , is
this going to be picked up ?

Regards,
Nikolay

[toc] | [next] | [standalone]

#1491956

On Tue, Sep 27, 2016, at 16:16, Nikolay Borisov wrote:
> Dave,
> 
> What's the status of https://patchwork.ozlabs.org/patch/664062/ , is
> this going to be picked up ?

Not sure if we actually fix a bug with this. Miklos could you maybe
enhance the changelog then?

Thanks,
Hannes

[toc] | [prev] | [next] | [standalone]

#1492237

From: Nikolay Borisov <kernel@kyup.com>
Date: Tue, 27 Sep 2016 17:16:27 +0300

> What's the status of https://patchwork.ozlabs.org/patch/664062/ , is
> this going to be picked up ?

Why would I apply a patch that's an RFC, doesn't have a proper commit
message, lacks a proper signoff, and also lacks ACK's and feedback
from other knowledgable developers?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web