From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752013AbeDDTAm (ORCPT ); Wed, 4 Apr 2018 15:00:42 -0400 Received: from mail-pl0-f47.google.com ([209.85.160.47]:40555 "EHLO mail-pl0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751946AbeDDTAh (ORCPT ); Wed, 4 Apr 2018 15:00:37 -0400 X-Google-Smtp-Source: AIpwx4+tjded2WpZeyMounFWwep6RJGJ07GrFlnJGzvJD+F1S3Cxm+tv1uG5OUr4k2EUAcL8c5flWA/QBDLE+45hb4I= MIME-Version: 1.0 In-Reply-To: References: <0000000000003584570568da18dd@google.com> <06c79d3f-3f28-7f1e-9431-66c18149c9e6@virtuozzo.com> <0eb5ed24-012a-89c9-bac9-796a0276221a@virtuozzo.com> From: Dmitry Vyukov Date: Wed, 4 Apr 2018 21:00:16 +0200 Message-ID: Subject: Re: possible deadlock in skb_queue_tail To: Cong Wang Cc: Kirill Tkhai , Ingo Molnar , syzbot , David Miller , David Herrmann , Denys Vlasenko , David Windsor , "Reshetova, Elena" , Hans Liljestrand , Kees Cook , LKML , Matthew Dawson , Mateusz Jurczyk , netdev , syzkaller-bugs@googlegroups.com, Al Viro , xemul@virtuozzo.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 4, 2018 at 7:08 AM, Cong Wang wrote: > On Tue, Apr 3, 2018 at 4:42 AM, Kirill Tkhai wrote: >> On 03.04.2018 14:25, Dmitry Vyukov wrote: >>> On Tue, Apr 3, 2018 at 11:50 AM, Kirill Tkhai 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.