DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Yong Liang <1269690261@qq.com>
Cc: kai.ji@intel.com, dev@dpdk.org
Subject: Re: [PATCH] Coverity issue: Failure to enqueue packets for cryptodev-scheduler_multicore can lead to program crashes Bugzilla ID: 1537 Fixes: replace `pending_deq_ops` with `pending_enq_ops` Cc: stable@dpdk.org
Date: Mon, 9 Sep 2024 10:12:37 -0700	[thread overview]
Message-ID: <20240909101237.09c4caaa@hermes.local> (raw)
In-Reply-To: <tencent_2B74A585963C1CDA8C52C45C6236CA934705@qq.com>

On Tue, 10 Sep 2024 00:48:22 +0800
Yong Liang <1269690261@qq.com> wrote:

> Signed-off-by: Yong Liang <1269690261@qq.com>

This is not the correct way to put the covertity and bugzilla information into the patch.
The infrastruture expects:

1. Put the short description in the Subject line of the email.

2. Add a longer description of what the problem is in the git commit
log (body of the email)

3. Put the Coverity Issue in as a line before the Signed-off-by in the commit log.

4. Put the Bugzilla ID in as line before the Signed-off-by

5. Put the Fixes line in before the Signed-off-by

Example:

commit 429219adab185909a8127e680d19f7628af62fb2
Author: Anatoly Burakov <anatoly.burakov@intel.com>
Date:   Fri Jul 12 12:41:35 2024 +0100

    malloc: fix multi-process wait condition handling
    
    From coverity's point of view, it is theoretically possible to have an
    infinite wait on a wait condition because while we do check for timeout,
    we do not check for whether the event we are waiting for has already
    occurred by the time we get to the first cond_wait call (in this case,
    it's state of memory request list entry's state being set to COMPLETE).
    
    This can't really happen as the only time a wait condition is triggered
    is when we are receiving a memory event (so the entry we are waiting on
    cannot change before wait condition is triggered because it's protected
    by a mutex), so either we receive an event and modify entry state, or we
    exit wait on a timeout and do not care about request state. However, it's
    better to keep coverity happy.
    
    Coverity issue: 425709
    Fixes: 07dcbfe0101f ("malloc: support multiprocess memory hotplug")
    Cc: stable@dpdk.org
    
    Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>


	

  reply	other threads:[~2024-09-09 17:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-09 16:48 Yong Liang
2024-09-09 17:12 ` Stephen Hemminger [this message]
2024-09-09 16:57 Yong Liang

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=20240909101237.09c4caaa@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=1269690261@qq.com \
    --cc=dev@dpdk.org \
    --cc=kai.ji@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).