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>
next prev parent 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).