Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mallesh Koujalagi" <mallesh.koujalagi@intel.com>,
	intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2 4/6] drm/xe/cper: Support software CPER records
Date: Thu, 29 Oct 2026 13:37:30 +0000	[thread overview]
Message-ID: <sashiko-outbox-189398@kernel.org> (raw)
In-Reply-To: <20261029132609.907017-12-mallesh.koujalagi@intel.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] drm/xe/cper: sleeping in atomic context in cper_emit_sw_err()
- [High] drm/xe/cper: NULL pointer dereference in cper_emit_sw_err() when xe is NULL
--

commit c16a87d05ae708e1a17ac24623a75a82d558972b
Author: Mallesh Koujalagi <mallesh.koujalagi@intel.com>

drm/xe/cper: Support software CPER records

This commit adds support for handling software SIGIDs in xe_cper_emit() by
formatting the log message and emitting driver-notification CPER records via
cper_emit_sw_err().

> diff --git a/drivers/gpu/drm/xe/xe_cper.c b/drivers/gpu/drm/xe/xe_cper.c
> index e802f534eb45a..ec61605d0a314 100644
> --- a/drivers/gpu/drm/xe/xe_cper.c
> +++ b/drivers/gpu/drm/xe/xe_cper.c

[ ... ]

> @@ -239,6 +246,37 @@ static void cper_emit_hw_err(struct xe_device *xe, int cper_sev, enum xe_sigid s
>  	xe_cper_emit_counter(xe, cper_sev, sigid, counter, &response);
>  }
>  
> +#define XE_CPER_SW_MSG_MAX	256
> +
> +static size_t cper_format_sw_msg(struct va_format *vaf, char *buf, size_t size)
> +{
> +	return scnprintf(buf, size, "%pV", vaf) + 1;
> +}
> +
> +static void cper_emit_sw_err(struct xe_device *xe, int cper_sev, enum xe_sigid sigid,
> +			     u32 component, u32 location, const void *data,
> +			     struct va_format *vaf)
> +{
> +	struct xe_cper_intel_hdr ihdr = {};
> +	struct xe_cper_driver_error_class *driver = &ihdr.driver;
> +	u64 timestamp = ktime_get_boottime_ns();
> +	char msg[XE_CPER_SW_MSG_MAX];
> +	size_t msg_len;
> +
> +	might_sleep();
> +
> +	driver->error_type = cper_sev;
> +	driver->error_component = component;
> +	driver->tile = location;
> +	if (IS_ERR(data))
> +		driver->cause = -PTR_ERR(data);
> +
> +	msg_len = cper_format_sw_msg(vaf, msg, sizeof(msg));
> +
> +	cper_init_intel_hdr(xe, timestamp, sigid, 1, &ihdr);
> +	cper_record_emit(xe, cper_sev, &INTEL_CPER_NOTIFY_DRV_ERROR, &ihdr, msg, msg_len);
> +}

[Severity: High]
Can cper_emit_sw_err() sleep in atomic context when software SIGIDs are
logged?

In drivers/gpu/drm/xe/xe_log.c, __xe_log_emit() unconditionally calls
log_emit_cper() -> xe_cper_emit(). With this change, software SIGIDs are
routed to cper_emit_sw_err(), which calls might_sleep() and then calls
cper_record_emit() in drivers/gpu/drm/xe/xe_cper.c:

    total_len = sizeof(struct xe_cper_nonstd_record) + einfo_len;
    rec = kzalloc(total_len, GFP_KERNEL);

However, several paths in the driver emit software SIGID logs from hardirq
context, while holding spinlocks, or with preemption disabled:

1. In drivers/gpu/drm/xe/xe_guc_ct.c, xe_guc_ct_fast_path() runs from the
interrupt handler under xe->irq.lock and ct->fast_lock:

    spin_lock(&ct->fast_lock);
    do {
        len = g2h_read(ct, ct->fast_msg, true);
        if (len > 0)
            g2h_fast_path(ct, ct->fast_msg, len);
    } while (len > 0);
    spin_unlock(&ct->fast_lock);

Within this critical section (as well as in g2h_release_space(),
dequeue_one_g2h(), and __guc_ct_send_locked() while holding ct->fast_lock),
g2h_read() -> ct_corrupted() and g2h_fast_path() -> __g2h_release_space()
call xe_log_err() for the GuC component:

    xe_log_err(ct_to_gt(ct), GUC, err, "CT: %pV", &vaf);

2. In drivers/gpu/drm/xe/xe_pagefault.c, xe_pagefault_handler() (called from
hardirq context via xe_guc_ct_fast_path()) and xe_pagefault_queue_pop() hold
pf_queue->lock and call xe_pagefault_queue_add():

    guard(spinlock_irqsave)(&pf_queue->lock);

    empty = xe_pagefault_queue_empty(pf_queue);
    lpf = xe_pagefault_queue_add(pf_queue, pf);

