[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 3 Mar 2022 10:27:29 +0800
From: Xiaomeng Tong <xiam0nd.tong@...il.com>
To: david.laight@...lab.com
Cc: akpm@...ux-foundation.org, alsa-devel@...a-project.org,
amd-gfx@...ts.freedesktop.org, andriy.shevchenko@...ux.intel.com,
arnd@...db.de, bcm-kernel-feedback-list@...adcom.com,
bjohannesmeyer@...il.com, c.giuffrida@...nl,
christian.koenig@....com, christophe.jaillet@...adoo.fr,
dan.carpenter@...cle.com, dmaengine@...r.kernel.org,
drbd-dev@...ts.linbit.com, dri-devel@...ts.freedesktop.org,
gustavo@...eddedor.com, h.j.bos@...nl,
intel-gfx@...ts.freedesktop.org, intel-wired-lan@...ts.osuosl.org,
jakobkoschel@...il.com, jgg@...pe.ca, keescook@...omium.org,
kgdb-bugreport@...ts.sourceforge.net, kvm@...r.kernel.org,
linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-aspeed@...ts.ozlabs.org, linux-block@...r.kernel.org,
linux-cifs@...r.kernel.org, linux-crypto@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net,
linux-fsdevel@...r.kernel.org, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
linux-mediatek@...ts.infradead.org, linux-pm@...r.kernel.org,
linux-rdma@...r.kernel.org, linux-scsi@...r.kernel.org,
linux-sgx@...r.kernel.org, linux-staging@...ts.linux.dev,
linux-tegra@...r.kernel.org, linux-usb@...r.kernel.org,
linux-wireless@...r.kernel.org,
linux1394-devel@...ts.sourceforge.net, linux@...musvillemoes.dk,
linuxppc-dev@...ts.ozlabs.org, nathan@...nel.org,
netdev@...r.kernel.org, nouveau@...ts.freedesktop.org,
rppt@...nel.org, samba-technical@...ts.samba.org,
tglx@...utronix.de, tipc-discussion@...ts.sourceforge.net,
torvalds@...ux-foundation.org,
v9fs-developer@...ts.sourceforge.net, xiam0nd.tong@...il.com
Subject: RE: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Wed, 2 Mar 2022 14:04:06 +0000, David Laight
<David.Laight@...LAB.COM> 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
Powered by blists - more mailing lists