possible bug in the sbappendrecord_locked()? (Was: Re: core dump with bluetooth device)

[Maksim Yevmenkin]

On Thu, Apr 23, 2009 at 1:56 AM, pluknet <pluknet at gmail.com> wrote:
> 2009/4/18 pluknet <pluknet at gmail.com>:
>> 2009/4/17 Maksim Yevmenkin <maksim.yevmenkin at gmail.com>:
>>>
> [snip]
>>>
>>> ok, this is completely untested, so be warned :) would something like
>>> the following  work? am i missing something?
>>
>> I'm on vacations and will not able to test it until after 4/23. :(
>>
>
> So, come back now.
>
> Works for me (tm) on stable/7 with SOCKBUF_DEBUG enabled.
> (writing this message currently via ng_ubt(4)).
> Please, commit.

thanks! i've committed slightly different patch to -head, but the idea
is still the same.

===

SVN rev 191366 on 2009-04-21 19:14:13Z by emax

Fix sbappendrecord_locked().

The main problem is that sbappendrecord_locked() relies on sbcompress()
to set sb_mbtail. This will not happen if sbappendrecord_locked() is
called with mbuf chain made of exactly one mbuf (i.e. m0->m_next == NULL).
In this case sbcompress() will be called with m == NULL and will do
nothing. I'm not entirely sure if m == NULL is a valid argument for
sbcompress(), and, it rather pointless to call it like that, but keep
calling it so it can do SBLASTMBUFCHK().

The problem is triggered by the SOCKBUF_DEBUG kernel option that
enables SBLASTRECORDCHK() and SBLASTMBUFCHK() checks.

PR:			kern/126742
Investigated by:	pluknet < pluknet -at- gmail -dot- com >
No response from:	freebsd-current@, freebsd-bluetooth@
MFC after:		3 days

==

thanks,
max