From: Brady, Alan <alan.br...@intel.com> Date: Mon, 29 Jan 2024 16:12:06 +0100
>> -----Original Message----- >> From: Lobakin, Aleksander <aleksander.loba...@intel.com> >> Sent: Monday, January 29, 2024 5:24 AM >> To: Brady, Alan <alan.br...@intel.com> >> Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; >> willemdebruijn.ker...@gmail.com; Bagnucki, Igor >> <igor.bagnu...@intel.com>; Kitszel, Przemyslaw >> <przemyslaw.kits...@intel.com> >> Subject: Re: [Intel-wired-lan] [PATCH v2 0/7 iwl-next] idpf: refactor >> virtchnl >> messages >> >> From: Alan Brady <alan.br...@intel.com> >> Date: Thu, 25 Jan 2024 21:47:40 -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. >> >> [...] >> >> There are a fistful of functions in this series and IDPF's virtchnl code in >> general >> that allocate a memory chunk via kzalloc() family and then free it at the >> end of >> the function, i.e. the lifetime of those buffers are the lifetime of the >> function. >> Since recently, we have auto-variables in the kernel, so that the pieces I >> described could be converted to: >> >> struct x *ptr __free(kfree) = NULL; >> >> ptr = kzalloc(sizeof(*x), GPF_KERNEL); >> >> // some code >> >> return 0; // kfree() is not needed anymore >> >> err: >> return err; // here as well >> >> That would allow to simplify the code and reduce its size. >> I'd like you to convert such functions to use auto-variables. > > Certainly, should be straightforward and make the code much better, sounds > good to me. Just to clarify I'm only going to mess with the virtchnl > functions I've otherwise altered in this patch series to maintain appropriate > scope, yes? Yes, only virtchnl functions. New functions that you introduce 100%, the rest only if you touch them. > > -Alan > >> >> Thanks, >> Olek Thanks, Olek
