On Sun, Sep 17, 2023 at 11:12:25AM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > Variables managed with __free() should typically be initialized where > they are declared so that the __free() callback is paired with its > counterpart resource allocator. Fix the second instance of using > __free() in gpio-sim to follow this pattern. ... > { > - struct gpio_sim_device *dev __free(kfree) = NULL; > int id; > > - dev = kzalloc(sizeof(*dev), GFP_KERNEL); > + struct gpio_sim_device *dev __free(kfree) = kzalloc(sizeof(*dev), > + GFP_KERNEL); > if (!dev) > return ERR_PTR(-ENOMEM); Aside: Oh, this might be a downside of the __free() sugar, as we can theoretically end up with a code in the future like struct bar *foo; ... struct baz *foo __free() = ... ... and I am not sure how it goes to work. Or relaxed variant with struct bar *foo; ... { struct baz *foo __free() = ... ... } where we would have two variables with the same name, but different scope (this, perhaps, would work, but I assume compiler should warn about shadowed name for the variable). (Also what if in both cases bar == baz, i.e. same type?) -- With Best Regards, Andy Shevchenko