kern/56947: audio(4) may fail uobj allocation under VA fragmentation/preassure

[martin%NetBSD.org@localhost]

>Number:         56947
>Category:       kern
>Synopsis:       audio(4) may fail uobj allocation under VA fragmentation/preassure
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul 30 15:05:01 +0000 2022
>Originator:     Martin Husemann
>Release:        NetBSD 9.99.99
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD big-apple.aprisoft.de 9.99.99 NetBSD 9.99.99 (POWERMAC_G5.MP) #65: Thu Jul 28 16:26:57 CEST 2022 martin%seven-days-to-the-wolves.aprisoft.de@localhost:/work/src/sys/arch/macppc/compile/POWERMAC_G5.MP macppc
Architecture: powerpc
Machine: macppc
>Description:

On a 32bit kernel with limited VA and the machine under heavy load (like
building pkgs) audio(4) sometimes fails with this printf
(sys/dev/audio/audio.c line 4701:

        if (track->usrbuf_blksize != oldblksize) {
                error = audio_realloc_usrbuf(track, newbufsize);
                if (error) {
                        device_printf(sc->sc_dev, "malloc usrbuf(%d) failed\n",
                            newbufsize);
                        goto error;
                }
        }

and the userland audio app aborts. The "newbufsize" printed is always
the maximum (64k) for me.

I added some instrumentation around audio_realloc_usrbuf and for a typical
playback of a single song I get:

[ 26185.7526103] audio0: play format changing: 0/0/0/0 -> 8000/1/8/8
[ 26185.7526103] audio0: block size changes from 0 to 512
[ 26185.7526103] audio0: play format changing: 8000/1/8/8 -> 48000/7/16/16
[ 26185.7526103] audio0: block size changes from 512 to 12288
[ 26185.7626097] audio0: play format changing: 48000/7/16/16 -> 4800
[ 26185.8226099] audio0: play format changing: 0/0/0/0 -> 8000/1/8/8
[ 26185.8226099] audio0: block size changes from 0 to 512
[ 26185.8226099] audio0: play format changing: 8000/1/8/8 -> 48000/7/16/16
[ 26185.8226099] audio0: block size changes from 512 to 12288
[ 26185.8226099] audio_free_usrbuf: freeing usrbuf

That is quite a bit of unecessary (re-)allocations.

>How-To-Repeat:
s/a

>Fix:

I wonder if we:

 a) could defer allocation untill the mmap actually happens (so the interim
    variants like the default 8k ulaw that is never really used avoid it
    completely)
 b) keep the uobj (and all allocations for it) around (i.e. not free
    it on close) so we stick with a single 64k uobj for each audio
    that is ever used at least once and never need to allocate anythin
    on later open/uses