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:   Thu, 20 Oct 2022 17:46:47 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Duoming Zhou <duoming@zju.edu.cn>
Cc:     linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
        Larry.Finger@lwfinger.net, phil@philpotter.co.uk,
        paskripkin@gmail.com, martin@kaiser.cx, straube.linux@gmail.com,
        kuba@kernel.org
Subject: Re: [PATCH] drivers: staging: r8188eu: Fix sleep-in-atomic-context
 bug in rtw_join_timeout_handler
Message-ID: <Y1FtZzV9wRQRaTYk@kroah.com>
References: <20221018083424.79741-1-duoming@zju.edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221018083424.79741-1-duoming@zju.edu.cn>
Precedence: bulk

On Tue, Oct 18, 2022 at 04:34:24PM +0800, Duoming Zhou wrote:
> The rtw_join_timeout_handler() is a timer handler that
> runs in atomic context, but it could call msleep().
> As a result, the sleep-in-atomic-context bug will happen.
> The process is shown below:
> 
>      (atomic context)
> rtw_join_timeout_handler

Wait, how is this an atomic timeout?

When can that happen?

>  _rtw_join_timeout_handler
>   rtw_do_join
>    rtw_select_and_join_from_scanned_queue
>     rtw_indicate_disconnect
>      rtw_lps_ctrl_wk_cmd
>       lps_ctrl_wk_hdl
>        LPS_Leave
>         LPS_RF_ON_check
>          msleep //sleep in atomic context

How was this found?

> Fix by removing msleep() and replacing with mdelay().

Wouldn't people have seen an error already if msleep() was really called
in atomic context?

And what about the other drivers that have this identical code, why only
fix one?

thanks,

greg k-h