Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Auld <matthew.auld@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>,
	intel-xe@lists.freedesktop.org
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Francois Dugast <francois.dugast@intel.com>,
	Badal Nilawar <badal.nilawar@intel.com>,
	Karthik Poosa <karthik.poosa@intel.com>
Subject: Re: [PATCH v2 13/14] drm/xe/hwmon: Fix mutex destroy
Date: Fri, 7 Feb 2025 10:20:18 +0000	[thread overview]
Message-ID: <286f74fa-1021-478b-b8db-74acd4f320cb@intel.com> (raw)
In-Reply-To: <h3qkpwdljkdfi22j3ldgqenhlb6j6k6wuksmazdfnuy3twapjn@umhq67gyaekc>

On 07/02/2025 03:27, Lucas De Marchi wrote:
> On Thu, Feb 06, 2025 at 03:23:31PM -0800, Lucas De Marchi wrote:
>> Since the mutex is used if userspace kept the fd open, it can't be
>> released together with the dev cleanup and needs to be delayed. Also,

Where is that? I would have thought here that 
devm_hwmon_device_register_with_info() would ensure nothing can reach 
that lock once the physical device is detached, since everything 
contained in xe->hwmon is tied to that, including the lock. It looks a 
little weird but seems like it should be fine?

>> there's no need to add an action just to release the mutex: use the
>> specific drmm_mutex_init() that should be smarter if mutex_destroy() is
>> actually a nop.
>>
>> Cc: Badal Nilawar <badal.nilawar@intel.com>
>> Cc: Karthik Poosa <karthik.poosa@intel.com>
>> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> 
> oops... 3a13c2de442d6bfaef9c102cd1092e6cae22b753
> 
> the reasoning is true, but the entire thing is in struct devm allocated.
> Then CI complains:
> 
> <4> [321.873848] WARNING: CPU: 13 PID: 12544 at kernel/locking/mutex- 
> debug.c:114 mutex_destroy+0x5b/0x60
 > >
> Lucas De Marchi
> 
>> ---
>> drivers/gpu/drm/xe/xe_hwmon.c | 10 +---------
>> 1 file changed, 1 insertion(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_hwmon.c b/drivers/gpu/drm/xe/ 
>> xe_hwmon.c
>> index 7f327e3342123..0fc91c184570d 100644
>> --- a/drivers/gpu/drm/xe/xe_hwmon.c
>> +++ b/drivers/gpu/drm/xe/xe_hwmon.c
>> @@ -869,13 +869,6 @@ xe_hwmon_get_preregistration_info(struct 
>> xe_device *xe)
>>             xe_hwmon_energy_get(hwmon, channel, &energy);
>> }
>>
>> -static void xe_hwmon_mutex_destroy(void *arg)
>> -{
>> -    struct xe_hwmon *hwmon = arg;
>> -
>> -    mutex_destroy(&hwmon->hwmon_lock);
>> -}
>> -
>> void xe_hwmon_register(struct xe_device *xe)
>> {
>>     struct device *dev = xe->drm.dev;
>> @@ -895,8 +888,7 @@ void xe_hwmon_register(struct xe_device *xe)
>>
>>     xe->hwmon = hwmon;
>>
>> -    mutex_init(&hwmon->hwmon_lock);
>> -    if (devm_add_action_or_reset(dev, xe_hwmon_mutex_destroy, hwmon))
>> +    if (drmm_mutex_init(&xe->drm, &hwmon->hwmon_lock))
>>         return;
>>
>>     /* There's only one instance of hwmon per device */
>> -- 
>> 2.48.1
>>


  reply	other threads:[~2025-02-07 10:25 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-06 23:23 [PATCH v2 00/14] Cleanup error handling on probe Lucas De Marchi
2025-02-06 23:23 ` [PATCH v2 01/14] drm/xe: Fix xe_display_fini() calls Lucas De Marchi
2025-02-06 23:23 ` [PATCH v2 02/14] drm/xe: Fix error handling in xe_irq_install() Lucas De Marchi
2025-02-06 23:23 ` [PATCH v2 03/14] drm/xe: Fix xe_tile_init_noalloc() error propagation Lucas De Marchi
2025-02-06 23:23 ` [PATCH v2 04/14] drm/xe: Stop ignoring errors from xe_ttm_stolen_mgr_init() Lucas De Marchi
2025-02-06 23:23 ` [PATCH v2 05/14] drm/xe: Remove leftover pxp comment Lucas De Marchi
2025-02-06 23:28   ` Daniele Ceraolo Spurio
2025-02-06 23:23 ` [PATCH v2 06/14] drm/xe: Add callback support for driver remove Lucas De Marchi
2025-02-06 23:23 ` [PATCH v2 07/14] drm/xe: Cleanup unwind of gt initialization Lucas De Marchi
2025-02-07  0:21   ` Daniele Ceraolo Spurio
2025-02-07  0:45     ` Lucas De Marchi
2025-02-06 23:23 ` [PATCH v2 08/14] drm/xe: Cleanup extra calls to xe_hw_fence_irq_finish() Lucas De Marchi
2025-02-06 23:23 ` [PATCH v2 09/14] drm/xe: Move oa fini to xe_oa Lucas De Marchi
2025-02-07 21:22   ` Dixit, Ashutosh
2025-02-06 23:23 ` [PATCH v2 10/14] drm/xe: Move drm_dev_unplug() out of display function Lucas De Marchi
2025-02-06 23:23 ` [PATCH v2 11/14] drm/xe/oa: Handle errors in xe_oa_register() Lucas De Marchi
2025-02-07 21:38   ` Dixit, Ashutosh
2025-02-06 23:23 ` [PATCH v2 12/14] drm/xe: Fail probe if xe_pmu_register() fails Lucas De Marchi
2025-02-06 23:23 ` [PATCH v2 13/14] drm/xe/hwmon: Fix mutex destroy Lucas De Marchi
2025-02-07  3:27   ` Lucas De Marchi
2025-02-07 10:20     ` Matthew Auld [this message]
2025-02-07 13:59       ` Lucas De Marchi
2025-02-06 23:23 ` [PATCH v2 14/14] drm/xe/hwmon: Stop ignoring errors on probe Lucas De Marchi
2025-02-07  0:59 ` ✓ CI.Patch_applied: success for Cleanup error handling on probe (rev2) Patchwork
2025-02-07  1:00 ` ✗ CI.checkpatch: warning " Patchwork
2025-02-07  1:01 ` ✓ CI.KUnit: success " Patchwork
2025-02-07  1:17 ` ✓ CI.Build: " Patchwork
2025-02-07  1:20 ` ✓ CI.Hooks: " Patchwork
2025-02-07  1:21 ` ✓ CI.checksparse: " Patchwork
2025-02-07  1:41 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-02-07  7:27 ` ✗ 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=286f74fa-1021-478b-b8db-74acd4f320cb@intel.com \
    --to=matthew.auld@intel.com \
    --cc=badal.nilawar@intel.com \
    --cc=francois.dugast@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=karthik.poosa@intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=rodrigo.vivi@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