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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 31 Mar 2022 10:58:55 -0700 From: Vinicius Costa Gomes <vinicius.gomes@...el.com> To: Jakob Koschel <jakobkoschel@...il.com> Cc: Jamal Hadi Salim <jhs@...atatu.com>, Cong Wang <xiyou.wangcong@...il.com>, Jiri Pirko <jiri@...nulli.us>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Netdev <netdev@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Mike Rapoport <rppt@...nel.org>, Brian Johannesmeyer <bjohannesmeyer@...il.com>, Cristiano Giuffrida <c.giuffrida@...nl>, "Bos, H.J." <h.j.bos@...nl> Subject: Re: [PATCH] taprio: replace usage of found with dedicated list iterator variable Jakob Koschel <jakobkoschel@...il.com> writes: >> On 31. Mar 2022, at 01:15, Vinicius Costa Gomes <vinicius.gomes@...el.com> wrote: >> >> Hi, >> >> Jakob Koschel <jakobkoschel@...il.com> writes: >> >>> To move the list iterator variable into the list_for_each_entry_*() >>> macro in the future it should be avoided to use the list iterator >>> variable after the loop body. >>> >>> To *never* use the list iterator variable after the loop it was >>> concluded to use a separate iterator variable instead of a >>> found boolean [1]. >>> >>> This removes the need to use a found variable and simply checking if >>> the variable was set, can determine if the break/goto was hit. >>> >>> Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ >>> Signed-off-by: Jakob Koschel <jakobkoschel@...il.com> >>> --- >> >> Code wise, patch look good. >> >> Just some commit style/meta comments: >> - I think that it would make more sense that these were two separate >> patches, but I haven't been following the fallout of the discussion >> above to know what other folks are doing; > > Thanks for the input, I'll split them up. > >> - Please use '[PATCH net-next]' in the subject prefix of your patch(es) >> when you next propose this (net-next is closed for new submissions for >> now, it should open again in a few days); > > I'll include that prefix, thanks. > > Paolo Abeni [CC'd] suggested to bundle all net-next patches in one series [1]. > If that's the general desire I'm happy to do that. I agree with that, having one series for the whole net-next is going to be easier for everyone. Cheers, -- Vinicius
Powered by blists - more mailing lists