netdev - Re: [Intel-wired-lan] [PATCH v3 0/7 iwl-next] idpf: refactor virtchnl messages

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: <6db9c94a-efd2-446d-a9f0-8cfc7d126f13@intel.com>
Date: Wed, 31 Jan 2024 14:03:14 -0800
From: Alan Brady <alan.brady@...el.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
CC: <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
	<willemdebruijn.kernel@...il.com>, <igor.bagnucki@...el.com>,
	<przemyslaw.kitszel@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH v3 0/7 iwl-next] idpf: refactor virtchnl
 messages

On 1/31/2024 10:33 AM, Alexander Lobakin wrote:
> From: Alan Brady <alan.brady@...el.com>
> Date: Mon, 29 Jan 2024 16:59:16 -0800
>
>> The motivation for this series has two primary goals. We want to enable
>> support of multiple simultaneous messages and make the channel more
>> robust. The way it works right now, the driver can only send and receive
>> a single message at a time and if something goes really wrong, it can
>> lead to data corruption and strange bugs.
> Have you tested v3?
> I have this on my system (net-next + your series), no other patches applied:

Mea culpa I have made a grave error.

We did test the vast majority of change and it was all fine. At last 
minute I noticed it looked like we could clean up idpf_send_mb_msg as 
well. I had confidence in the other changes weren't a problem so this 
seemed innocent to me. I was very wrong. There's some complications here 
with how idpf_mb_clean works that I think need to be worked out 
separately before we can do this change to idpf_send_mb_msg. I would 
like to revert the change to idpf_send_mb_msg I did in v3 and instead 
investigate it further in a follow up series that attempts to address 
all cases where automatic variables would be a good idea. Apologies and 
thanks.

-Alan

> [...]
>
> Thanks,
> Olek