Re: git: 9d18115ca0ab - main - sound: Retire snd_mtx* wrappers

On Sat Nov 22, 2025 at 12:54 AM CET, Shawn Webb wrote:
> On Sat, Nov 22, 2025 at 12:50:19AM +0100, Christos Margiolis wrote:
>> On Fri Nov 21, 2025 at 9:46 PM CET, Shawn Webb wrote:
>> > On Fri, Nov 21, 2025 at 08:45:27PM +0000, Shawn Webb wrote:
>> >> On Fri, Nov 21, 2025 at 04:15:03PM +0000, Christos Margiolis wrote:
>> >> > The branch main has been updated by christos:
>> >> > 
>> >> > URL: https://cgit.FreeBSD.org/src/commit/?id=9d18115ca0ab0ef3f34173d4e2bdabec916d0b60
>> >> > 
>> >> > commit 9d18115ca0ab0ef3f34173d4e2bdabec916d0b60
>> >> > Author:     Christos Margiolis <christos@FreeBSD.org>
>> >> > AuthorDate: 2025-11-21 16:14:33 +0000
>> >> > Commit:     Christos Margiolis <christos@FreeBSD.org>
>> >> > CommitDate: 2025-11-21 16:14:47 +0000
>> >> > 
>> >> >     sound: Retire snd_mtx* wrappers
>> >> >     
>> >> >     Do not create mutexes with snd_mtxcreate(). It doesn't provide any
>> >> >     value, plus it first allocates the mutex with malloc(9). Allocate
>> >> >     mutexes in the stack and use mtx_* functions directly instead of the
>> >> >     snd_mtx* wrappers.
>> >> >     
>> >> >     Sponsored by:   The FreeBSD Foundation
>> >> >     MFC after:      1 week
>> >> >     Reviewed by:    kib, markj
>> >> >     Differential Revision:  https://reviews.freebsd.org/D53855
>> >> 
>> >> Hey Christos,
>> >> 
>> >> I'm getting the following error on buildkernel:
>> >> 
>> >> ==== BEGIN LOG ====
>> >> /usr/src/sys/dev/sound/pci/hdspe-pcm.c:726:3: error: call to undeclared function 'snd_mtxunlock'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration]
>> >>   726 |                 snd_mtxunlock(sc->lock);
>> >>       |                 ^
>> >> 1 error generated.
>> >> --- hdspe-pcm.o ---
>> >> ==== END LOG ====
>> >
>> > Never mind. I didn't realize HardenedBSD had a change to that file.
>> > Sorry for the noise!
>> 
>> So all good? Out of curiousity, what change is there on HardenedBSD?
>
> Yeah, all good. There's a potential NULL pointer dereference due to a
> lack of a return value check from malloc(..., M_NOWAIT). I haven't
> done any determination as to whether the bug is triggerable, but it
> exists nonetheless.
>
> Thanks,

I'll look into it. Thanks.

Christos