From owner-svn-src-head@freebsd.org Tue Apr 26 20:50:47 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BA57B1DDDF; Tue, 26 Apr 2016 20:50:47 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-ob0-f194.google.com (mail-ob0-f194.google.com [209.85.214.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E488F133B; Tue, 26 Apr 2016 20:50:46 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-ob0-f194.google.com with SMTP id tz8so1709723obc.1; Tue, 26 Apr 2016 13:50:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-transfer-encoding; bh=snunI3tmyyRvYroQ2EbcYs+kymFRZxrpUBEn1gBgvDU=; b=d+ci8xjy9bmxcaRFSFpEiNi7cOAGH/cvSzQ13PAjgXB4G7O8blDZv/0cxwEjnK+qYc V/4DC9+G+LloON3+HMyDGzvz9VdO8AqkuExwlfbmtzqRwVv89FtlufRNf3QWlL7gCbjX GV31kx54jkVe1/geQvOudx3uvz/Of7/Zad0ZuIq3jLB/4258le5I6Bc8L0IAVmC24fwP icjZEGocm3rVnPwrdLLvNAW/aGWcX2cVghCK1WrgRouWK/1C4GczSaJNUQSeFwHxXsNS MIjXheerY3kwTQmFnmua54mWc1+7KjxPH6QaWUZDdPUErTRqlf2YvZv/3/FwR8D735L6 75dg== X-Gm-Message-State: AOPr4FW5C0r+6Y3h9ScYGKu9lhvZqa9Gk/MZQLNddUPSRFAA4EHeECsYlaSI2onkOsvGJQ== X-Received: by 10.60.50.194 with SMTP id e2mr1912471oeo.57.1461703840428; Tue, 26 Apr 2016 13:50:40 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com. [209.85.218.48]) by smtp.gmail.com with ESMTPSA id c62sm257007oig.13.2016.04.26.13.50.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Apr 2016 13:50:40 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id r78so28617753oie.0; Tue, 26 Apr 2016 13:50:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.215.86 with SMTP id o83mr1755572oig.55.1461703839777; Tue, 26 Apr 2016 13:50:39 -0700 (PDT) Reply-To: cem@FreeBSD.org Received: by 10.157.6.111 with HTTP; Tue, 26 Apr 2016 13:50:39 -0700 (PDT) In-Reply-To: References: <201604251706.u3PH6okj031018@repo.freebsd.org> Date: Tue, 26 Apr 2016 13:50:39 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r298585 - in head: sys/kern usr.sbin/jail From: Conrad Meyer To: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, NGie Cooper , src-committers@freebsd.org, Jamie Gritton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 20:50:47 -0000 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 wrote: > On Apr 26, 2016 11:44 AM, "Conrad Meyer" 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.