On Mon, 24 Feb 2025 at 06:52, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Sun, Feb 23, 2025 at 07:34:30PM +0100, Ricardo Ribalda wrote: > > On Fri, 21 Feb 2025 at 10:18, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > > > > > On 21/02/2025 10:04, Hans Verkuil wrote: > > > > Hi Ricardo, > > > > > > > > On 21/01/2025 22:14, Ricardo Ribalda wrote: > > > >> When we obtain a reference to of a platform_device, we need to release > > > >> it via put_device. > > > >> > > > >> Found by cocci: > > > >> ./platform/nuvoton/npcm-video.c:1677:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. > > > >> ./platform/nuvoton/npcm-video.c:1684:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. > > > >> ./platform/nuvoton/npcm-video.c:1690:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. > > > >> ./platform/nuvoton/npcm-video.c:1694:1-7: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. > > > > > > > > This driver uses this construct: > > > > > > > > struct device *ece_dev __free(put_device) = &ece_pdev->dev; > > > > > > > > to automatically call put_device. So this patch would 'put' the device twice. > > > > > > > > Does cocci understand constructs like this? If I hadn't looked closely at the > > > > code first, I would just have merged it. > > > > > > Oh wait, now that I am reading the following patches I see that it was those later > > > patches that add the __free code. > > > > > > This is far too confusing. Please post a v2 that just combines the 'fix references' > > > and 'use cleanup.h macros' in a single patch. It makes no sense to have this two-phase > > > approach. > > > > I believe this is discouraged. > > > > cleanup.h macros does not exist in old kernel versions, so makes it > > impossible to backport the fix to them. > > That's not a problem, fix things properly in the main tree and let the > stable/lts kernels work it out on their own. > > > This is an example of other series following this policy: > > https://lore.kernel.org/lkml/173608125422.1253657.3732758016133408588.stgit@devnote2/ > > > > They also mention the same here: > > https://hackerbikepacker.com/kernel-auto-cleanup-1 .... I am pretty > > sure that I read the policy in a more official location... but I > > cannot find it right now :) > > No, it is NOT official policy at all. Otherwise you would be saying > that no one could use these new functions for 6 years just because of > really old kernels still living around somewhere. That's not how kernel > development works, thankfully. No, I am not saying that we cannot use cleanup.h for 6 years. What I am saying is that first we fix the errors without it, and then we move to cleanup.h. All in the same series: 1/2 Fix reference handling (cc: stable) 2/2 Use cleanup.h That way the fix (1/2) can be applied without changes to all the stable trees, and 2/2 can be ignored by them. The alternative is a patch that cannot be applied to stable and either you, the author or the maintainer have to backport to stable (basically implementing 1/2). So no, we do not save work by just posting a cleanup.h version of the fix to the mailing list. The even better alternative is that cleanup.h is backported to all the stable trees. Anyway, it is up to you and Sasha to decide. I will repost the series only using cleanup.h Best regards! > > thanks, > > greg k-h -- Ricardo Ribalda
