virtual_oss(8): Properly cleanup cuse(3) #41
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "christos/vosscuse"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
virtual_oss(8) does not currently keep track of the cuse(3) it creates,
nor does it destroy any of them on exit, except for the control device.
This is harmless if virtual_oss(8) is shutdown after all audio streams
have been shut down, but if it's killed during I/O, the process hangs
and/or goes into uninterruptible sleep state.
To fix this, have pointers to all cuse(3) devices, and explicitly
destroy them on exit.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
@jrm @0mp This should fix the issues we talked about in #33. Feel free to test.
@ -1957,6 +1958,7 @@ dup_profile(vprofile_t *pvp, int *pamp, int pol, int rx_mute,free(ptr);Is this a problem?
dup_profile()is called with bothpvp->oss_nameandpvp->wav_namenon-empty.ptris allocated and copiedfree(ptr)releases the heap memory, butptr->oss_devis discarded andcuse_dev_destroy(ptr->oss_dev)is never called.Maybe something like this?
Good catch, will update the PR.
@ -2648,3 +2653,4 @@if (voss_ctl_device[0] != 0)cuse_dev_destroy(pdev);TAILQ_FOREACH(pvp, &virtual_profile_client_head, entry) {This is a minor nit you can certainly ignore. These two loops are almost identical. Maybe a helper function?
a13e2ab020d6ae736619d6ae736619de80446e0f@ -2651,0 +2679,4 @@}cuse_uninit();close(voss_fd_sta);It looks like
voss_fd_stacan fall through here and still be-1. Is it conventional to use a guard for something like this?I'm unsure about our convention. Maybe we're fine calling
close()on something that's not an active file descriptor?This is harmless, we don't need to check.
@ -1949,1 +1956,3 @@init_sndstat(ptr);if (voss_fd_sta < 0) {if ((voss_fd_sta = open("/dev/sndstat", O_WRONLY)) < 0) {errstr = "Could not open /dev/sndstat";We're changing from a
warnto a fatal error here. Should note that in the commit message?Not really, it's very unlikely anyone can hit this error because
/dev/sndstatis always created whensound(4)attaches, but it's good to fail if we do somehow hit an error here.lgtm
de80446e0f93a234a694