Hi,
On Dec 30 2015 17:09, Takashi Iwai wrote:
On Tue, 29 Dec 2015 12:37:06 +0100, Takashi Sakamoto wrote:
On 2015年12月29日 19:56, Takashi Sakamoto wrote:
On 2015年12月29日 18:00, Takashi Iwai wrote:
On Sat, 26 Dec 2015 04:35:24 +0100, Takashi Sakamoto wrote:
When work of sound card registration fails, bus reset on IEEE 1394 can schedule the work again. In this case, currently instances of PCM and RawMIDI devices are not released, but allocated and errors occurs.
This commit solves this issue. The allocated data is kept and released at any failures in the work.
Aren't they be released in snd_card_free() in the later error path?
Not in the error path, but indeed in card free processing. They're not released anymore. I should have used snd_pcm_free() and snd_rawmidi_free() for this purpose. (I misunderstand they should be used after calling snd_card_register().)
I realized that both of snd_rawmidi_free() and snd_pcm_free() are called by snd_device_free(), then all of allocated memory blocks are freed.
Which error pathes do you think to cause the problems?
I don't think it causing problems but just superfluous to call explicitly there. You (should) call snd_card_free*() in the error path, and these components are released there automatically.
I had two reason not to call snd_card_free() family in error path of the 'do_registration().
Originally, the 'do_registration()' and .remove() are on a race condition against sound card instance.
But now. remove() waits to finish a work of the sound card registration, therefore snd_card_free() can be called in error path of the work.
Another reason is the memory object for driver_data. Currently I use struct snd_dice allocated by snd_card_new(). If calling snd_card_new() in the work, I must allocate it in .probe() callback independently. I thought it a bit hard to maintain the memory object against the race condition between the work, .update() and .remove() and sound card free.
But the race condition becomes simpler when .remove() waits to finish the work.
OK. I'll modify and post the new patchset.
In which code path did you see the leak? This already sounds strange.
It was my misunderstanding a few days ago.
Thanks
Takashi Sakamoto