linux-kernel - RE: [PATCH] wifi: rtw88: reduce failed to flush queue severity

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <d03e8c066a6e464aa61badb252c32b01@realtek.com>
Date: Tue, 16 Apr 2024 02:57:57 +0000
From: Ping-Ke Shih <pkshih@...ltek.com>
To: Lewis Robbins <lewis.robbins2@...il.com>,
        "kvalo@...nel.org"
	<kvalo@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
Subject: RE: [PATCH] wifi: rtw88: reduce failed to flush queue severity

Lewis Robbins <lewis.robbins2@...il.com> wrote:
> 
> Ping-Ke Shih <pkshih@...ltek.com> writes:
> 
> > Lewis Robbins <lewis.robbins2@...il.com> wrote:
> >>
> >> Reduce the log message severity when we fail to flush device priority
> >> queue. If a system has a lot of traffic, we may fail to flush the queue
> >> in time. This generates a lot of messages in the kernel ring buffer. As
> >> this is a common occurrence, we should use dev_info instead of dev_warn.
> >>
> >> Signed-off-by: Lewis Robbins <lewis.robbins2@...il.com>
> >
> > Acked-by: Ping-Ke Shih <pkshih@...ltek.com>
> >
> > I'd like to know situations of " If a system has a lot of traffic...".
> > Did you scan or do something during traffic?
> 
> So, after digging a bit more, it seems you're right this only happens during a
> scan. The log message itself is repeated about 5-10x.

That is the same as my test before. 

> 
> I'm not sure as to the cause. If the flush operation takes a long time do we
> need to release any mutexes etc? And if this is just a hardware issue, then we
> can do a debug print as you say.

The cause is because packets in hardware TX queue that can't be sent out in time,
and flush ops with 'drop = false', so driver throws one warning. I don't have
good idea for now. Maybe, we can add a special debug mask to replace this kind of
verbose warning with uncertain solution.