linux-kernel - Re: [RESEND. PATCH] mt76: mt76u_vendor_request: Do not print error messages when -EPROTO

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: <531681bd-30f5-4a70-a156-bf8754b8e072@intel.com>
Date: Thu, 19 Dec 2024 16:23:02 +0100
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: WangYuli <wangyuli@...ontech.com>
CC: <nbd@....name>, <lorenzo@...nel.org>, <ryder.lee@...iatek.com>,
	<shayne.chen@...iatek.com>, <sean.wang@...iatek.com>, <kvalo@...nel.org>,
	<matthias.bgg@...il.com>, <angelogioacchino.delregno@...labora.com>,
	<davem@...emloft.net>, <andrew+netdev@...n.ch>, <edumazet@...gle.com>,
	<kuba@...nel.org>, <pabeni@...hat.com>, <alexander.deucher@....com>,
	<gregkh@...uxfoundation.org>, <rodrigo.vivi@...el.com>,
	<linux-wireless@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-mediatek@...ts.infradead.org>,
	<raoxu@...ontech.com>, <guanwentao@...ontech.com>, <zhanjun@...ontech.com>,
	<cug_yangyuancong@...mail.com>, <lorenzo.bianconi@...hat.com>,
	<kvalo@...eaurora.org>, <sidhayn@...il.com>, <lorenzo.bianconi83@...il.com>,
	<sgruszka@...hat.com>, <keescook@...omium.org>, <markus.theil@...ilmenau.de>,
	<gustavoars@...nel.org>, <stf_xl@...pl>, <romain.perier@...il.com>,
	<apais@...ux.microsoft.com>, <mrkiko.rs@...il.com>, <oliver@...kum.org>,
	<woojung.huh@...rochip.com>, <helmut.schaa@...glemail.com>,
	<mailhol.vincent@...adoo.fr>, <dokyungs@...sei.ac.kr>,
	<deren.wu@...iatek.com>, <daniel@...rotopia.org>, <sujuan.chen@...iatek.com>,
	<mikhail.v.gavrilov@...il.com>, <stern@...land.harvard.edu>,
	<linux-usb@...r.kernel.org>, <leitao@...ian.org>, <dsahern@...nel.org>,
	<weiwan@...gle.com>, <netdev@...r.kernel.org>, <horms@...nel.org>,
	<andrew@...n.ch>, <leit@...com>, <wang.zhao@...iatek.com>,
	<chui-hao.chiu@...iatek.com>, <lynxis@...0.eu>, <mingyen.hsieh@...iatek.com>,
	<yn.chen@...iatek.com>, <quan.zhou@...iatek.com>, <dzm91@...t.edu.cn>,
	<gch981213@...il.com>, <git@...nap.io>, <jiefeng_li@...t.edu.cn>,
	<nelson.yu@...iatek.com>, <rong.yan@...iatek.com>, <Bo.Jiao@...iatek.com>,
	<StanleyYP.Wang@...iatek.com>
Subject: Re: [RESEND. PATCH] mt76: mt76u_vendor_request: Do not print error
 messages when -EPROTO

From: Wangyuli <wangyuli@...ontech.com>
Date: Thu, 19 Dec 2024 15:11:24 +0800

> On 2024/12/19 00:10, Alexander Lobakin wrote:
> 
>> Is it a fix or an improvement?
>> You need to specify the target tree, either 'PATCH net' (fixes) or
>> 'PATCH net-next' (improvements).
>  It is a fix not an improvement.

So you need to add the correct tree and/or subject prefix and specify
"Fixes:" tag with the commit this change fixes.

>> How do other drivers handle this?
>> Can -EPROTO happen in other cases, not only unplugging, which this patch
>> would break?
>>
> When initializing the network card, unplugging the device will trigger
> an -EPROTO error.
> 
> The exception is printed as follows：
> 
>         
>         mt76x2u 2-2.4:1.0: vendor request req:47 off:9018 failed:-71
>         mt76x2u 2-2.4:1.0: vendor request req:47 off:9018 failed:-71
>         ...
>         
> 
> It will continue to print more than 2000 times for about 5 minutes,
> causing the usb device to be unable to be disconnected.  During this
> period, the usb port cannot recognize the new device because the old
> device has not disconnected.
> 
> There may be other operating methods that cause -EPROTO, but -EPROTO is
> a low-level hardware error. It is unwise to repeat vendor requests
> expecting to read correct data. It is a better choice to treat -EPROTO
> and -ENODEV the same way.
> 
> Similar to commit （mt76: usb: process URBs with status EPROTO
> properly）do no schedule rx_worker for urb marked with status set -
> EPROTO. I also reproduced this situation when plugging and unplugging
> the device, and this patch is effective.

I'm not a wireless expert, from my PoV sounds good. Just describe
everything in details in the commit message, so that it will be clear
for everyone.

> 
> Just do not vendor request again for urb marked with status set -EPROTO .
> 
> 
> Thanks,
> 
> -- 
> WangYuli

Thanks,
Olek