From: 黄高彬 <huanggaobin23@semi.ac.cn>
To: "Alison Schofield" <alison.schofield@intel.com>
Cc: linux-cxl@vger.kernel.org, "Davidlohr Bueso" <dave@stgolabs.net>,
"Jonathan Cameron" <jic23@kernel.org>,
"Dave Jiang" <dave.jiang@intel.com>,
"Vishal Verma" <vishal.l.verma@intel.com>,
"Dan Williams" <djbw@kernel.org>,
"Ira Weiny" <iweiny@kernel.org>,
"Li Ming" <ming.li@zohomail.com>,
"Richard Cheng" <icheng@nvidia.com>,
linux-kernel@vger.kernel.org
Subject: Re: Re: [PATCH] cxl/mbox: bound the device-supplied command return code
Date: Wed, 14 Oct 2026 22:48:51 +0800 (GMT+08:00) [thread overview]
Message-ID: <49ee762d.402bc.1a13ae337d6.Coremail.huanggaobin23@semi.ac.cn> (raw)
In-Reply-To: <as7cid_6QQS5gBI-@aschofie-mobl2.lan>
Hi Alison,
Thank you for picking it up, and for the corrections.
> (Sashiko is right here. PADDR and POISONLMT don't map to -ENXIO, so the
> comment and changelog claim isn't accurate. -ENXIO is still the right
> fallback for an unknown code.)
You are both right: the claim should be that an unknown code is still a failure
and that -ENXIO keeps it in the usual device-error class -- not that every
non-success entry maps to -ENXIO. Please use that wording in the version you
carry; I will not repost the patch on its own.
> I'm taking this into a series that adds CXL KUnit tests, including a
> regression test for this table. You'll get CC'd when it posts and I'll need
> you ACK it since it has your original authorship with changes from me added.
Understood -- I will ACK as soon as it posts.
> It looks like the return code you saw is valid for CXL 4.0 and just not added
> to CXL driver yet. ... CXL 4.0, Table 8-208 ... 001Fh and 0020h
> I don't think anyone else has sent a patch for that yet, so you can if you
> like.
Two things there, and I would rather not collide with your series:
- The KASAN reproduction used 0x1f, which stops being out of range once 001Fh is
in the table. Out of range is any code past the end of the table, so with
001Fh and 0020h added it is 0021h upwards -- the bound itself is unchanged.
- Adding the two entries is a separate change from the bound. Do you want it in
your series next to the KUnit test, so the boundary and the test move
together, or as a standalone patch from me after yours? Either is fine. If
you would rather have it from me, I will take the names and errno mappings
from Table 8-208 and send it separately.
Thanks,
Gaobin
next prev parent reply other threads:[~2026-10-14 14:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 6:07 Gaobin Huang
2026-10-14 1:36 ` Alison Schofield
2026-10-14 14:48 ` 黄高彬 [this message]
2026-10-14 21:39 ` Alison Schofield
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=49ee762d.402bc.1a13ae337d6.Coremail.huanggaobin23@semi.ac.cn \
--to=huanggaobin23@semi.ac.cn \
--cc=alison.schofield@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=djbw@kernel.org \
--cc=icheng@nvidia.com \
--cc=iweiny@kernel.org \
--cc=jic23@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.li@zohomail.com \
--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
all inboxes | Powered by JetHome®