All of 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 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.