On Tue, 12 Apr 2022 12:47:47 +0200, Takashi Sakamoto wrote:
Hi,
On Tue, Apr 12, 2022 at 11:31:40AM +0200, Takashi Iwai wrote:
This is a small helper function to handle the error path more easily when an error happens during the probe for the device with the device-managed card. Since devres releases in the reverser order of the creations, usually snd_card_free() gets called at the last in the probe error path unless it already reached snd_card_register() calls. Due to this nature, when a driver expects the resource releases in card->private_free, this might be called too lately.
As a workaround, one should call the probe like:
static int __some_probe(...) { // do real probe.... }
static int some_probe(...) { return snd_card_free_on_error(dev, __some_probe(dev, ...)); }
so that the snd_card_free() is called explicitly at the beginning of the error path from the probe.
This function will be used in the upcoming fixes to address the regressions by devres usages.
Fixes: e8ad415b7a55 ("ALSA: core: Add managed card creation") Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai tiwai@suse.de
include/sound/core.h | 1 + sound/core/init.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 29 insertions(+)
diff --git a/include/sound/core.h b/include/sound/core.h index b7e9b58d3c78..6d4cc49584c6 100644 --- a/include/sound/core.h +++ b/include/sound/core.h @@ -284,6 +284,7 @@ int snd_card_disconnect(struct snd_card *card); void snd_card_disconnect_sync(struct snd_card *card); int snd_card_free(struct snd_card *card); int snd_card_free_when_closed(struct snd_card *card); +int snd_card_free_on_error(struct device *dev, int ret); void snd_card_set_id(struct snd_card *card, const char *id); int snd_card_register(struct snd_card *card); int snd_card_info_init(void); diff --git a/sound/core/init.c b/sound/core/init.c index 31ba7024e3ad..726a8353201f 100644 --- a/sound/core/init.c +++ b/sound/core/init.c @@ -209,6 +209,12 @@ static void __snd_card_release(struct device *dev, void *data)
- snd_card_register(), the very first devres action to call snd_card_free()
- is added automatically. In that way, the resource disconnection is assured
- at first, then released in the expected order.
- If an error happens at the probe before snd_card_register() is called and
- there have been other devres resources, you'd need to free the card manually
- via snd_card_free() call in the error; otherwise it may lead to UAF due to
- devres call orders. You can use snd_card_free_on_error() helper for
*/
- handling it more easily.
int snd_devm_card_new(struct device *parent, int idx, const char *xid, struct module *module, size_t extra_size, @@ -235,6 +241,28 @@ int snd_devm_card_new(struct device *parent, int idx, const char *xid, } EXPORT_SYMBOL_GPL(snd_devm_card_new);
+/**
- snd_card_free_on_error - a small helper for handling devm probe errors
- @dev: the managed device object
- @ret: the return code from the probe callback
- This function handles the explicit snd_card_free() call at the error from
- the probe callback. It's just a small helper for simplifying the error
- handling with the managed devices.
- */
+int snd_card_free_on_error(struct device *dev, int ret) +{
- struct snd_card *card;
- if (!ret)
return 0;
- card = devres_find(dev, __snd_card_release, NULL, NULL);
- if (card)
snd_card_free(card);
- return ret;
+} +EXPORT_SYMBOL_GPL(snd_card_free_on_error);
static int snd_card_init(struct snd_card *card, struct device *parent, int idx, const char *xid, struct module *module, size_t extra_size) -- 2.31.1
The idea looks good itself to me. On the other hand, the name 'snd_card_free_on_error()' is not so suitable since it assumes that 'snd_devm_card_new()' is called in advance, while we have another function, 'snd_card_new()'.
I think it better to use 'snd_devm_card_free_on_error()' instead since the function doesn't work as expected in the case of 'snd_card_new()' (the snd_card_free() is not called because nothing found in devres).
Yeah, that came to my mind in the first implementations, too, but it looked too long to me, so I took this term in the submitted version :)
In theory, we can extend it to retrieve the card from the device data, too, but I don't think worth for it.
thanks,
Takashi