linux-kernel - Re: [PATCH v5 1/3] staging: rtl8723bs: change return type of _rtw_pktfile

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

Message-ID: <aXIkvw2bVfQwpqWF@JMW-Ubuntu>
Date: Thu, 22 Jan 2026 22:23:11 +0900
From: Minu Jin <s9430939@...er.com>
To: dan.carpenter@...aro.org
Cc: gregkh@...uxfoundation.org, andriy.shevchenko@...ux.intel.com,
	abrahamadekunle50@...il.com, zxcv2569763104@...il.com,
	milospuric856@...il.com, karanja99erick@...il.com,
	weibu@...admin.org, linux-staging@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/3] staging: rtl8723bs: change return type of
 _rtw_pktfile_read to int

Hi Dan,

Thanks for the feedback.
I'll drop the type-change patch and reorganize the series
into two patches for v6 as you suggested.

Regarding the return type,
I’ve audited the call sites including set_qos(), update_attrib(),
and rtw_xmitframe_coalesce(), along with their callers rtw_xmit() and xmit_frames().

Since these functions handle errors immediately and exit,
I initially thought a negative return value would be safe.

I'm curious if I missed a specific scenario in the current code,
or if your advice is more about general defensive programming—such as avoiding
future risks like implicit casting or pointer arithmetic issues.

I’d appreciate your insight on this
so I can better understand the preferred approach in the kernel.

Best regards

Minu Jin