Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753351AbdCNPKA (ORCPT ); Tue, 14 Mar 2017 11:10:00 -0400 Received: from mail-io0-f174.google.com ([209.85.223.174]:35938 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753189AbdCNPJm (ORCPT ); Tue, 14 Mar 2017 11:09:42 -0400 MIME-Version: 1.0 In-Reply-To: <1489503785.2413.10.camel@redhat.com> References: <1489502504.28631.115.camel@edumazet-glaptop3.roam.corp.google.com> <1489503785.2413.10.camel@redhat.com> From: Eric Dumazet Date: Tue, 14 Mar 2017 08:09:40 -0700 Message-ID: Subject: Re: net: deadlock between ip_expire/sch_direct_xmit To: Paolo Abeni Cc: Eric Dumazet , Dmitry Vyukov , David Miller , Cong Wang , Alexey Kuznetsov , James Morris , Hideaki YOSHIFUJI , Patrick McHardy , netdev , LKML , Jamal Hadi Salim , syzkaller Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 585 Lines: 14 On Tue, Mar 14, 2017 at 8:03 AM, Paolo Abeni wrote: > I'm wondering if we really need to keep the fragment queue lock held > while sending the icmp packet ? we hold a reference to the struct, so > it can't be deleted, and AFAICS after ipq_kill() nobody else could > access/modify that queue. > > That lock is there pretty much forever, but perhaps is only a leftover > and we can release it just after ipq_kill() ? Maybe, but for peace of mind I would make sure this code path owns the skb (head) before releasing the lock. Seems something to try for net-next ?