svn commit: r298585 - in head: sys/kern usr.sbin/jail

[Conrad Meyer]

I'll borrow my explanation from the NTB review:

There is the sbuf itself, and there is some buffer for data. Either
can be on the stack or the heap independently. This is controlled with
the DYNSTRUCT and DYNAMIC flags respectively.

sbuf_new() just initializes an sbuf. Depending on the inputs passed in
to it, it can allocate an sbuf on the heap (setting DYNSTRUCT) or not,
and allocate a buffer on the heap (setting DYNAMIC) or not.

Coverity is specifically complaining about freeing the sbuf memory
itself—not the heap buffer. Since this sbuf was initialized as *not*
DYNSTRUCT, sbuf_delete will never free the sbuf memory itself. This is
purely a false positive.

So, any stack sbuf will pass a non-NULL pointer to sbuf-new, making it
!DYNSTRUCT.  sbuf_delete on this pointer is valid because it won't try
to free a !DYNSTRUCT sbuf.  Coverity warns about it because it doesn't
understand the 1:1 relationship between stack sbufs and DYNSTRUCT.

Best,
Conrad


On Tue, Apr 26, 2016 at 1:45 PM, Ulrich Spörlein <uspoerlein at gmail.com> wrote:
> On Apr 26, 2016 11:44 AM, "Conrad Meyer" <cem at freebsd.org> wrote:
>>
>> Right.  False positive.  Coverity doesn't grok sbuf memory management
>> fully.
>>
>
> If someone can explain it to me in very simple words, I can update the model
> to make these go away ... maybe.