Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Srirangan Madhavan <smadhavan@nvidia.com>
To: Dave Jiang <dave.jiang@intel.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Ira Weiny <ira.weiny@intel.com>,
	Jonathan Cameron <jic23@kernel.org>,
	Vishal Verma <vishal.l.verma@intel.com>,
	linux-cxl@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: Alex Williamson <alex.williamson@redhat.com>,
	vsethi@nvidia.com, alwilliamson@nvidia.com,
	Sai Yashwanth Reddy Kancherla <skancherla@nvidia.com>,
	Vishal Aslot <vaslot@nvidia.com>,
	Manish Honap <mhonap@nvidia.com>, Jiandi An <jan@nvidia.com>,
	Richard Cheng <icheng@nvidia.com>,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH v10 07/12] cxl: Validate HDM ranges before CXL reset
Date: Tue, 1 Sep 2026 21:39:05 -0700	[thread overview]
Message-ID: <95385898-6e8b-4eef-9135-23605feea614@nvidia.com> (raw)
In-Reply-To: <2b6302e6-18e6-42de-9489-014c4beb25c4@intel.com>

On 8/25/26 1:30 PM, Dave Jiang wrote:
>> +                 range->hpa_range.end == hpa_range->end)
> I think range_contains() would work here?

  Wouldn’t range_contains() also match a subrange? Is it okay to treat a 
contained but non-identical decoder range as a duplicate as well?

>> +                     return 0;
>> +
>> +     range = kzalloc_obj(*range);
>> +     if (!range)
>> +             return -ENOMEM;
>> +
>> +     range->pdev = pdev;
>> +     range->hpa_range = *hpa_range;
>> +     list_add_tail(&range->list, &ctx->ranges);
>> +
>> +     return 0;
>> +}
>> +
>> +static int cxl_hdm_ranges_collect(struct cxl_hdm_range_context *ctx,
>> +                               struct pci_dev *pdev)
>> +{
>> +     struct cxl_hdm_info *info;
>> +     int rc;
>> +
>> +     guard(rwsem_read)(&cxl_rwsem.dpa);
>> +     info = pdev->hdm;
>> +     if (!info) {
>> +             pci_err(pdev, "CXL HDM decoder state unavailable\n");
>> +             return -ENXIO;
>> +     }
>> +
>> +     for (int i = 0; i < info->decoder_count; i++) {
>> +             struct cxl_decoder_settings *settings = &info->settings[i];
>> +
>> +             if (!(settings->flags & CXL_DECODER_F_ENABLE))
>> +                     continue;
>> +
>> +             if (settings->flags & CXL_DECODER_F_NORMALIZED_ADDRESSING) {
>> +                     pci_err(pdev,
>> +                             "CXL reset does not support normalized address decoders\n");
>> +                     return -EOPNOTSUPP;
>> +             }
>> +
>> +             rc = cxl_hdm_range_add(ctx, pdev, &settings->hpa_range);
>> +             if (rc)
>> +                     return rc;
>> +     }
>> +
>> +     return 0;
>> +}
>> +
>> +static int cxl_hdm_range_len(struct pci_dev *pdev,
>> +                          const struct range *hpa_range, u64 *len)
>> +{
>> +     if (hpa_range->end < hpa_range->start)
>> +             return -EINVAL;
>> +
>> +     if (hpa_range->start > RESOURCE_SIZE_MAX ||
>> +         hpa_range->end > RESOURCE_SIZE_MAX) {
> Given that above you established that (end >= start) couple lines above, you really only need to test end here.
> 
>> +             pci_err(pdev,
>> +                     "CXL reset range [%#llx-%#llx] exceeds resource address size\n",
>> +                     hpa_range->start, hpa_range->end);
>> +             return -EOVERFLOW;
>> +     }
>> +
>> +     *len = range_len(hpa_range);
>> +     if (!*len || *len > RESOURCE_SIZE_MAX) {
>> +             pci_err(pdev,
>> +                     "CXL reset range [%#llx-%#llx] exceeds resource size\n",
>> +                     hpa_range->start, hpa_range->end);
>> +             return -EOVERFLOW;
>> +     }
>> +
>> +     if (*len > SIZE_MAX) {
>> +             pci_err(pdev,
>> +                     "CXL reset range [%#llx-%#llx] exceeds cache flush size\n",
>> +                     hpa_range->start, hpa_range->end);
>> +             return -EOVERFLOW;
>> +     }
>> +
>> +     return 0;
>> +}
> This function is doing too much. I suggest you rename it cxl_hdm_range_validate() and drop the *len parameter. And just assign len from range_len(hpa_range) once it's validated. I'll paste a diff at the end as a suggestion.

  I applied this refactor in v11: the helper is now 
cxl_hdm_range_validate(), it no longer has a len output parameter, and 
the caller assigns range_len() after validation.

