All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.