Re: possible deadlock in skb_queue_tail

[Dmitry Vyukov]

On Wed, Apr 4, 2018 at 7:08 AM, Cong Wang <xiyou.wangcong@xxxxxxxxx> wrote:
> On Tue, Apr 3, 2018 at 4:42 AM, Kirill Tkhai <ktkhai@xxxxxxxxxxxxx> wrote:
>> On 03.04.2018 14:25, Dmitry Vyukov wrote:
>>> On Tue, Apr 3, 2018 at 11:50 AM, Kirill Tkhai <ktkhai@xxxxxxxxxxxxx> wrote:
>>>> sk_diag_dump_icons() dumps only sockets in TCP_LISTEN state.
>>>> TCP_LISTEN state may be assigned in only place in net/unix/af_unix.c:
>>>> it's unix_listen(). The function is applied to stream and seqpacket
>>>> socket types.
>>>>
>>>> It can't be stream because of the second stack, and seqpacket also can't,
>>>> as I don't think it's possible for gcc to inline unix_seqpacket_sendmsg()
>>>> in the way, we don't see it in the stack.
>>>>
>>>> So, this is looks like false positive result for me.
>>>>
>>>> Kirill
>>>
>>> Do you mean that these &(&u->lock)->rlock/1 referenced in 2 stacks are
>>> always different?
>>
>> In these 2 particular stacks they have to be different.
>
> So actually my patch could fix this false positive? I thought it couldn't.
> https://patchwork.ozlabs.org/patch/894342/

You know better!
If you suspect it can fix this report, and nobody has better
proposals, then we can just mark this as being fixed with your commit
and then see if it triggers again with your commit or not.