lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2025122822-rectangle-wisdom-f775@gregkh>
Date: Sun, 28 Dec 2025 13:54:03 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Sun Jian <sun.jian.kdev@...il.com>
Cc: linux-staging@...ts.linux.dev, Thomas Gleixner <tglx@...utronix.de>,
	Ignacio Pena <ignacio.pena87@...il.com>,
	Bryant Boatright <bryant.boatright@...ton.me>,
	JJ Strnad <strnad.jj@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: rtl8723bs: avoid short msleep duration

On Sun, Dec 28, 2025 at 01:49:02PM +0800, Sun Jian wrote:
> msleep() is documented to sleep for at least the specified
> number of milliseconds, but small values may result in a
> longer delay due to scheduler granularity.
> 
> Replace msleep(10) with msleep(20) to match the effective
> sleep duration and silence checkpatch warning.
> 
> No functional change intended.
> 
> Signed-off-by: Sun Jian <sun.jian.kdev@...il.com>
> ---
>  drivers/staging/rtl8723bs/core/rtw_cmd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c b/drivers/staging/rtl8723bs/core/rtw_cmd.c
> index ef2d92b5588a..0edf9ecc4bed 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_cmd.c
> @@ -215,7 +215,7 @@ void _rtw_free_evt_priv(struct	evt_priv *pevtpriv)
>  {
>  	_cancel_workitem_sync(&pevtpriv->c2h_wk);
>  	while (pevtpriv->c2h_wk_alive)
> -		msleep(10);
> +		msleep(20);

That is very arbritrary, are you sure this is ok?  Why 20?

Just doing this for checkpatch without being able to test and know it
works properly on real hardware is not a good idea.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