From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiaomeng Tong Date: Thu, 3 Mar 2022 10:27:29 +0800 Subject: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr In-Reply-To: <1077f17e50d34dc2bbfdf4e52a1cb2fd@AcuMS.aculab.com> References: <1077f17e50d34dc2bbfdf4e52a1cb2fd@AcuMS.aculab.com> Message-ID: <20220303022729.9321-1-xiam0nd.tong@gmail.com> List-Id: To: linux-aspeed@lists.ozlabs.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, 2 Mar 2022 14:04:06 +0000, David Laight wrote: > I think that it would be better to make any alternate loop macro > just set the variable to NULL on the loop exit. > That is easier to code for and the compiler might be persuaded to > not redo the test. No, that would lead to a NULL dereference. The problem is the mis-use of iterator outside the loop on exit, and the iterator will be the HEAD's container_of pointer which pointers to a type-confused struct. Sidenote: The *mis-use* here refers to mistakely access to other members of the struct, instead of the list_head member which acutally is the valid HEAD. IOW, you would dereference a (NULL + offset_of_member) address here. Please remind me if i missed something, thanks. > OTOH there may be alternative definitions that can be used to get > the compiler (or other compiler-like tools) to detect broken code. > Even if the definition can't possibly generate a working kerrnel. The "list_for_each_entry_inside(pos, type, head, member)" way makes the iterator invisiable outside the loop, and would be catched by compiler if use-after-loop things happened. Can you share your "alternative definitions" details? thanks! -- Xiaomeng Tong