intel-xe.lists.freedesktop.org archive mirror
 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:01:49 +0300	[thread overview]
Message-ID: <87plo86zua.fsf@intel.com> (raw)
In-Reply-To: <20241009232709.961628-1-shuicheng.lin@intel.com>

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().

BR,
Jani.

>  
>  	return false;
>  }

-- 
Jani Nikula, Intel

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

Thread overview: 11+ 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 10:01 ` Jani Nikula [this message]
2024-10-10 10:02   ` [PATCH] " Jani Nikula
2024-10-10 15:04 ` ✗ CI.FULL: failure for " 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=87plo86zua.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).