From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA9A5C43219 for ; Mon, 29 Apr 2019 11:22:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 890542087B for ; Mon, 29 Apr 2019 11:22:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727970AbfD2LWN (ORCPT ); Mon, 29 Apr 2019 07:22:13 -0400 Received: from charlotte.tuxdriver.com ([70.61.120.58]:36906 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727710AbfD2LWM (ORCPT ); Mon, 29 Apr 2019 07:22:12 -0400 Received: from cpe-2606-a000-111b-405a-0-0-0-162e.dyn6.twc.com ([2606:a000:111b:405a::162e] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1hL4MC-0005tc-Kv; Mon, 29 Apr 2019 07:22:07 -0400 Date: Mon, 29 Apr 2019 07:21:31 -0400 From: Neil Horman To: Xin Long Cc: network dev , linux-sctp@vger.kernel.org, davem@davemloft.net, Marcelo Ricardo Leitner Subject: Re: [PATCH net] sctp: avoid running the sctp state machine recursively Message-ID: <20190429112131.GA18158@hmswarspite.think-freely.org> References: <3a5d5e96521a5f53ed36ca85219294c34be7d0ef.1556518579.git.lucien.xin@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a5d5e96521a5f53ed36ca85219294c34be7d0ef.1556518579.git.lucien.xin@gmail.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Apr 29, 2019 at 02:16:19PM +0800, Xin Long wrote: > Ying triggered a call trace when doing an asconf testing: > > BUG: scheduling while atomic: swapper/12/0/0x10000100 > Call Trace: > [] dump_stack+0x19/0x1b > [] __schedule_bug+0x64/0x72 > [] __schedule+0x9ba/0xa00 > [] __cond_resched+0x26/0x30 > [] _cond_resched+0x3a/0x50 > [] kmem_cache_alloc_node+0x38/0x200 > [] __alloc_skb+0x5d/0x2d0 > [] sctp_packet_transmit+0x610/0xa20 [sctp] > [] sctp_outq_flush+0x2ce/0xc00 [sctp] > [] sctp_outq_uncork+0x1c/0x20 [sctp] > [] sctp_cmd_interpreter.isra.22+0xc8/0x1460 [sctp] > [] sctp_do_sm+0xe1/0x350 [sctp] > [] sctp_primitive_ASCONF+0x3d/0x50 [sctp] > [] sctp_cmd_interpreter.isra.22+0x114/0x1460 [sctp] > [] sctp_do_sm+0xe1/0x350 [sctp] > [] sctp_assoc_bh_rcv+0xf4/0x1b0 [sctp] > [] sctp_inq_push+0x51/0x70 [sctp] > [] sctp_rcv+0xa8b/0xbd0 [sctp] > > As it shows, the first sctp_do_sm() running under atomic context (NET_RX > softirq) invoked sctp_primitive_ASCONF() that uses GFP_KERNEL flag later, > and this flag is supposed to be used in non-atomic context only. Besides, > sctp_do_sm() was called recursively, which is not expected. > > Vlad tried to fix this recursive call in Commit c0786693404c ("sctp: Fix > oops when sending queued ASCONF chunks") by introducing a new command > SCTP_CMD_SEND_NEXT_ASCONF. But it didn't work as this command is still > used in the first sctp_do_sm() call, and sctp_primitive_ASCONF() will > be called in this command again. > > To avoid calling sctp_do_sm() recursively, we send the next queued ASCONF > not by sctp_primitive_ASCONF(), but by sctp_sf_do_prm_asconf() in the 1st > sctp_do_sm() directly. > > Reported-by: Ying Xu > Signed-off-by: Xin Long > --- > include/net/sctp/command.h | 1 - > net/sctp/sm_sideeffect.c | 29 ----------------------------- > net/sctp/sm_statefuns.c | 35 +++++++++++++++++++++++++++-------- > 3 files changed, 27 insertions(+), 38 deletions(-) > Acked-by: Neil Horman