| Message ID | 20220228110822.491923-3-jakobkoschel@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/6] drivers: usb: remove usage of list iterator past the loop body | expand |
On Mon, Feb 28, 2022 at 4:38 PM Segher Boessenkool <segher@kernel.crashing.org> wrote: > > In C its scope is the rest of the declaration and the entire loop, not > anything after it. This was the same in C++98 already, btw (but in > pre-standard versions of C++ things were like you remember, yes, and it > was painful). Yeah, the original C++ model was just unadulterated garbage, with no excuse for it, and the scope was not the loop, but the block the loop existed in. That would never have been acceptable for the kernel - it's basically just an even uglier version of "put variable declarations in the middle of code" (and we use "-Wdeclaration-after-statement" to disallow that for kernel code, although apparently some of our user space tooling code doesn't enforce or follow that rule). The actual C99 version is the sane one which actually makes it easier and clearer to have loop iterators that are clearly just in loop scope. That's a good idea in general, and I have wanted to start using that in the kernel even aside from some of the loop construct macros. Because putting variables in natural minimal scope is a GoodThing(tm). Of course, we shouldn't go crazy with it. Even after we do that -std=gnu11 thing, we'll have backports to worry about. And it's not clear that we necessarily want to backport that gnu11 thing - since people who run old stable kernels also may be still using those really old compilers... Linus
From: Linus Torvalds > Sent: 28 February 2022 19:56 > On Mon, Feb 28, 2022 at 4:19 AM Christian König > <christian.koenig@amd.com> wrote: > > > > I don't think that using the extra variable makes the code in any way > > more reliable or easier to read. > > So I think the next step is to do the attached patch (which requires > that "-std=gnu11" that was discussed in the original thread). > > That will guarantee that the 'pos' parameter of list_for_each_entry() > is only updated INSIDE the for_each_list_entry() loop, and can never > point to the (wrongly typed) head entry. > > And I would actually hope that it should actually cause compiler > warnings about possibly uninitialized variables if people then use the > 'pos' pointer outside the loop. Except > > (a) that code in sgx/encl.c currently initializes 'tmp' to NULL for > inexplicable reasons - possibly because it already expected this > behavior > > (b) when I remove that NULL initializer, I still don't get a warning, > because we've disabled -Wno-maybe-uninitialized since it results in so > many false positives. > > Oh well. > > Anyway, give this patch a look, and at least if it's expanded to do > "(pos) = NULL" in the entry statement for the for-loop, it will avoid > the HEAD type confusion that Jakob is working on. And I think in a > cleaner way than the horrid games he plays. > > (But it won't avoid possible CPU speculation of such type confusion. > That, in my opinion, is a completely different issue) > > I do wish we could actually poison the 'pos' value after the loop > somehow - but clearly the "might be uninitialized" I was hoping for > isn't the way to do it. > > Anybody have any ideas? > > Linus diff --git a/include/linux/list.h b/include/linux/list.h index dd6c2041d09c..bab995596aaa 100644 --- a/include/linux/list.h +++ b/include/linux/list.h @@ -634,10 +634,10 @@ static inline void list_splice_tail_init(struct list_head *list, * @head: the head for your list. * @member: the name of the list_head within the struct. */ -#define list_for_each_entry(pos, head, member) \ - for (pos = list_first_entry(head, typeof(*pos), member); \ - !list_entry_is_head(pos, head, member); \ - pos = list_next_entry(pos, member)) +#define list_for_each_entry(pos, head, member) \ + for (typeof(pos) __iter = list_first_entry(head, typeof(*pos), member); \ + !list_entry_is_head(__iter, head, member) && (((pos)=__iter),1); \ + __iter = list_next_entry(__iter, member)) /** * list_for_each_entry_reverse - iterate backwards over list of given type. I think you actually want: !list_entry_is_head(__iter, head, member) ? (((pos)=__iter),1) : (((pos) = NULL),0); Which can be done in the original by: !list_entry_is_head(pos, head, member) ? 1 : (((pos) = NULL), 0); Although it would be safer to have (without looking up the actual name): for (item *__item = head; \ __item ? (((pos) = list_item(__item, member)), 1) : (((pos) = NULL), 0); __item = (pos)->member) The local does need 'fixing' to avoid shadowing for nested loops. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Am 28.02.22 um 22:13 schrieb James Bottomley: > On Mon, 2022-02-28 at 21:56 +0100, Christian König wrote: >> Am 28.02.22 um 21:42 schrieb James Bottomley: >>> On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote: >>>> Am 28.02.22 um 20:56 schrieb Linus Torvalds: >>>>> On Mon, Feb 28, 2022 at 4:19 AM Christian König >>>>> <christian.koenig@amd.com> wrote: >>>>> [SNIP] >>>>> Anybody have any ideas? >>>> I think we should look at the use cases why code is touching >>>> (pos) >>>> after the loop. >>>> >>>> Just from skimming over the patches to change this and experience >>>> with the drivers/subsystems I help to maintain I think the >>>> primary pattern looks something like this: >>>> >>>> list_for_each_entry(entry, head, member) { >>>> if (some_condition_checking(entry)) >>>> break; >>>> } >>>> do_something_with(entry); >>> Actually, we usually have a check to see if the loop found >>> anything, but in that case it should something like >>> >>> if (list_entry_is_head(entry, head, member)) { >>> return with error; >>> } >>> do_somethin_with(entry); >>> >>> Suffice? The list_entry_is_head() macro is designed to cope with >>> the bogus entry on head problem. >> That will work and is also what people already do. >> >> The key problem is that we let people do the same thing over and >> over again with slightly different implementations. >> >> Out in the wild I've seen at least using a separate variable, using >> a bool to indicate that something was found and just assuming that >> the list has an entry. >> >> The last case is bogus and basically what can break badly. > Yes, I understand that. I'm saying we should replace that bogus checks > of entry->something against some_value loop termination condition with > the list_entry_is_head() macro. That should be a one line and fairly > mechanical change rather than the explosion of code changes we seem to > have in the patch series. Yes, exactly that's my thinking as well. Christian. > > James > >
> On 1. Mar 2022, at 01:41, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Mon, Feb 28, 2022 at 1:47 PM Jakob Koschel <jakobkoschel@gmail.com> wrote: >> >> The goal of this is to get compiler warnings right? This would indeed be great. > > Yes, so I don't mind having a one-time patch that has been gathered > using some automated checker tool, but I don't think that works from a > long-term maintenance perspective. > > So if we have the basic rule being "don't use the loop iterator after > the loop has finished, because it can cause all kinds of subtle > issues", then in _addition_ to fixing the existing code paths that > have this issue, I really would want to (a) get a compiler warning for > future cases and (b) make it not actually _work_ for future cases. > > Because otherwise it will just happen again. > >> Changing the list_for_each_entry() macro first will break all of those cases >> (e.g. the ones using 'list_entry_is_head()). > > So I have no problems with breaking cases that we basically already > have a patch for due to your automated tool. There were certainly > more than a handful, but it didn't look _too_ bad to just make the > rule be "don't use the iterator after the loop". > > Of course, that's just based on that patch of yours. Maybe there are a > ton of other cases that your patch didn't change, because they didn't > match your trigger case, so I may just be overly optimistic here. Based on the coccinelle script there are ~480 cases that need fixing in total. I'll now finish all of them and then split them by submodules as Greg suggested and repost a patch set per submodule. Sounds good? > > But basically to _me_, the important part is that the end result is > maintainable longer-term. I'm more than happy to have a one-time patch > to fix a lot of dubious cases if we can then have clean rules going > forward. > >> I assumed it is better to fix those cases first and then have a simple >> coccinelle script changing the macro + moving the iterator into the scope >> of the macro. > > So that had been another plan of mine, until I actually looked at > changing the macro. In the one case I looked at, it was ugly beyond > belief. > > It turns out that just syntactically, it's really nice to give the > type of the iterator from outside the way we do now. Yeah, it may be a > bit odd, and maybe it's partly because I'm so used to the > "list_for_each_list_entry()" syntax, but moving the type into the loop > construct really made it nasty - either one very complex line, or > having to split it over two lines which was even worse. > > Maybe the place I looked at just happened to have a long typename, but > it's basically always going to be a struct, so it's never a _simple_ > type. And it just looked very odd adn unnatural to have the type as > one of the "arguments" to that list_for_each_entry() macro. > > So yes, initially my idea had been to just move the iterator entirely > inside the macro. But specifying the type got so ugly that I think > that > > typeof (pos) pos > > trick inside the macro really ends up giving us the best of all worlds: > > (a) let's us keep the existing syntax and code for all the nice cases > that did everything inside the loop anyway > > (b) gives us a nice warning for any normal use-after-loop case > (unless you explicitly initialized it like that > sgx_mmu_notifier_release() function did for no good reason > > (c) also guarantees that even if you don't get a warning, > non-converted (or newly written) bad code won't actually _work_ > > so you end up getting the new rules without any ambiguity or mistaken > >> With this you are no longer able to set the 'outer' pos within the list >> iterator loop body or am I missing something? > > Correct. Any assignment inside the loop will be entirely just to the > local loop case. So any "break;" out of the loop will have to set > another variable - like your updated patch did. > >> I fail to see how this will make most of the changes in this >> patch obsolete (if that was the intention). > > I hope my explanation above clarifies my thinking: I do not dislike > your patch, and in fact your patch is indeed required to make the new > semantics work. ok it's all clear now, thanks for clarifying. I've defined all the 'tmp' iterator variables uninitialized so applying your patch on top of that later will just give the nice compiler warning if they are used past the loop body. > > What I disliked was always the maintainability of your patch - making > the rules be something that isn't actually visible in the source code, > and letting the old semantics still work as well as they ever did, and > having to basically run some verification pass to find bad users. Since this patch is not a complete list of cases that need fixing (30%) I haven't included the actual change of moving the iterator variable into the loop and thought that would be a second step coming after this is merged. With these changes alone, yes you still rely on manual verification passes. > > (I also disliked your original patch that mixed up the "CPU > speculation type safety" with the actual non-speculative problems, but > that was another issue). > > Linus - Jakob
On Mon, Feb 28, 2022 at 01:06:57PM +0100, Jakob Koschel wrote: > > > > On 28. Feb 2022, at 12:20, Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Mon, Feb 28, 2022 at 12:08:18PM +0100, Jakob Koschel wrote: > >> If the list does not contain the expected element, the value of > >> list_for_each_entry() iterator will not point to a valid structure. > >> To avoid type confusion in such case, the list iterator > >> scope will be limited to list_for_each_entry() loop. > >> > >> In preparation to limiting scope of a list iterator to the list traversal > >> loop, use a dedicated pointer to point to the found element. > >> Determining if an element was found is then simply checking if > >> the pointer is != NULL. > >> > >> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> > >> --- > >> arch/x86/kernel/cpu/sgx/encl.c | 6 +++-- > >> drivers/scsi/scsi_transport_sas.c | 17 ++++++++----- > >> drivers/thermal/thermal_core.c | 38 ++++++++++++++++++---------- > >> drivers/usb/gadget/configfs.c | 22 ++++++++++------ > >> drivers/usb/gadget/udc/max3420_udc.c | 11 +++++--- > >> drivers/usb/gadget/udc/tegra-xudc.c | 11 +++++--- > >> drivers/usb/mtu3/mtu3_gadget.c | 11 +++++--- > >> drivers/usb/musb/musb_gadget.c | 11 +++++--- > >> drivers/vfio/mdev/mdev_core.c | 11 +++++--- > >> 9 files changed, 88 insertions(+), 50 deletions(-) > > > > The drivers/usb/ portion of this patch should be in patch 1/X, right? > > I kept them separate since it's a slightly different case. > Using 'ptr' instead of '&ptr->other_member'. Regardless, I'll split > this commit up as you mentioned. > > > > > Also, you will have to split these up per-subsystem so that the > > different subsystem maintainers can take these in their trees. > > Thanks for the feedback. > To clarify I understand you correctly: > I should do one patch set per-subsystem with every instance/(file?) > fixed as a separate commit? Yes, each file needs a different commit as they are usually all written or maintained by different people. As I said in my other response, if you need any help with this, just let me know, I'm glad to help. thanks, greg k-h
On Tue, Mar 01, 2022 at 06:40:04PM +0100, Jakob Koschel wrote: > > > > On 1. Mar 2022, at 18:36, Greg KH <greg@kroah.com> wrote: > > > > On Tue, Mar 01, 2022 at 12:28:15PM +0100, Jakob Koschel wrote: > >> > >> > >>> On 1. Mar 2022, at 01:41, Linus Torvalds <torvalds@linux-foundation.org> wrote: > >>> > >>> On Mon, Feb 28, 2022 at 1:47 PM Jakob Koschel <jakobkoschel@gmail.com> wrote: > >>>> > >>>> The goal of this is to get compiler warnings right? This would indeed be great. > >>> > >>> Yes, so I don't mind having a one-time patch that has been gathered > >>> using some automated checker tool, but I don't think that works from a > >>> long-term maintenance perspective. > >>> > >>> So if we have the basic rule being "don't use the loop iterator after > >>> the loop has finished, because it can cause all kinds of subtle > >>> issues", then in _addition_ to fixing the existing code paths that > >>> have this issue, I really would want to (a) get a compiler warning for > >>> future cases and (b) make it not actually _work_ for future cases. > >>> > >>> Because otherwise it will just happen again. > >>> > >>>> Changing the list_for_each_entry() macro first will break all of those cases > >>>> (e.g. the ones using 'list_entry_is_head()). > >>> > >>> So I have no problems with breaking cases that we basically already > >>> have a patch for due to your automated tool. There were certainly > >>> more than a handful, but it didn't look _too_ bad to just make the > >>> rule be "don't use the iterator after the loop". > >>> > >>> Of course, that's just based on that patch of yours. Maybe there are a > >>> ton of other cases that your patch didn't change, because they didn't > >>> match your trigger case, so I may just be overly optimistic here. > >> > >> Based on the coccinelle script there are ~480 cases that need fixing > >> in total. I'll now finish all of them and then split them by > >> submodules as Greg suggested and repost a patch set per submodule. > >> Sounds good? > > > > Sounds good to me! > > > > If you need help carving these up and maintaining them over time as > > different subsystem maintainers accept/ignore them, just let me know. > > Doing large patchsets like this can be tough without a lot of > > experience. > > Very much appreciated! > > There will probably be some cases that do not match one of the pattern > we already discussed and need separate attention. > > I was planning to start with one subsystem and adjust the coming ones > according to the feedback gather there instead of posting all of them > in one go. That seems wise. Feel free to use USB as a testing ground for this if you want to :) thanks, greg k-h
On Tue, Mar 01, 2022 at 12:28:15PM +0100, Jakob Koschel wrote: > Based on the coccinelle script there are ~480 cases that need fixing > in total. I'll now finish all of them and then split them by > submodules as Greg suggested and repost a patch set per submodule. > Sounds good? To help with this splitting, see: https://github.com/kees/kernel-tools/blob/trunk/split-on-maintainer It's not perfect, but it'll get you really close. For example, if you had a single big tree-wide patch applied to your tree: $ rm 0*.patch $ git format-patch -1 HEAD $ mv 0*.patch treewide.patch $ split-on-maintainer treewide.patch $ ls 0*.patch If you have a build log before the patch that spits out warnings, the --build-log argument can extract those warnings on a per-file basis, too (though this can be fragile).
On Tue, Mar 01, 2022 at 10:14:07AM -0800, Kees Cook wrote: > On Mon, Feb 28, 2022 at 04:45:11PM -0800, Linus Torvalds wrote: > > Really. The "-Wshadow doesn't work on the kernel" is not some new > > issue, because you have to do completely insane things to the source > > code to enable it. > > The first big glitch with -Wshadow was with shadowed global variables. > GCC 4.8 fixed that, but it still yells about shadowed functions. What > _almost_ works is -Wshadow=local. At first glace, all the warnings > look solvable, but then one will eventually discover __wait_event() > and associated macros that mix when and how deeply it intentionally > shadows variables. :) Well, that's just disgusting. Macros fundamentally shouldn't be referring to things that aren't in their arguments. The first step to cleaning this up is ... I'll take a look at the rest of cleaning this up soon.
On Mon, Feb 28, 2022 at 2:29 PM James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > However, if the desire is really to poison the loop variable then we > can do > > #define list_for_each_entry(pos, head, member) \ > for (pos = list_first_entry(head, typeof(*pos), member); \ > !list_entry_is_head(pos, head, member) && ((pos = NULL) == NULL; \ > pos = list_next_entry(pos, member)) > > Which would at least set pos to NULL when the loop completes. That would actually have been excellent if we had done that originally. It would not only avoid the stale and incorrectly typed head entry left-over turd, it would also have made it very easy to test for "did I find an entry in the loop". But I don't much like it in the situation we are now. Why? Mainly because it basically changes the semantics of the loop _without_ any warnings about it. And we don't actually get the advantage of the nicer semantics, because we can't actually make code do list_for_each_entry(entry, ....) { .. } if (!entry) return -ESRCH; .. use the entry we found .. because that would be a disaster for back-porting, plus it would be a flag-day issue (ie we'd have to change the semantics of the loop at the same time we change every single user). So instead of that simple "if (!entry)", we'd effectively have to continue to use something that still works with the old world order (ie that "if (list_entry_is_head())" model). So we couldn't really take _advantage_ of the nicer semantics, and we'd not even get a warning if somebody does it wrong - the code would just silently do the wrong thing. IOW: I don't think you are wrong about that patch: it would solve the problem that Jakob wants to solve, and it would have absolutely been much better if we had done this from the beginning. But I think that in our current situation, it's actually a really fragile solution to the "don't do that then" problem we have. Linus
On Tue, Mar 1, 2022 at 2:58 PM David Laight <David.Laight@aculab.com> wrote: > > Can it be resolved by making: > #define list_entry_is_head(pos, head, member) ((pos) == NULL) > and double-checking that it isn't used anywhere else (except in > the list macros themselves). Well, yes, except for the fact that then the name is entirely misleading... And somebody possibly uses it together with list_first_entry() etc, so it really is completely broken to mix that change with the list traversal change. Linus Linus
On Tue, Mar 1, 2022 at 3:19 PM David Laight <David.Laight@aculab.com> wrote: > > Having said that there are so few users of list_entry_is_head() > it is reasonable to generate two new names. Well, the problem is that the users of list_entry_is_head() may be few - but there are a number of _other_ ways to check "was that the HEAD pointer", and not all of them are necessarily correct. IOW, different places do different random tests for "did we walk the whole loop without breaking out". And many of them happen to work. In fact, in practice, pretty much *all* of them happen to work, and you have to have the right struct layout and really really bad luck to hit a case of "type confusion ended up causing the test to not work". And *THAT* is the problem here. It's not the "there are 25ish places that current use list_entry_is_head()". It's the "there are ~480 places that use the type-confused HEAD entry that has been cast to the wrong type". And THAT is why I think we'd be better off with that bigger change that simply means that you can't use the iterator variable at all outside the loop, and try to make it something where the compiler can help catch mis-uses. Now, making the list_for_each_entry() thing force the iterator to NULL at the end of the loop does fix the problem. The issue I have with it is really just that you end up getting no warning at all from the compiler if you mix old-style and new-style semantics. Now, you *will* get an oops (if using a new-style iterator with an old-style check), but many of these things will be in odd driver code and may happen only for error cases. And if you use a new-style check with an old-style iterator (ie some backport problem), you will probably end up getting random memory corruption, because you'll decide "it's not a HEAD entry", and then you'll actually *use* the HEAD that has the wrong type cast associated with it. See what my worry is? With the "don't use iterator outside the loop" approach, the exact same code works in both the old world order and the new world order, and you don't have the semantic confusion. And *if* you try to use the iterator outside the loop, you'll _mostly_ (*) get a compiler warning about it not being initialized. Linus (*) Unless somebody initializes the iterator pointer pointlessly. Which clearly does happen. Thus the "mostly". It's not perfect, and that's most definitely not nice - but it should at least hopefully make it that much harder to mess up.
On Wed, Mar 02, 2022 at 12:18:45PM -0800, Linus Torvalds wrote: > On Wed, Mar 2, 2022 at 12:07 PM Kees Cook <keescook@chromium.org> wrote: > > > > I've long wanted to change kfree() to explicitly set pointers to NULL on > > free. https://github.com/KSPP/linux/issues/87 > > We've had this discussion with the gcc people in the past, and gcc > actually has some support for it, but it's sadly tied to the actual > function name (ie gcc has some special-casing for "free()") > > See > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527 > > for some of that discussion. > > Oh, and I see some patch actually got merged since I looked there last > so that you can mark "deallocator" functions, but I think it's only > for the context matching, not for actually killing accesses to the > pointer afterwards. Ah! I missed that getting added in GCC 11. But yes, there it is: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-malloc-function-attribute Hah, now we may need to split __malloc from __alloc_size. ;) I'd still like the NULL assignment behavior, though, since some things can easily avoid static analysis.
diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c index 48afe96ae0f0..6c916416decc 100644 --- a/arch/x86/kernel/cpu/sgx/encl.c +++ b/arch/x86/kernel/cpu/sgx/encl.c @@ -450,7 +450,8 @@ static void sgx_mmu_notifier_release(struct mmu_notifier *mn, struct mm_struct *mm) { struct sgx_encl_mm *encl_mm = container_of(mn, struct sgx_encl_mm, mmu_notifier); - struct sgx_encl_mm *tmp = NULL; + struct sgx_encl_mm *found_encl_mm = NULL; + struct sgx_encl_mm *tmp; /* * The enclave itself can remove encl_mm. Note, objects can't be moved @@ -460,12 +461,13 @@ static void sgx_mmu_notifier_release(struct mmu_notifier *mn, list_for_each_entry(tmp, &encl_mm->encl->mm_list, list) { if (tmp == encl_mm) { list_del_rcu(&encl_mm->list); + found_encl_mm = tmp; break; } } spin_unlock(&encl_mm->encl->mm_lock); - if (tmp == encl_mm) { + if (found_encl_mm) { synchronize_srcu(&encl_mm->encl->srcu); mmu_notifier_put(mn); } diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c index 4ee578b181da..a8cbd90db9d2 100644 --- a/drivers/scsi/scsi_transport_sas.c +++ b/drivers/scsi/scsi_transport_sas.c @@ -1060,26 +1060,29 @@ EXPORT_SYMBOL(sas_port_get_phy); * connected to a remote device is a port, so ports must be formed on * all devices with phys if they're connected to anything. */ -void sas_port_add_phy(struct sas_port *port, struct sas_phy *phy) +void sas_port_add_phy(struct sas_port *port, struct sas_phy *_phy) { mutex_lock(&port->phy_list_mutex); - if (unlikely(!list_empty(&phy->port_siblings))) { + if (unlikely(!list_empty(&_phy->port_siblings))) { /* make sure we're already on this port */ + struct sas_phy *phy = NULL; struct sas_phy *tmp; list_for_each_entry(tmp, &port->phy_list, port_siblings) - if (tmp == phy) + if (tmp == _phy) { + phy = tmp; break; + } /* If this trips, you added a phy that was already * part of a different port */ - if (unlikely(tmp != phy)) { + if (unlikely(!phy)) { dev_printk(KERN_ERR, &port->dev, "trying to add phy %s fails: it's already part of another port\n", - dev_name(&phy->dev)); + dev_name(&_phy->dev)); BUG(); } } else { - sas_port_create_link(port, phy); - list_add_tail(&phy->port_siblings, &port->phy_list); + sas_port_create_link(port, _phy); + list_add_tail(&_phy->port_siblings, &port->phy_list); port->num_phys++; } mutex_unlock(&port->phy_list_mutex); diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index 82654dc8382b..97198543448b 100644 --- a/drivers/thermal/thermal_core.c +++ b/drivers/thermal/thermal_core.c @@ -625,24 +625,30 @@ int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz, { struct thermal_instance *dev; struct thermal_instance *pos; - struct thermal_zone_device *pos1; - struct thermal_cooling_device *pos2; + struct thermal_zone_device *pos1 = NULL; + struct thermal_zone_device *tmp1; + struct thermal_cooling_device *pos2 = NULL; + struct thermal_cooling_device *tmp2; unsigned long max_state; int result, ret; if (trip >= tz->trips || trip < 0) return -EINVAL; - list_for_each_entry(pos1, &thermal_tz_list, node) { - if (pos1 == tz) + list_for_each_entry(tmp1, &thermal_tz_list, node) { + if (tmp1 == tz) { + pos1 = tmp1; break; + } } - list_for_each_entry(pos2, &thermal_cdev_list, node) { - if (pos2 == cdev) + list_for_each_entry(tmp2, &thermal_cdev_list, node) { + if (tmp2 == cdev) { + pos2 = tmp2; break; + } } - if (tz != pos1 || cdev != pos2) + if (!pos1 || !pos2) return -EINVAL; ret = cdev->ops->get_max_state(cdev, &max_state); @@ -1074,15 +1080,18 @@ void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev) const struct thermal_zone_params *tzp; struct thermal_zone_device *tz; struct thermal_cooling_device *pos = NULL; + struct thermal_cooling_device *tmp; if (!cdev) return; mutex_lock(&thermal_list_lock); - list_for_each_entry(pos, &thermal_cdev_list, node) - if (pos == cdev) + list_for_each_entry(tmp, &thermal_cdev_list, node) + if (tmp == cdev) { + pos = tmp; break; - if (pos != cdev) { + } + if (!pos) { /* thermal cooling device not found */ mutex_unlock(&thermal_list_lock); return; @@ -1335,6 +1344,7 @@ void thermal_zone_device_unregister(struct thermal_zone_device *tz) const struct thermal_zone_params *tzp; struct thermal_cooling_device *cdev; struct thermal_zone_device *pos = NULL; + struct thermal_zone_device *tmp; if (!tz) return; @@ -1343,10 +1353,12 @@ void thermal_zone_device_unregister(struct thermal_zone_device *tz) tz_id = tz->id; mutex_lock(&thermal_list_lock); - list_for_each_entry(pos, &thermal_tz_list, node) - if (pos == tz) + list_for_each_entry(tmp, &thermal_tz_list, node) + if (tmp == tz) { + pos = tmp; break; - if (pos != tz) { + } + if (!pos) { /* thermal zone device not found */ mutex_unlock(&thermal_list_lock); return; diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c index d4a678c0806e..99f10cbd8878 100644 --- a/drivers/usb/gadget/configfs.c +++ b/drivers/usb/gadget/configfs.c @@ -418,7 +418,8 @@ static int config_usb_cfg_link( struct usb_function_instance *fi = to_usb_function_instance(usb_func_ci); - struct usb_function_instance *a_fi; + struct usb_function_instance *a_fi = NULL; + struct usb_function_instance *tmp; struct usb_function *f; int ret; @@ -428,11 +429,13 @@ static int config_usb_cfg_link( * from another gadget or a random directory. * Also a function instance can only be linked once. */ - list_for_each_entry(a_fi, &gi->available_func, cfs_list) { - if (a_fi == fi) + list_for_each_entry(tmp, &gi->available_func, cfs_list) { + if (tmp == fi) { + a_fi = tmp; break; + } } - if (a_fi != fi) { + if (!a_fi) { ret = -EINVAL; goto out; } @@ -882,15 +885,18 @@ static int os_desc_link(struct config_item *os_desc_ci, struct gadget_info *gi = os_desc_item_to_gadget_info(os_desc_ci); struct usb_composite_dev *cdev = &gi->cdev; struct config_usb_cfg *c_target = to_config_usb_cfg(usb_cfg_ci); - struct usb_configuration *c; + struct usb_configuration *c = NULL; + struct usb_configuration *tmp; int ret; mutex_lock(&gi->lock); - list_for_each_entry(c, &cdev->configs, list) { - if (c == &c_target->c) + list_for_each_entry(tmp, &cdev->configs, list) { + if (tmp == &c_target->c) { + c = tmp; break; + } } - if (c != &c_target->c) { + if (!c) { ret = -EINVAL; goto out; } diff --git a/drivers/usb/gadget/udc/max3420_udc.c b/drivers/usb/gadget/udc/max3420_udc.c index d2a2b20cc1ad..d1b010b5f4a0 100644 --- a/drivers/usb/gadget/udc/max3420_udc.c +++ b/drivers/usb/gadget/udc/max3420_udc.c @@ -1044,22 +1044,25 @@ static int max3420_ep_queue(struct usb_ep *_ep, struct usb_request *_req, static int max3420_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req) { - struct max3420_req *t, *req = to_max3420_req(_req); + struct max3420_req *t = NULL; + struct max3420_req *req = to_max3420_req(_req); + struct max3420_req *tmp; struct max3420_ep *ep = to_max3420_ep(_ep); unsigned long flags; spin_lock_irqsave(&ep->lock, flags); /* Pluck the descriptor from queue */ - list_for_each_entry(t, &ep->queue, queue) - if (t == req) { + list_for_each_entry(tmp, &ep->queue, queue) + if (tmp == req) { list_del_init(&req->queue); + t = tmp; break; } spin_unlock_irqrestore(&ep->lock, flags); - if (t == req) + if (t) max3420_req_done(req, -ECONNRESET); return 0; diff --git a/drivers/usb/gadget/udc/tegra-xudc.c b/drivers/usb/gadget/udc/tegra-xudc.c index 43f1b0d461c1..c37e3148a208 100644 --- a/drivers/usb/gadget/udc/tegra-xudc.c +++ b/drivers/usb/gadget/udc/tegra-xudc.c @@ -1413,18 +1413,21 @@ __tegra_xudc_ep_dequeue(struct tegra_xudc_ep *ep, struct tegra_xudc_request *req) { struct tegra_xudc *xudc = ep->xudc; - struct tegra_xudc_request *r; + struct tegra_xudc_request *r = NULL; + struct tegra_xudc_request *tmp; struct tegra_xudc_trb *deq_trb; bool busy, kick_queue = false; int ret = 0; /* Make sure the request is actually queued to this endpoint. */ - list_for_each_entry(r, &ep->queue, list) { - if (r == req) + list_for_each_entry(tmp, &ep->queue, list) { + if (tmp == req) { + r = tmp; break; + } } - if (r != req) + if (!r) return -EINVAL; /* Request hasn't been queued in the transfer ring yet. */ diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c index 9977600616d7..2e4daaa081a0 100644 --- a/drivers/usb/mtu3/mtu3_gadget.c +++ b/drivers/usb/mtu3/mtu3_gadget.c @@ -323,7 +323,8 @@ static int mtu3_gadget_dequeue(struct usb_ep *ep, struct usb_request *req) { struct mtu3_ep *mep = to_mtu3_ep(ep); struct mtu3_request *mreq = to_mtu3_request(req); - struct mtu3_request *r; + struct mtu3_request *r = NULL; + struct mtu3_request *tmp; struct mtu3 *mtu = mep->mtu; unsigned long flags; int ret = 0; @@ -336,11 +337,13 @@ static int mtu3_gadget_dequeue(struct usb_ep *ep, struct usb_request *req) spin_lock_irqsave(&mtu->lock, flags); - list_for_each_entry(r, &mep->req_list, list) { - if (r == mreq) + list_for_each_entry(tmp, &mep->req_list, list) { + if (tmp == mreq) { + r = tmp; break; + } } - if (r != mreq) { + if (!r) { dev_dbg(mtu->dev, "req=%p not queued to %s\n", req, ep->name); ret = -EINVAL; goto done; diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index 51274b87f46c..26b61ad7ab1b 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1266,7 +1266,8 @@ static int musb_gadget_dequeue(struct usb_ep *ep, struct usb_request *request) { struct musb_ep *musb_ep = to_musb_ep(ep); struct musb_request *req = to_musb_request(request); - struct musb_request *r; + struct musb_request *r = NULL; + struct musb_request *tmp; unsigned long flags; int status = 0; struct musb *musb = musb_ep->musb; @@ -1278,11 +1279,13 @@ static int musb_gadget_dequeue(struct usb_ep *ep, struct usb_request *request) spin_lock_irqsave(&musb->lock, flags); - list_for_each_entry(r, &musb_ep->req_list, list) { - if (r == req) + list_for_each_entry(tmp, &musb_ep->req_list, list) { + if (tmp == req) { + r = tmp; break; + } } - if (r != req) { + if (!r) { dev_err(musb->controller, "request %p not queued to %s\n", request, ep->name); status = -EINVAL; diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c index b314101237fe..52cfa44c24a7 100644 --- a/drivers/vfio/mdev/mdev_core.c +++ b/drivers/vfio/mdev/mdev_core.c @@ -337,16 +337,19 @@ int mdev_device_create(struct mdev_type *type, const guid_t *uuid) int mdev_device_remove(struct mdev_device *mdev) { - struct mdev_device *tmp; + struct mdev_device *tmp = NULL; + struct mdev_device *iter; struct mdev_parent *parent = mdev->type->parent; mutex_lock(&mdev_list_lock); - list_for_each_entry(tmp, &mdev_list, next) { - if (tmp == mdev) + list_for_each_entry(iter, &mdev_list, next) { + if (iter == mdev) { + tmp = iter; break; + } } - if (tmp != mdev) { + if (!tmp) { mutex_unlock(&mdev_list_lock); return -ENODEV; }
If the list does not contain the expected element, the value of list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to list_for_each_entry() loop. In preparation to limiting scope of a list iterator to the list traversal loop, use a dedicated pointer to point to the found element. Determining if an element was found is then simply checking if the pointer is != NULL. Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> --- arch/x86/kernel/cpu/sgx/encl.c | 6 +++-- drivers/scsi/scsi_transport_sas.c | 17 ++++++++----- drivers/thermal/thermal_core.c | 38 ++++++++++++++++++---------- drivers/usb/gadget/configfs.c | 22 ++++++++++------ drivers/usb/gadget/udc/max3420_udc.c | 11 +++++--- drivers/usb/gadget/udc/tegra-xudc.c | 11 +++++--- drivers/usb/mtu3/mtu3_gadget.c | 11 +++++--- drivers/usb/musb/musb_gadget.c | 11 +++++--- drivers/vfio/mdev/mdev_core.c | 11 +++++--- 9 files changed, 88 insertions(+), 50 deletions(-) -- 2.25.1