From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: network dev <netdev@vger.kernel.org>,
linux-sctp@vger.kernel.org, davem@davemloft.net,
Neil Horman <nhorman@tuxdriver.com>
Subject: Re: [PATCH net] sctp: avoid running the sctp state machine recursively
Date: Mon, 29 Apr 2019 11:53:36 +0000 [thread overview]
Message-ID: <20190429115336.GF13306@localhost.localdomain> (raw)
In-Reply-To: <3a5d5e96521a5f53ed36ca85219294c34be7d0ef.1556518579.git.lucien.xin@gmail.com>
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:
> <IRQ> [<ffffffffa4375904>] dump_stack+0x19/0x1b
> [<ffffffffa436fcaf>] __schedule_bug+0x64/0x72
> [<ffffffffa437b93a>] __schedule+0x9ba/0xa00
> [<ffffffffa3cd5326>] __cond_resched+0x26/0x30
> [<ffffffffa437bc4a>] _cond_resched+0x3a/0x50
> [<ffffffffa3e22be8>] kmem_cache_alloc_node+0x38/0x200
> [<ffffffffa423512d>] __alloc_skb+0x5d/0x2d0
> [<ffffffffc0995320>] sctp_packet_transmit+0x610/0xa20 [sctp]
> [<ffffffffc098510e>] sctp_outq_flush+0x2ce/0xc00 [sctp]
> [<ffffffffc098646c>] sctp_outq_uncork+0x1c/0x20 [sctp]
> [<ffffffffc0977338>] sctp_cmd_interpreter.isra.22+0xc8/0x1460 [sctp]
> [<ffffffffc0976ad1>] sctp_do_sm+0xe1/0x350 [sctp]
> [<ffffffffc099443d>] sctp_primitive_ASCONF+0x3d/0x50 [sctp]
> [<ffffffffc0977384>] sctp_cmd_interpreter.isra.22+0x114/0x1460 [sctp]
> [<ffffffffc0976ad1>] sctp_do_sm+0xe1/0x350 [sctp]
> [<ffffffffc097b3a4>] sctp_assoc_bh_rcv+0xf4/0x1b0 [sctp]
> [<ffffffffc09840f1>] sctp_inq_push+0x51/0x70 [sctp]
> [<ffffffffc099732b>] 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 <yinxu@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: network dev <netdev@vger.kernel.org>,
linux-sctp@vger.kernel.org, davem@davemloft.net,
Neil Horman <nhorman@tuxdriver.com>
Subject: Re: [PATCH net] sctp: avoid running the sctp state machine recursively
Date: Mon, 29 Apr 2019 08:53:36 -0300 [thread overview]
Message-ID: <20190429115336.GF13306@localhost.localdomain> (raw)
In-Reply-To: <3a5d5e96521a5f53ed36ca85219294c34be7d0ef.1556518579.git.lucien.xin@gmail.com>
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:
> <IRQ> [<ffffffffa4375904>] dump_stack+0x19/0x1b
> [<ffffffffa436fcaf>] __schedule_bug+0x64/0x72
> [<ffffffffa437b93a>] __schedule+0x9ba/0xa00
> [<ffffffffa3cd5326>] __cond_resched+0x26/0x30
> [<ffffffffa437bc4a>] _cond_resched+0x3a/0x50
> [<ffffffffa3e22be8>] kmem_cache_alloc_node+0x38/0x200
> [<ffffffffa423512d>] __alloc_skb+0x5d/0x2d0
> [<ffffffffc0995320>] sctp_packet_transmit+0x610/0xa20 [sctp]
> [<ffffffffc098510e>] sctp_outq_flush+0x2ce/0xc00 [sctp]
> [<ffffffffc098646c>] sctp_outq_uncork+0x1c/0x20 [sctp]
> [<ffffffffc0977338>] sctp_cmd_interpreter.isra.22+0xc8/0x1460 [sctp]
> [<ffffffffc0976ad1>] sctp_do_sm+0xe1/0x350 [sctp]
> [<ffffffffc099443d>] sctp_primitive_ASCONF+0x3d/0x50 [sctp]
> [<ffffffffc0977384>] sctp_cmd_interpreter.isra.22+0x114/0x1460 [sctp]
> [<ffffffffc0976ad1>] sctp_do_sm+0xe1/0x350 [sctp]
> [<ffffffffc097b3a4>] sctp_assoc_bh_rcv+0xf4/0x1b0 [sctp]
> [<ffffffffc09840f1>] sctp_inq_push+0x51/0x70 [sctp]
> [<ffffffffc099732b>] 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 <yinxu@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
next prev parent reply other threads:[~2019-04-29 11:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-29 6:16 [PATCH net] sctp: avoid running the sctp state machine recursively Xin Long
2019-04-29 6:16 ` Xin Long
2019-04-29 11:21 ` Neil Horman
2019-04-29 11:21 ` Neil Horman
2019-04-29 11:53 ` Marcelo Ricardo Leitner [this message]
2019-04-29 11:53 ` Marcelo Ricardo Leitner
2019-05-01 13:19 ` David Miller
2019-05-01 13:19 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190429115336.GF13306@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=davem@davemloft.net \
--cc=linux-sctp@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.