On 25.02.2021 21:30, Takashi Iwai wrote:> On Thu, 25 Feb 2021 20:02:50
+0100,
Michael S. Tsirkin wrote:
On Thu, Feb 25, 2021 at 01:51:16PM +0100, Takashi Iwai wrote:
On Thu, 25 Feb 2021 13:14:37 +0100,
Anton Yakovlev wrote:
[snip]
Takashi given I was in my tree for a while and I planned to merge
it this merge window.
Hmm, that's too quick, I'm afraid. I see still a few rough edges in
the code. e.g. the reset work should be canceled at the driver
removal, but it's missing right now. And that'll become tricky
because the reset work itself unbinds the device, hence it'll get
stuck if calling cancel_work_sync() at remove callback.
Yes, you made a good point here! In this case, we need some external
mutex for synchronization. This is just a rough idea, but maybe
something like this might work:
struct reset_work {
struct mutex mutex;
struct work_struct work;
struct virtio_snd *snd;
bool resetting;
};
static struct reset_work reset_works[SNDRV_CARDS];
init()
// init mutexes and workers
virtsnd_probe()
snd_card_new(snd->card)
reset_works[snd->card->number].snd = snd;
virtsnd_remove()
mutex_lock(reset_works[snd->card->number].mutex)
reset_works[snd->card->number].snd = NULL;
resetting = reset_works[snd->card->number].resetting;
mutex_unlock(reset_works[snd->card->number].mutex)
if (!resetting)
// cancel worker reset_works[snd->card->number].work
// remove device
virtsnd_reset_fn(work)
mutex_lock(work->mutex)
if (!work->snd)
// do nothing and take an exit path
work->resetting = true;
mutex_unlock(work->mutex)
device_reprobe()
work->resetting = false;
interrupt_handler()
schedule_work(reset_works[snd->card->number].work);
What do you think?
--
Anton Yakovlev
Senior Software Engineer
OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
