Linux IIO development
 help / color / mirror / Atom feed
From: "Nuno Sá" <noname.nuno@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: Ma Ke <make24@iscas.ac.cn>,
	jic23@kernel.org, dlechner@baylibre.com,  nuno.sa@analog.com,
	andy@kernel.org, linux-iio@vger.kernel.org,
	 linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH v3] iio: trigger: Fix error handling in viio_trigger_alloc
Date: Fri, 07 Nov 2025 16:48:03 +0000	[thread overview]
Message-ID: <9e96f49f3903f704e16e8dde540507b10a978951.camel@gmail.com> (raw)
In-Reply-To: <aQ3NHnL2rF0wkqeo@smile.fi.intel.com>

On Fri, 2025-11-07 at 12:42 +0200, Andy Shevchenko wrote:
> On Fri, Nov 07, 2025 at 10:26:10AM +0000, Nuno Sá wrote:
> > On Fri, 2025-11-07 at 10:02 +0800, Ma Ke wrote:
> > > viio_trigger_alloc() initializes the device with device_initialize()
> > > but uses kfree() directly in error paths, which bypasses the device's
> > > release callback iio_trig_release(). This could lead to memory leaks
> > > and inconsistent device state.
> 
> ...
> 
> > > -free_descs:
> > > -	irq_free_descs(trig->subirq_base, CONFIG_IIO_CONSUMERS_PER_TRIGGER);
> > >  free_trig:
> > > -	kfree(trig);
> > > +	put_device(&trig->dev);
> > 
> > Yes, device_initialize() docs do say that we should give the reference instead of
> > freeing the device but I'm not see how that helps in here. Maybe initializing the
> > device should be done only after all the resources are allocated so the code is a
> > bit
> > more clear... But doing it like you're doing just means that we might get into
> > the
> > release function with things that might or might not be allocated which is a
> > pattern
> > I would prefer to avoid.
> 
> The put_device() here is the correct (and must) thing to do independently on
> the preferences. The problem is that device_initialise() and followed calls
> may do much more than just some initialisation.
> 

Well, I would argue against that (at least in the context the function is now
implemented). To me, the right thing to do would be to move the device initialization
code to this point:

https://elixir.bootlin.com/linux/v6.17.7/source/drivers/iio/industrialio-trigger.c#L594

trig->dev.parent = parent;
trig->dev.type = &iio_trig_type;
trig->dev.bus = &iio_bus_type;
device_initialize(&trig->dev);

Then we would not even need to think about put_device(). Like it is, using it, it's
just prone to errors (I did mentioned a couple of things this patch introduced If I'm
not overseeing it) or we do need to have lots of care in the release function to make
sure we don't mess up. To me that's a bad sign on how the code is architectured. 

FWIW, the pattern you find for example in SPI is the natural one for me:

You have a spi_alloc_device() [1] that initialises struct device right in the end.
Above it, kfree() as usual. Then the callers, will indeed use put_device() in their
error paths.

So the pattern to me is to do device_initialize() after all resources of your device
are allocated. So that after that point put_device() does not get you into some odd
handling in the release callback.

[1]: https://elixir.bootlin.com/linux/v6.17.7/source/drivers/spi/spi.c#L568

- Nuno Sá

  reply	other threads:[~2025-11-07 16:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-07  2:02 [PATCH v3] iio: trigger: Fix error handling in viio_trigger_alloc Ma Ke
2025-11-07  8:03 ` Andy Shevchenko
2025-11-07 10:26 ` Nuno Sá
2025-11-07 10:42   ` Andy Shevchenko
2025-11-07 16:48     ` Nuno Sá [this message]
2025-11-07 18:19       ` Andy Shevchenko
2025-11-08 10:26         ` Nuno Sá
2025-11-09 13:54           ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e96f49f3903f704e16e8dde540507b10a978951.camel@gmail.com \
    --to=noname.nuno@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=make24@iscas.ac.cn \
    --cc=nuno.sa@analog.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox