Date: Tue, 26 Apr 2016 13:50:39 -0700 From: Conrad Meyer <cem@FreeBSD.org> To: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= <uspoerlein@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, NGie Cooper <yaneurabeya@gmail.com>, src-committers@freebsd.org, Jamie Gritton <jamie@freebsd.org> Subject: Re: svn commit: r298585 - in head: sys/kern usr.sbin/jail Message-ID: <CAG6CVpXLRKgKGsmce_YEd5pKbUhWcnpzVQq%2Bc8uj7VUMvar28w@mail.gmail.com> In-Reply-To: <CAJ9axoTN40JHAbj06kU8iRoJSOj3p=HhWGuHvBBz4HLyLiJuPQ@mail.gmail.com> References: <201604251706.u3PH6okj031018@repo.freebsd.org> <CAJ9axoQq6ZY1ys5FVzDFv%2Bpu1JZVaF=eQQ1UNwo9YC_-QKewPg@mail.gmail.com> <CA043211-34D4-4562-86A1-F737F8ED1550@gmail.com> <CAG6CVpU2BwQtCcavz0Vj0f=o44q4LD0LiCLc_WPsPTWH5jVFQQ@mail.gmail.com> <CAJ9axoTN40JHAbj06kU8iRoJSOj3p=HhWGuHvBBz4HLyLiJuPQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=E2=80=94not 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=C3=B6rlein <uspoerlein@gmail.com= > wrote: > On Apr 26, 2016 11:44 AM, "Conrad Meyer" <cem@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 mo= del > to make these go away ... maybe.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpXLRKgKGsmce_YEd5pKbUhWcnpzVQq%2Bc8uj7VUMvar28w>