All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raag Jadav <raag.jadav@intel.com>
To: "André Almeida" <andrealmeid@igalia.com>
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	siqueira@igalia.com, airlied@gmail.com, simona@ffwll.ch,
	rodrigo.vivi@intel.com, jani.nikula@linux.intel.com,
	"Xaver Hugl" <xaver.hugl@gmail.com>,
	"Krzysztof Karas" <krzysztof.karas@intel.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	kernel-dev@igalia.com, amd-gfx@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v5 1/3] drm: Create a task info option for wedge events
Date: Wed, 21 May 2025 12:11:07 +0300	[thread overview]
Message-ID: <aC2Yq89IL5tx8MY3@black.fi.intel.com> (raw)
In-Reply-To: <20250520163243.328746-2-andrealmeid@igalia.com>

On Tue, May 20, 2025 at 01:32:41PM -0300, André Almeida wrote:
> When a device get wedged, it might be caused by a guilty application.
> For userspace, knowing which task was the cause can be useful for some
> situations, like for implementing a policy, logs or for giving a chance
> for the compositor to let the user know what task caused the problem.
> This is an optional argument, when the task info is not available, the
> PID and TASK string won't appear in the event string.
> 
> Sometimes just the PID isn't enough giving that the task might be already
> dead by the time userspace will try to check what was this PID's name,
> so to make the life easier also notify what's the task's name in the user
> event.

...

> -int drm_dev_wedged_event(struct drm_device *dev, unsigned long method)
> +int drm_dev_wedged_event(struct drm_device *dev, unsigned long method,
> +			 struct drm_wedge_task_info *info)
>  {
>  	const char *recovery = NULL;
>  	unsigned int len, opt;
> -	/* Event string length up to 28+ characters with available methods */
> -	char event_string[32];
> -	char *envp[] = { event_string, NULL };
> +	char event_string[WEDGE_STR_LEN], pid_string[PID_LEN] = "", comm_string[TASK_COMM_LEN] = "";
> +	char *envp[] = { event_string, NULL, NULL, NULL };
>  
>  	len = scnprintf(event_string, sizeof(event_string), "%s", "WEDGED=");
>  
> @@ -582,6 +586,13 @@ int drm_dev_wedged_event(struct drm_device *dev, unsigned long method)
>  	drm_info(dev, "device wedged, %s\n", method == DRM_WEDGE_RECOVERY_NONE ?
>  		 "but recovered through reset" : "needs recovery");
>  
> +	if (info && ((info->comm && info->comm[0] != '\0'))) {

Thanks for adding this. Should we check if pid > 0?

Also, I was wondering what if the driver only has info on one of the
given members? Should we allow it to be flagged independently?

> +		snprintf(pid_string, sizeof(pid_string), "PID=%u", info->pid);
> +		snprintf(comm_string, sizeof(comm_string), "TASK=%s", info->comm);
> +		envp[1] = pid_string;
> +		envp[2] = comm_string;
> +	}
> +
>  	return kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
>  }
>  EXPORT_SYMBOL(drm_dev_wedged_event);

...

> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index e2f894f1b90a..c13fe85210f2 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -30,6 +30,14 @@ struct pci_controller;
>  #define DRM_WEDGE_RECOVERY_REBIND	BIT(1)	/* unbind + bind driver */
>  #define DRM_WEDGE_RECOVERY_BUS_RESET	BIT(2)	/* unbind + reset bus device + bind */
>  
> +/**
> + * struct drm_wedge_task_info - information about the guilty app of a wedge dev

s/app/task, missed an instance ;)

> + */
> +struct drm_wedge_task_info {
> +	pid_t pid;
> +	char *comm;
> +};

Raag

  reply	other threads:[~2025-05-22  7:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-20 16:32 [PATCH v5 0/3] drm: Create a tas info option for wedge events André Almeida
2025-05-20 16:32 ` [PATCH v5 1/3] drm: Create a task " André Almeida
2025-05-21  9:11   ` Raag Jadav [this message]
2025-05-21 15:17     ` André Almeida
2025-05-20 16:32 ` [PATCH v5 2/3] drm/doc: Add a section about "Task information" for the wedge API André Almeida
2025-05-20 16:32 ` [PATCH v5 3/3] drm/amdgpu: Make use of drm_wedge_task_info André Almeida
2025-05-20 17:07 ` ✗ Fi.CI.CHECKPATCH: warning for drm: Create a tas info option for wedge events Patchwork
2025-05-20 17:07 ` ✗ Fi.CI.SPARSE: " Patchwork
2025-05-20 17:11 ` ✓ CI.Patch_applied: success " Patchwork
2025-05-20 17:11 ` ✗ CI.checkpatch: warning " Patchwork
2025-05-20 17:12 ` ✓ CI.KUnit: success " Patchwork
2025-05-20 17:23 ` ✓ CI.Build: " Patchwork
2025-05-20 17:25 ` ✓ CI.Hooks: " Patchwork
2025-05-20 17:27 ` ✗ CI.checksparse: warning " Patchwork
2025-05-20 17:30 ` ✗ i915.CI.BAT: failure " Patchwork
2025-05-20 17:48 ` ✓ Xe.CI.BAT: success " Patchwork
2025-05-21  1:18 ` ✗ Xe.CI.Full: failure " 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=aC2Yq89IL5tx8MY3@black.fi.intel.com \
    --to=raag.jadav@intel.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=andrealmeid@igalia.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=kernel-dev@igalia.com \
    --cc=krzysztof.karas@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=siqueira@igalia.com \
    --cc=xaver.hugl@gmail.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 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.