From: Dan Williams <dan.j.williams@intel.com>
To: Alison Schofield <alison.schofield@intel.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Kwangjin Ko <kwangjin.ko@sk.com>, <dave@stgolabs.net>,
<dave.jiang@intel.com>, <vishal.l.verma@intel.com>,
<ira.weiny@intel.com>, <dan.j.williams@intel.com>,
<linux-cxl@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<kernel_team@skhynix.com>
Subject: Re: [PATCH v2 1/1] cxl/core: Fix initialization of mbox_cmd.size_out in get event
Date: Fri, 5 Apr 2024 10:45:05 -0700 [thread overview]
Message-ID: <661038a136a79_1578629429@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <ZhA25pRuyiHJWcLj@aschofie-mobl2>
Alison Schofield wrote:
[..]
> My thought was 2) device bug. Bad device is returning payload length
> that exceeds what pci/cxl-driver can consume, so gets ignored. Am I
> worrying about debugging the hardware needlessly?
I would not go so far as to say "needlessly", but the number of fun and
interesting ways that hardware can violate software expectations is
myriad, so it will always be game of after-the-fact quirks and fixups.
A payload truncation would seem to fail safely in the sense of no buffer
overrun and no stale data exposure. Still a bug, but no riskier than all
the other potential hardware bugs / spec violations.
prev parent reply other threads:[~2024-04-05 17:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 8:14 [PATCH v2 0/1] cxl/core: Fix initialization of mbox_cmd.size_out in get event Kwangjin Ko
2024-04-02 8:14 ` [PATCH v2 1/1] " Kwangjin Ko
2024-04-02 14:38 ` Jonathan Cameron
2024-04-02 16:25 ` Ira Weiny
2024-04-03 14:53 ` Dan Williams
2024-04-04 13:30 ` Jonathan Cameron
2024-04-04 17:35 ` Dan Williams
2024-04-04 20:20 ` Ira Weiny
2024-04-05 16:04 ` Alison Schofield
2024-04-05 16:40 ` Jonathan Cameron
2024-04-05 17:37 ` Alison Schofield
2024-04-05 17:45 ` Dan Williams [this message]
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=661038a136a79_1578629429@dwillia2-mobl3.amr.corp.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.com \
--cc=kernel_team@skhynix.com \
--cc=kwangjin.ko@sk.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vishal.l.verma@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 read-only IMAP folder(s) and NNTP newsgroup(s).