All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ric Wheeler <rwheeler@redhat.com>
To: Sage Weil <sweil@redhat.com>, Gregory Farnum <greg@inktank.com>
Cc: Loic Dachary <loic@dachary.org>,
	"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
	Jeff Darcy <jdarcy@redhat.com>, Kaleb Keithley <kaleb@redhat.com>
Subject: Re: New Defects reported by Coverity Scan for ceph (fwd)
Date: Tue, 30 Sep 2014 13:41:46 -0400	[thread overview]
Message-ID: <542AEB5A.9070804@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1409301037300.17090@cobra.newdream.net>

On 09/30/2014 01:38 PM, Sage Weil wrote:
> On Tue, 30 Sep 2014, Gregory Farnum wrote:
>> On Tue, Sep 30, 2014 at 6:59 AM, Sage Weil <sweil@redhat.com> wrote:
>>> Looks like recent changes from Greg, Loic, and I.
>>>
>>> ---------- Forwarded message ----------
>>> From: scan-admin@coverity.com
>>> To: undisclosed-recipients:;
>>> Cc:
>>> Date: Tue, 30 Sep 2014 06:21:08 -0700
>>> Subject: New Defects reported by Coverity Scan for ceph
>>>
>>>
>>> Hi,
>>>
>>>
>>> Please find the latest report on new defect(s) introduced to ceph found with Coverity Scan.
>>>
>>> Defect(s) Reported-by: Coverity Scan
>>> Showing 4 of 4 defect(s)
>>>
>>>
>>> ** CID 1242019:  Data race condition  (MISSING_LOCK)
>>> /msg/Pipe.cc: 230 in Pipe::DelayedDelivery::entry()()
>>>
>>> ** CID 1242021:  Resource leak  (RESOURCE_LEAK)
>>> /test/librados/tier.cc: 1026 in LibRadosTwoPoolsPP_EvictSnap2_Test::TestBody()()
>>> /test/librados/tier.cc: 1022 in LibRadosTwoPoolsPP_EvictSnap2_Test::TestBody()()
>>> /test/librados/tier.cc: 1040 in LibRadosTwoPoolsPP_EvictSnap2_Test::TestBody()()
>>> /test/librados/tier.cc: 1037 in LibRadosTwoPoolsPP_EvictSnap2_Test::TestBody()()
>>>
>>> ** CID 1242020:  Resource leak  (RESOURCE_LEAK)
>>> /test/librados/aio.cc: 168 in LibRadosAio_TooBig_Test::TestBody()()
>>>
>>> ** CID 1242018:  Resource leak  (RESOURCE_LEAK)
>>> /test/librados/aio.cc: 188 in LibRadosAio_TooBigPP_Test::TestBody()()
>>> /test/librados/aio.cc: 190 in LibRadosAio_TooBigPP_Test::TestBody()()
>>> /test/librados/aio.cc: 187 in LibRadosAio_TooBigPP_Test::TestBody()()
>>>
>>>
>>> ________________________________________________________________________________________________________
>>> *** CID 1242019:  Data race condition  (MISSING_LOCK)
>>> /msg/Pipe.cc: 230 in Pipe::DelayedDelivery::entry()()
>>> 224         if (flush_count > 0) {
>>> 225           --flush_count;
>>> 226           active_flush = true;
>>> 227         }
>>> 228         if (pipe->in_q->can_fast_dispatch(m)) {
>>> 229           if (!stop_fast_dispatching_flag) {
>>>>>>      CID 1242019:  Data race condition  (MISSING_LOCK)
>>>>>>      Accessing "this->delay_dispatching" without holding lock "Mutex._m". Elsewhere, "_ZN4Pipe15DelayedDeliveryE.delay_dispatching" is accessed with "Mutex._m" held 1 out of 2 times (1 of these accesses strongly imply that it is necessary).
>>> 230             delay_dispatching = true;
>>> 231             delay_lock.Unlock();
>>> 232             pipe->in_q->fast_dispatch(m);
>>> 233             delay_lock.Lock();
>>> 234             delay_dispatching = false;
>>> 235             if (stop_fast_dispatching_flag) {
>> This one's a false positive. (delay_dispatching is protected by the
>> delay_lock, but I think it's picking up on the Pipe::lock which is
>> held when DelayedDelivery is constructed and initialized.) Is there a
>> way I should annotate this, or is it something we need to adjust in
>> the Coverity web interface?
> There are annotations but I don't know how they work.  I've been marking
> them through the web interface...
>
> sage
>

Jeff and Kaleb (last I remember) had more expertise in coverity magic - they 
might know how to annotate those false positives...

ric


  reply	other threads:[~2014-09-30 17:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-30 13:59 New Defects reported by Coverity Scan for ceph (fwd) Sage Weil
2014-09-30 17:26 ` Loic Dachary
2014-09-30 17:36 ` Gregory Farnum
2014-09-30 17:38   ` Sage Weil
2014-09-30 17:41     ` Ric Wheeler [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-10-08 14:59 Sage Weil
2014-09-25 15:02 Sage Weil
2014-09-25 15:27 ` John Spray
2014-09-16 21:44 Sage Weil
2014-08-23 16:04 Sage Weil
2014-07-11  3:39 Sage Weil
2014-06-20 14:46 Sage Weil
2014-06-07 16:12 Sage Weil
2014-06-08  8:38 ` Sebastien Ponce
2014-06-18  7:37 ` Sebastien Ponce
2014-06-06 15:54 Sage Weil
2014-05-30 13:54 Sage Weil
2014-05-20 16:16 Sage Weil
2014-05-10 16:03 Sage Weil
2014-04-22 15:26 Sage Weil
2014-04-12  4:06 Sage Weil
2014-04-12  8:26 ` Loic Dachary
2014-03-03 22:23 Sage Weil
2014-03-03 22:53 ` John Spray
2014-03-04  0:53   ` Li Wang
2013-12-17 17:10 Sage Weil
2013-12-16 16:07 Sage Weil
2013-12-17  9:01 ` Ilya Dryomov
2013-08-21  4:09 Sage Weil
2013-07-25 20:31 Sage Weil
2013-07-19 18:04 Sage Weil
2013-06-19 19:36 Sage Weil
2013-06-19 21:03 ` Loic Dachary

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=542AEB5A.9070804@redhat.com \
    --to=rwheeler@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=greg@inktank.com \
    --cc=jdarcy@redhat.com \
    --cc=kaleb@redhat.com \
    --cc=loic@dachary.org \
    --cc=sweil@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.