> 
>> +
>> +static int cxl_hdm_range_request(struct cxl_hdm_range *range)
>> +{
>> +     struct pci_dev *pdev = rang


-- 
Regards,
Srirangan

  reply	other threads:[~2026-09-02  4:39 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 19:29 [PATCH v10 00/12] PCI/CXL: Add CXL reset support for Type 2 devices Srirangan Madhavan
2026-08-04 19:29 ` [PATCH v10 01/12] cxl: Move HDM decoder programming helpers Srirangan Madhavan
2026-08-04 19:46   ` sashiko-bot
2026-08-05  2:13   ` Alison Schofield
2026-09-02  0:52     ` Srirangan Madhavan
2026-08-20 21:13   ` Dave Jiang
2026-08-24  7:11   ` Li Ming
2026-08-24  7:19     ` Li Ming
2026-09-02  1:18       ` Srirangan Madhavan
2026-08-04 19:29 ` [PATCH v10 02/12] cxl: Pass decoder settings to HDM commit helpers Srirangan Madhavan
2026-08-04 19:49   ` sashiko-bot
2026-08-20 22:21   ` Dave Jiang
2026-09-02  1:51     ` Srirangan Madhavan
2026-08-24  7:33   ` Li Ming
2026-09-02  1:53     ` Srirangan Madhavan
2026-08-04 19:29 ` [PATCH v10 03/12] cxl: Share HDM decoder decode logic Srirangan Madhavan
2026-08-04 19:45   ` sashiko-bot
2026-08-20 23:25   ` Dave Jiang
2026-09-02  1:58     ` Srirangan Madhavan
2026-09-02  2:06     ` Srirangan Madhavan
2026-08-04 19:29 ` [PATCH v10 04/12] cxl: Cache decoder settings on PCI devices Srirangan Madhavan
2026-08-04 19:40   ` sashiko-bot
2026-08-21 22:12   ` Dave Jiang
2026-09-02  2:12     ` Srirangan Madhavan
2026-08-24  7:53   ` Li Ming
2026-09-02  2:13     ` Srirangan Madhavan
2026-08-04 19:29 ` [PATCH v10 05/12] cxl: Cache endpoint decoder settings during PCI enumeration Srirangan Madhavan
2026-08-04 19:51   ` sashiko-bot
2026-08-05  2:28   ` Alison Schofield
2026-09-02  2:14     ` Srirangan Madhavan
2026-08-17  5:30   ` Richard Cheng
2026-09-02  2:23     ` Srirangan Madhavan
2026-08-21 23:33   ` Dave Jiang
2026-09-02  2:30     ` Srirangan Madhavan
2026-08-25  6:58   ` Li Ming
2026-09-02  2:48     ` Srirangan Madhavan
2026-08-26 18:30   ` Lucero Palau, Alejandro
2026-09-02  3:22     ` Srirangan Madhavan
2026-08-04 19:29 ` [PATCH v10 06/12] cxl: Add CXL Device Reset helper Srirangan Madhavan
2026-08-04 19:42   ` sashiko-bot
2026-08-24 22:24   ` Dave Jiang
2026-08-26 18:09   ` Lucero Palau, Alejandro
2026-09-02  3:52     ` Srirangan Madhavan
2026-08-04 19:29 ` [PATCH v10 07/12] cxl: Validate HDM ranges before CXL reset Srirangan Madhavan
2026-08-04 19:38   ` sashiko-bot
2026-08-25 20:30   ` Dave Jiang
2026-09-02  4:39     ` Srirangan Madhavan [this message]
2026-08-04 19:29 ` [PATCH v10 08/12] cxl: Reject CXL Reset on multifunction devices Srirangan Madhavan
2026-08-04 19:40   ` sashiko-bot
2026-08-25 20:32   ` Dave Jiang
2026-08-26 18:47   ` Lucero Palau, Alejandro
2026-09-02  4:52     ` Srirangan Madhavan
2026-08-04 19:29 ` [PATCH v10 09/12] cxl: Restore CXL HDM state after PCI reset Srirangan Madhavan
2026-08-04 19:44   ` sashiko-bot
2026-08-17  7:12   ` Richard Cheng
2026-09-02  5:17     ` Srirangan Madhavan
2026-08-04 19:29 ` [PATCH v10 10/12] PCI/CXL: Expose CXL Reset as a PCI reset method Srirangan Madhavan
2026-08-04 20:00   ` sashiko-bot
2026-08-04 19:29 ` [PATCH v10 11/12] Documentation/ABI: Document CXL Reset " Srirangan Madhavan
2026-08-04 19:41   ` sashiko-bot
2026-08-04 19:29 ` [PATCH v10 12/12] PCI/CXL: Restore HDM state after CXL bus reset Srirangan Madhavan
2026-08-04 19:59   ` sashiko-bot
2026-08-13  9:35 ` [PATCH v10 00/12] PCI/CXL: Add CXL reset support for Type 2 devices Alejandro Lucero Palau
2026-08-25 21:13 ` Dave Jiang
2026-09-02  5:11   ` Srirangan Madhavan

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=95385898-6e8b-4eef-9135-23605feea614@nvidia.com \
    --to=smadhavan@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=alison.schofield@intel.com \
    --cc=alwilliamson@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=icheng@nvidia.com \
    --cc=ira.weiny@intel.com \
    --cc=jan@nvidia.com \
    --cc=jic23@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mhonap@nvidia.com \
    --cc=skancherla@nvidia.com \
    --cc=vaslot@nvidia.com \
    --cc=vishal.l.verma@intel.com \
    --cc=vsethi@nvidia.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