From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751891AbeEMQCa (ORCPT ); Sun, 13 May 2018 12:02:30 -0400 Received: from mail-qk0-f193.google.com ([209.85.220.193]:46198 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751489AbeEMQC2 (ORCPT ); Sun, 13 May 2018 12:02:28 -0400 X-Google-Smtp-Source: AB8JxZolO4Fu0DwcjS4S9shxLdQ/CEk6c9NaqvgnH+HEuYMg+BdxPimTEz8peDfhUw0qUQS8y84Phw== Date: Sun, 13 May 2018 13:02:23 -0300 From: Marcelo Ricardo Leitner To: Dmitry Vyukov Cc: Eric Dumazet , syzbot , Vladislav Yasevich , Neil Horman , linux-sctp@vger.kernel.org, Andrei Vagin , David Miller , Kirill Tkhai , LKML , netdev , syzkaller-bugs Subject: Re: INFO: rcu detected stall in kfree_skbmem Message-ID: <20180513160223.GR4977@localhost.localdomain> References: <000000000000a9b0e3056b14bfb2@google.com> <20180511184141.GW5105@localhost.localdomain> <683d1ead-d35b-27ee-0f0c-f7e815d989fc@gmail.com> <20180511204228.GO4977@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 13, 2018 at 03:52:01PM +0200, Dmitry Vyukov wrote: > On Fri, May 11, 2018 at 10:42 PM, Marcelo Ricardo Leitner > wrote: > > On Fri, May 11, 2018 at 12:08:33PM -0700, Eric Dumazet wrote: > >> > >> > >> On 05/11/2018 11:41 AM, Marcelo Ricardo Leitner wrote: > >> > >> > But calling ip6_xmit with rcu_read_lock is expected. tcp stack also > >> > does it. > >> > Thus I think this is more of an issue with IPv6 stack. If a host has > >> > an extensive ip6tables ruleset, it probably generates this more > >> > easily. > >> > > >> >>> sctp_v6_xmit+0x4a5/0x6b0 net/sctp/ipv6.c:225 > >> >>> sctp_packet_transmit+0x26f6/0x3ba0 net/sctp/output.c:650 > >> >>> sctp_outq_flush+0x1373/0x4370 net/sctp/outqueue.c:1197 > >> >>> sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776 > >> >>> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline] > >> >>> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline] > >> >>> sctp_do_sm+0x596/0x7160 net/sctp/sm_sideeffect.c:1191 > >> >>> sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406 > >> >>> call_timer_fn+0x230/0x940 kernel/time/timer.c:1326 > >> >>> expire_timers kernel/time/timer.c:1363 [inline] > >> > > >> > Having this call from a timer means it wasn't processing sctp stack > >> > for too long. > >> > > >> > >> I feel the problem is that this part is looping, in some infinite loop. > >> > >> I have seen this stack traces in other reports. > > > > Checked mail history now, seems at least two other reports on RCU > > stalls had sctp_generate_heartbeat_event involved. > > > >> > >> Maybe some kind of list corruption. > > > > Could be. > > Do we know if it generated a flood of packets? > > We only know what's in the bug reports. Do the other ones have Ok. > reproducers? It can make sense to mark them as duplicates to not have No. > a placer of open bugs about the same root cause. They may have the same root cause, but right now I cannot tell for sure.