Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 24 Jul 2022 10:13:18 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To:     Duoming Zhou <duoming@zju.edu.cn>
Cc:     linux-sctp@vger.kernel.org, vyasevich@gmail.com,
        nhorman@tuxdriver.com, davem@davemloft.net, edumazet@google.com,
        kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] sctp: fix sleep in atomic context bug in timer
 handlers
Message-ID: <Yt1Fbv9t/BBeYe1Z@t14s.localdomain>
References: <20220723015809.11553-1-duoming@zju.edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220723015809.11553-1-duoming@zju.edu.cn>
Precedence: bulk

Hi,

On Sat, Jul 23, 2022 at 09:58:09AM +0800, Duoming Zhou wrote:
> There are sleep in atomic context bugs in timer handlers of sctp
> such as sctp_generate_t3_rtx_event(), sctp_generate_probe_event(),
> sctp_generate_t1_init_event(), sctp_generate_timeout_event(),
> sctp_generate_t3_rtx_event() and so on.
> 
> The root cause is sctp_sched_prio_init_sid() with GFP_KERNEL parameter
> that may sleep could be called by different timer handlers which is in
> interrupt context.
> 
> One of the call paths that could trigger bug is shown below:
> 
>       (interrupt context)
> sctp_generate_probe_event
>   sctp_do_sm
>     sctp_side_effects
>       sctp_cmd_interpreter
>         sctp_outq_teardown
>           sctp_outq_init

This sequence is odd but it is used when handling dup cookies. It
tears down whatever was in there and re-inits it. With that,

Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

>             sctp_sched_set_sched
>               n->init_sid(..,GFP_KERNEL)
>                 sctp_sched_prio_init_sid //may sleep