In D45982#1050109, @markj wrote:

In D45982#1050048, @christos wrote:

In D45982#1049997, @markj wrote:

In D45982#1049978, @dev_submerge.ch wrote:

While testing with snd_hdspe I ran into the following warning, but I can't really make sense of it:

Jul 21 17:36:14 current kernel: uma_zalloc_debug: zone "malloc-16384" with the following non-sleepable locks
held:

This is a consequence of the fact that sndstat_read() works by allocating an sbuf, which may grow as data is added, then copying out the resulting buffer via uiomove().

In general, blocking memory allocations are not permitted while holding a mtx(9) mutex, hence the warning. To work around this, one would typically add a "drain" callback function to the sbuf, that it calls to write out data once the buffer is full. In this case, the callback would write out buffered data via uiomove(), after which the buffer can be reused and thus doesn't need to grow. See sbuf_set_drain(9).

I will take care of this. Thanks.

Thinking about this again, my suggestion won't work since uiomove() also can't be called with a mutex held. (It's possible for copyout() to take a page fault, and the page fault handler may sleep.)

One other approach is to build the output twice, the first time is used to get the length of the output, without writing to the buffer. Then one allocates the buffer using the provided size, and then actually fills it.

After discussion with markj@, keep PCM_GIANT_* and just use the new
SND_LOCK for uses of devclass_get_maxunit() and where needed, global variable
setting in sysctl handlers.

Bump.

In D46836#1075056, @dev_submerge.ch wrote:

In D46836#1074859, @christos wrote:

In D46836#1073676, @dev_submerge.ch wrote:

1. What is the intended meaning of the "name" field? It was sort of descriptive before, but now you're tying it to the device path.

As mentioned before, the meaning remains exactly the same.

The "name" field was meant as a descriptive label before, now it's a copy of an internal identifier that looks like a device path but isn't. It's not obvious to me whether you want to unify it with dsp_unit2name() everywhere or not. And without knowing all uses it's hard to tell whether that's a good idea.

Remove CMLKH duplicate as well.

Use a shared lock instead. Fixes some bugs I missed (didn't realize I wasn't
using a non-MPSAFE driver when testing...).

Use sx(9) instead of mtx(9) so that we can sleep with the lock held.

Retire PCM_GIANT_ENTER() and PCM_GIANT_LEAVE/PCM_GIANT_EXIT() and replace with
2 two PCM_SND_LOCK() and PCM_SND_UNLOCK() macros (I'm open to propositions for
a better name).

In D46836#1073676, @dev_submerge.ch wrote:

1. What is the intended meaning of the "name" field? It was sort of descriptive before, but now you're tying it to the device path.

LGTM. Only a minor nit: in the commit message there is a typo: "sendmai daemon ...".

Make unr(9) per-softc. I don't know how I missed this one...

In D46847#1073456, @dev_submerge.ch wrote:

In D46847#1073438, @christos wrote:

In D46847#1069896, @dev_submerge.ch wrote:

I just put your reproduce code into a shell script. Setup is a bhyve VM, 4 cores, pcm0 is a passthrough USB audio interface, script operates on pcm1 which is snd_dummy as in your example.

I tried this exact scenario, but still cannot reproduce the panic after multiple times of running the script. Is there some non-default configuration you're using?

Nothing special, I don't have any non-default config in this test VM. It took me about 7 attempts to reproduce this with 50 channels (as in your example), I think it took less attempts with 100 as I had in my script originally. I also updated src in the meantime, same panic.

In D46847#1069896, @dev_submerge.ch wrote:

In D46847#1069421, @christos wrote:

Interesting. What do you do exactly to reproduce those? Also what is the configuration you're using?

I just put your reproduce code into a shell script. Setup is a bhyve VM, 4 cores, pcm0 is a passthrough USB audio interface, script operates on pcm1 which is snd_dummy as in your example.

In D46836#1069907, @dev_submerge.ch wrote:

In D46836#1069394, @christos wrote:

In D46836#1069273, @dev_submerge.ch wrote:

I don't care too much about the device names, but I think we should conceptually separate them from what we display to the end user. As a future goal we may want to have something more elaborate in the OSS audio info name field, e.g. dsp.virtual_play.1 <Dummy Audio Device>.

I agree with printing something more elaborate, although I'd prefer a different naming scheme than this one. But we can discuss it in the future. :-)

You are changing the content of the name field here. We have to assess where and what it is used for. As I try to explain, the different use cases may demand different formatting and content, thus I want to know what we cater to here.

@markj any opinion (see previous comment)?

Split buffer line as well.

Approved.

Approved.

In D46857#1069256, @dev_submerge.ch wrote:

I'd prefer a smaller indent, maybe 2 spaces instead of the 8 space standard tabs, also for the first indent level. As is, the lines regularly exceed 80 character screen width and break the visual indent with the overflow.
But this is already an improvement, thanks!

Interesting. What do you do exactly to reproduce those? Also what is the configuration you're using?

In D46836#1069273, @dev_submerge.ch wrote:

I don't care too much about the device names, but I think we should conceptually separate them from what we display to the end user. As a future goal we may want to have something more elaborate in the OSS audio info name field, e.g. dsp.virtual_play.1 <Dummy Audio Device>.

New naming scheme: dspX.[virtual_]play|record.Y

Use new global driver lock instead of bus_topo_*.

Any comments?

In D46847#1068121, @markj wrote:

In general it makes sense to remove entry points (a device file in this case) first when tearing down a driver, so this is probably fine.

In D46836#1067943, @dev_submerge.ch wrote:

If I'm not mistaken, this name field corresponds to the name entry in the SNDCTL_AUDIOINFO ioctl. OSSv4 defines it as follows:

A string that contains the "full" description of the device.

This sounds like it should be presentable to normal users and help them to identify the device.
Could you verify that this string is actually used in GUIs like VLC? I don't have Xorg running on CURRENT.

• s/sound_glob_init()/sound_global_init()/
• Move indendation fix to separate patch: D46856

Address Mark's comments.

In D46836#1067926, @dev_submerge.ch wrote:

This makes sysctl hw.snd.verbose=2; cat /dev/sndstat harder to read, and we lose the ability to grep for play, record and virtual there. Also I think this is shown verbatim in GUIs like VLC, do we expect normal users to understand the subtle notion of [v]p|r?

In D46845#1067932, @dev_submerge.ch wrote:

LGTM, I suppose this is save when called through SYSINIT?

Fix.

I accidentally posted a draft patch, which contained some errors. Will re-submit the correct one soon.

Move to separate function.

In D46680#1066259, @dev_submerge.ch wrote:

@dev_submerge.ch Any comments? As I mention in the commit message, wanting to sort in descending order (and as a result, breaking the mechanism proposed in D46550) is highly unlikely, but I think it's good to be on the safe side.

Using existing KPI is a plus, but the *_unr() is quite complex. It introduces another mutex and additional allocations in our case. Regarding the issue discussed in D46520, this makes the runtime implications non-obvious. We'll have to test that. Also this change trades the list order requirement in for the complexity of an additional unr allocation that we must not leak.

In D46520#1066199, @dev_submerge.ch wrote:

In D46520#1064256, @dev_submerge.ch wrote:

I suspect the traversal of the channel list to have an impact. If we traverse it for every allocation, and the list getting longer, we get O(N^2) for N allocations. That should be easy to prove by doing a benchmark of allocations with few vchans and compare that to situations with 1'000, 10'000 and 100'000 preallocated vchans.

Some brief tests seem to support this theory, we have a scaling problem. Allocating 1000 vchans from 0 is almost instantaneous, while allocating from 100000 to 101000 takes about 10 seconds.

I think even without preallocation, we still need some hard upper bound for the number of vchans, like @olce proposed. 10ms per allocation can already be problematic for multimedia applications. And we should have a close look at how we deallocate the vchans again.

s/hypervisor/ppt/