On Thu, 30 Sep 2021 08:55:52 +0200 Takashi Iwai tiwai@suse.de wrote:
On Thu, 30 Sep 2021 08:31:56 +0200, Takashi Iwai wrote:
On Wed, 29 Sep 2021 18:56:32 +0200, John Keeping wrote:
On Wed, 29 Sep 2021 17:28:57 +0200 Takashi Iwai tiwai@suse.de wrote:
On Wed, 29 Sep 2021 17:17:58 +0200, John Keeping wrote:
On Wed, 29 Sep 2021 16:51:47 +0200 Takashi Iwai tiwai@suse.de wrote:
On Wed, 29 Sep 2021 13:36:20 +0200, John Keeping wrote: > > If the sequencer device outlives the rawmidi device, then > snd_rawmidi_dev_seq_free() will run after release_rawmidi_device() has > freed the snd_rawmidi structure. > > This can easily be reproduced with CONFIG_DEBUG_KOBJECT_RELEASE. > > Keep a reference to the rawmidi device until the sequencer has been > destroyed in order to avoid this. > > Signed-off-by: John Keeping john@metanate.com
Thanks for the patch. I wonder, though, how this could be triggered. Is this the case where the connected sequencer device is being used while the sound card gets released? Or is it something else?
I'm not sure if it's possible to trigger via the ALSA API; I haven't found a route that can trigger it, but that doesn't mean there isn't one :-)
Mostly this is useful to make CONFIG_DEBUG_KOBJECT_RELEASE cleaner.
Hm, then could you check whether the patch below papers over it instead?
No, this patch doesn't solve it. The issue is that the effect of the final device_put() is delayed from the time it is called and there is no way to guarantee the ordering without ensuring the sequencer has been destroyed before the final reference to the rawmidi device is put.
Both of the functions involved are called from the core device::release() hook.
I'm using the patch below to easily check that the sequencer has been freed before the rawmidi data. This can easily be triggered by unplugging a USB MIDI device (it's not 100% since the kobject release delays are random).
Hm, it's strange. I suppose you're *not* using the MIDI device, right?
The release path for the USB-audio driver is: usb_audio_disconnect() -> snd_card_free_when_closed() -> release_card_device() (via put_device(&card->card_dev)) -> snd_card_do_free()
And here in snd_card_do_free(), the snd_device free-callback chains are called at the beginning (snd_device_free_all()). As it's executed in a reverse loop, snd_rawmidi_dev_seq_free() shall be called before snd_rawmidi_dev_free(). Since the final put_device() for the rawmidi device is called in the latter function, the device release must not happen before snd_rawmidi_dev_seq_free()...
Correction: now I finally understood what I misunderstood. Although the snd_device call chain mentioned above itself is correct, the snd_rawmidi_dev_seq_free() function isn't called directly from the snd_device chain, but it's rater the own private_free of snd_seq_device object. That is, the call of snd_seq_device private_free is done in a wrong place; it should be called in the snd_device call chain instead of the device release.
A fix patch is something like below. Could you check whether this fixes the problem?
Yes, this fixes it!
Thanks, John
--- a/sound/core/seq_device.c +++ b/sound/core/seq_device.c @@ -156,6 +156,8 @@ static int snd_seq_device_dev_free(struct snd_device *device) struct snd_seq_device *dev = device->device_data;
cancel_autoload_drivers();
- if (dev->private_free)
dev->private_free(dev);} @@ -183,11 +185,7 @@ static int snd_seq_device_dev_disconnect(struct snd_device *device)
static void snd_seq_dev_release(struct device *dev) {
- struct snd_seq_device *sdev = to_seq_dev(dev);
- if (sdev->private_free)
sdev->private_free(sdev);- kfree(sdev);
- kfree(to_seq_dev(dev));
}
/*