[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0f400bb9-03a7-431a-95c3-340bb3e10614@linux.microsoft.com>
Date: Fri, 17 Jan 2025 11:14:04 -0800
From: Roman Kisel <romank@...ux.microsoft.com>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>,
Jakub Kicinski <kuba@...nel.org>
Cc: Thorsten Blum <thorsten.blum@...ux.dev>,
"K. Y. Srinivasan" <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>, Wei Liu <wei.liu@...nel.org>,
Dexuan Cui <decui@...rosoft.com>, Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>, linux-hardening@...r.kernel.org,
linux-hyperv@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] hv_netvsc: Replace one-element array with flexible
array member
On 1/17/2025 3:10 AM, Przemek Kitszel wrote:
> On 1/17/25 01:17, Jakub Kicinski wrote:
>> On Thu, 16 Jan 2025 13:39:52 -0800 Roman Kisel wrote:
>>> On 1/16/2025 1:19 PM, Thorsten Blum wrote:
>>>> Replace the deprecated one-element array with a modern flexible array
>>>> member in the struct nvsp_1_message_send_receive_buffer_complete.
>>>>
>>>> Use struct_size_t(,,1) instead of sizeof() to maintain the same size.
>
> I would add a struct-specific macro or at least put the info into this
> struct' doc, that "there is legacy API requirement to allocate at least
> one element for the flex array member".
>
Perhaps add "No functional changes", too.
Worked for me.
Tested-by: Roman Kisel <romank@...ux.microsoft.com>
Reviewed-by: Roman Kisel <romank@...ux.microsoft.com>
>>>
>>> Thanks!
>>>
>>>>
>>>> Compile-tested only.
>>>
>>> The code change looks good to me now. I'll build a VM with this change
>>> to clear my conscience (maybe the change triggers a compiler bug,
>>> however unlikely that sounds) before replying with any tags. Likely next
>>> Monday, but feel free to beat me to it, or perhaps, someone else will
>>> tag this as reviewed by them and/or tested by them.
>>
>> Doesn't look like a real bug fix, so would be good to get some signal
>
> If the actual usage would be with more than 1 element UBSAN will
> complain.
Great point!
>
>> soon. The merge window is soon so we'll likely close the trees very
>> very soon ..
>>
>
--
Thank you,
Roman
Powered by blists - more mailing lists