All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Shuicheng Lin <shuicheng.lin@intel.com>,
	intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Subject: Re: [PATCH] drm/xe/display: Fix memory leak in parse_lfp_panel_dtd()
Date: Thu, 10 Oct 2024 13:02:55 +0300	[thread overview]
Message-ID: <87msjc6zsg.fsf@intel.com> (raw)
In-Reply-To: <87plo86zua.fsf@intel.com>

On Thu, 10 Oct 2024, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Wed, 09 Oct 2024, Shuicheng Lin <shuicheng.lin@intel.com> wrote:
>> The function parse_lfp_panel_dtd() is called when the driver
>> attempts to initialize the eDP connector, and it allocates memory,
>> which is recorded in panel->vbt.lfp_vbt_mode. However, since no
>> eDP panel is connected, the driver fails at intel_edp_init_dpcd()
>> and follows the failure path. Unfortunately, the allocated memory
>> is not freed in this case.
>>
>> To fix this issue, free the memory in the failure path.
>>
>> leak info from kmemleak:
>> "
>> unreferenced object 0xffff8881252f8800 (size 128):
>>   comm "systemd-udevd", pid 192, jiffies 4294896880
>>   hex dump (first 32 bytes):
>>     e8 fd 00 00 00 04 18 04 a0 04 40 05 00 00 00 03  ..........@.....
>>     03 03 09 03 26 03 00 00 0a 00 00 00 00 00 00 00  ....&...........
>>   backtrace (crc 7448f6b4):
>>     [<ffffffff82475c9b>] kmemleak_alloc+0x4b/0x80
>>     [<ffffffff814bb50e>] __kmalloc_cache_noprof+0x2be/0x390
>>     [<ffffffffa069862c>] intel_bios_init_panel+0x1c4c/0x2720 [xe]
>>     [<ffffffffa0699123>] intel_bios_init_panel_early+0x13/0x20 [xe]
>>     [<ffffffffa06fceb9>] intel_dp_init_connector+0x2f9/0x1080 [xe]
>>     [<ffffffffa06c370a>] intel_ddi_init+0xbba/0xf50 [xe]
>>     [<ffffffffa069b906>] intel_bios_for_each_encoder+0x36/0x60 [xe]
>>     [<ffffffffa06d7bd6>] intel_setup_outputs+0x206/0x450 [xe]
>>     [<ffffffffa06dad33>] intel_display_driver_probe_nogem+0x163/0x1f0 [xe]
>>     [<ffffffffa0680fc7>] xe_display_init_noaccel+0x27/0x70 [xe]
>>     [<ffffffffa05b30d6>] xe_device_probe+0x806/0x9a0 [xe]
>>     [<ffffffffa0612f0f>] xe_pci_probe+0x31f/0x590 [xe]
>>     [<ffffffff81b41718>] local_pci_probe+0x48/0xb0
>>     [<ffffffff81b432c8>] pci_device_probe+0xc8/0x280
>>     [<ffffffff81d5dde8>] really_probe+0xf8/0x390
>>     [<ffffffff81d5e11a>] __driver_probe_device+0x8a/0x170
>> "
>>
>> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
>> ---
>>  drivers/gpu/drm/i915/display/intel_dp.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
>> index 90fa73575feb..39ad71454d2b 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -6801,6 +6801,7 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
>>  
>>  out_vdd_off:
>>  	intel_pps_vdd_off_sync(intel_dp);
>> +	intel_panel_fini(intel_connector);
>
> It's a bit hard to follow, but this breaks the symmetry. If we end up
> here, intel_panel_init() hasn't been called yet, so we shouldn't call
> intel_panel_fini() either.
>
> What we want to undo here is what was done by
> intel_bios_init_panel_early() and intel_bios_init_panel_late(). The
> appropriate function for that is intel_bios_fini_panel().

PS. The subject prefix should be "drm/i915/dp". This is not about xe
display per se.

BR,
Jani.

>
> BR,
> Jani.
>
>>  
>>  	return false;
>>  }

-- 
Jani Nikula, Intel

  reply	other threads:[~2024-10-10 10:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-09 23:27 [PATCH] drm/xe/display: Fix memory leak in parse_lfp_panel_dtd() Shuicheng Lin
2024-10-10  0:06 ` ✓ CI.Patch_applied: success for " Patchwork
2024-10-10  0:06 ` ✓ CI.checkpatch: " Patchwork
2024-10-10  0:07 ` ✓ CI.KUnit: " Patchwork
2024-10-10  0:19 ` ✓ CI.Build: " Patchwork
2024-10-10  0:21 ` ✓ CI.Hooks: " Patchwork
2024-10-10  0:23 ` ✗ CI.checksparse: warning " Patchwork
2024-10-10  0:40 ` ✓ CI.BAT: success " Patchwork
2024-10-10  0:40 ` ✓ Fi.CI.BAT: " Patchwork
2024-10-10 10:01 ` [PATCH] " Jani Nikula
2024-10-10 10:02   ` Jani Nikula [this message]
2024-10-10 15:04 ` ✗ CI.FULL: failure for " Patchwork
2024-10-11  7:20 ` ✗ Fi.CI.IGT: " 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=87msjc6zsg.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=shuicheng.lin@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.