When the queue is full, xe_pagefault_queue_add() calls:

    if (WARN_ON_ONCE(xe_pagefault_queue_full(pf_queue))) {
        xe_log_err(xe, PAGEFAULT, -ENOSPC, "Queue full!\n");
        return NULL;
    }

3. In drivers/gpu/drm/xe/xe_wedge.c, xe_wedge_declare() is documented as safe
for atomic callers and is invoked from hardirq context via
dg1_irq_handler() -> xe_mert_irq_handler() -> mert_handle_cat_error():

    xe_log_err_fatal(xe, WEDGED, -EIO, "Device declared wedged!\n");

4. In drivers/gpu/drm/xe/xe_pcode.c, xe_pcode_request() disables preemption
around pcode_try_request() -> pcode_mailbox_rw() -> __pcode_mailbox_rw() ->
pcode_mailbox_status(), which logs PCODE errors via xe_log_err():

    preempt_disable();
    ret = pcode_try_request(tile, mbox, request, reply_mask, reply, &status,
                            true, 50 * 1000, true);
    preempt_enable();

> +
>  /**
>   * xe_cper_emit() - Emit a CPER record for a SIGID log entry
>   * @xe: The &xe_device
> @@ -272,7 +310,8 @@ void xe_cper_emit(struct xe_device *xe, int cper_sev, enum xe_sigid sigid,
>  		return;
>  	}
>  
> -	/* TODO software CPER */
> +	if (is_sw_sigid(sigid))
> +		cper_emit_sw_err(xe, cper_sev, sigid, component, location, data, vaf);
>  }

[Severity: High]
Could this dereference a null xe pointer when xe_cper_emit() is called during
early PCI probe?

In drivers/gpu/drm/xe/xe_log.c, log_emit_cper() resolves the device pointer
via xe_any_to_xe():

    xe_cper_emit(xe_any_to_xe(pdev), cper_sev, sigid,
                 component, location, data, len, vaf);

When a struct pci_dev pointer is passed to the logging macros before
pci_set_drvdata() has been called in __xe_pci_probe(), pdev_to_xe_device(pdev)
returns NULL. This happens in drivers/gpu/drm/xe/xe_pci.c in xe_pci_probe()
when a device ID is blocked or if __xe_pci_probe() fails during early setup
(such as in devres_open_group(), pcim_enable_device(), or
xe_device_create()):

    if (id_blocked(pdev->device)) {
        xe_log_info(pdev, PROBE, "driver loading blocked for device '%04x'\n",
                    pdev->device);
        return -ENODEV;
    }

    if (xe_display_driver_probe_defer(pdev))
        return -EPROBE_DEFER;

    err = __xe_pci_probe(pdev, desc);
    if (err) {
        xe_log_err_fatal(pdev, PROBE, err, "driver loading failed for device '%04x'\n",
                         pdev->device);
        return err;
    }

Because those probe logs use a software SIGID, xe_cper_emit() now calls
cper_emit_sw_err() -> cper_init_intel_hdr() with xe set to NULL, which
dereferences xe->drm.dev in drivers/gpu/drm/xe/xe_cper.c:

    strscpy(ihdr->pci_bdf, pci_name(to_pci_dev(xe->drm.dev)), sizeof(ihdr->pci_bdf));

Should xe_cper_emit() check for a null xe pointer before proceeding?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261029132609.907017-8-mallesh.koujalagi@intel.com?part=4

  reply	other threads:[~2026-10-29 13:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 13:26 [PATCH v2 0/6] drm/xe/cper: Software (driver-detected) CPER error reporting Mallesh Koujalagi
2026-10-29 13:26 ` [PATCH v2 1/6] Add CPER logging support for CRI-Do not review Mallesh Koujalagi
2026-10-29 13:26 ` [PATCH v2 2/6] drm/xe/cper: Add software error classification definitions Mallesh Koujalagi
2026-10-29 13:26 ` [PATCH v2 3/6] drm/xe/cper: Decouple RAS error class initialization Mallesh Koujalagi
2026-10-29 13:26 ` [PATCH v2 4/6] drm/xe/cper: Support software CPER records Mallesh Koujalagi
2026-10-29 13:37   ` sashiko-bot [this message]
2026-10-29 13:26 ` [PATCH v2 5/6] drm/xe/log: Add software CPER information to KUnit output Mallesh Koujalagi
2026-10-29 13:26 ` [PATCH v2 6/6] drm/xe/log: Test software CPER emission parameters Mallesh Koujalagi
2026-10-29 13:35 ` ✗ CI.checkpatch: warning for drm/xe/cper: Software (driver-detected) CPER error reporting (rev2) Patchwork
2026-10-29 13:37 ` ✓ CI.KUnit: success " Patchwork
2026-10-29 14:12 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-10-30  3:29 ` ✗ Xe.CI.FULL: " Patchwork

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=sashiko-outbox-189398@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=mallesh.koujalagi@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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