lane_init
| |-> __drm_universal_plane_init (first free)
|
|-> mdp5_plane_destroy
|-> drm_plane_cleanup (second free)
Fix this by setting the two pointers to NULL after kfree.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/drm_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu
When kzalloc() for smu_table->ecc_table fails, we should free
the previously allocated resources to prevent memleak.
Fixes: edd794208555 ("drm/amd/pm: add message smu to get ecc_table v2")
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 5
When nv50_lut_init() fails, *pwndw should be freed
just like when drm_universal_plane_init() fails.
It's the same for the subsequent error paths.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 22 --
1 file changed, 12 insertions(+), 10 deletions
When amdgpu_display_modeset_create_props() fails, state and
state->context should be freed to prevent memleak. It's the
same when amdgpu_dm_audio_init() fails.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 --
1 file changed, 8 insertions(+)
When radeon_kick_out_firmware_fb() fails, info should be
freed just like the subsequent error paths.
Fixes: 069ee21a82344 ("fbdev: Fix loading of module radeonfb on PowerMac")
Signed-off-by: Dinghao Liu
---
drivers/video/fbdev/aty/radeon_base.c | 2 +-
1 file changed, 1 insertion(+),
to keep
the counter balanced.
Fixes: 4fbafaf371be7 ("OMAP: DSS2: Use PM runtime & HWMOD support")
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/drivers/g
the counter
balanced.
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Fix 5 additional similar cases in omapdrm.
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 7 +--
drivers/gpu/drm/omapdrm/dss/dsi.c | 7 +--
drivers/gpu/drm/omapdrm/dss/dss.c | 7 +--
drivers/gpu/drm/omapdrm/dss/hdmi4.c
> Hi,
>
> On 21/08/2020 10:45, Dinghao Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter
> > even when it returns an error code. However, users of
> > dsi_runtime_get(), a direct wrapper of pm_runtime_get_sync(),
> > assume that PM usage
> On Thu, 20 Aug 2020, dinghao@zju.edu.cn wrote:
>
> > > On Wed, 19 Aug 2020, Markus Elfring wrote:
> > >
> > > > > When of_property_read_u32_array() returns an error code,
> > > > > a pairing refcount decrement is needed to keep np's refcount balanced.
> > > >
> > > > Can another
> On Wed, 19 Aug 2020, Markus Elfring wrote:
>
> > > When of_property_read_u32_array() returns an error code,
> > > a pairing refcount decrement is needed to keep np's refcount balanced.
> >
> > Can another imperative wording be helpful for the change description?
> >
When verify_crc_source() fails, source needs to be freed.
However, current code is returning directly and ends up
leaking memory.
Fixes: c0811a7d5befe ("drm/crc: Cleanup crtc_crc_open function")
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/drm_debugfs_crc.c | 4 +++-
1 file
When of_property_read_u32_array() returns an error code, a
pairing refcount decrement is needed to keep np's refcount
balanced.
Fixes: f705806c9f355 ("backlight: Add support Skyworks SKY81452 backlight
driver")
Signed-off-by: Dinghao Liu
---
drivers/video/backlight/sky81452-backl
> On Tue, Jun 02, 2020 at 01:10:34PM +0200, Markus Elfring wrote:
> > > The original patch was basically fine.
> >
> > I propose to reconsider the interpretation of the software situation once
> > more.
> >
> > * Should the allocated clock object be kept usable even after
> > a successful
> > I just found that clk is referenced by pclk in this function. When clk is
> > freed,
> > pclk will be allocated in gm20b_clk_new_speedo0(). Thus we should not
> > release clk
> > in this function and there is no bug here.
>
> Can there be a need to release a clock object after a failed
>
> > For security, I will release this pointer only on error paths in this
> > function.
>
> Do you tend to release objects (which are referenced by pointers)?
>
I just found that clk is referenced by pclk in this function. When clk is
freed,
pclk will be allocated in
>
> > It's the same when gm20b_clk_new() returns from elsewhere following this
> > call.
>
> I suggest to reconsider the interpretation of the software situation once
> more.
> Can it be that the allocated clock object should be kept usable even after
> a successful return from this function?
> > If gk20a_clk_ctor() never returns such an error code,
> > we may need not to release this clock object.
>
> Would you like to achieve complete exception handling
> also for this function implementation?
>
It seems that it's possible to get -ENOMEM from gk20a_clk_ctor().
The call chain is as
> > If there's *any* error, it'll check the pointer, if it's non-NULL,
> > it'll call the destructor. If kzalloc() fails, the pointer will be
> > NULL, there's no double-free bug. *every* subdev is written this way
> > to avoid duplicating cleanup logic.
> Actually, gm20b_clk_new_speedo0() may
Hi Ben,
> > When gk20a_clk_ctor() returns an error code, pointer "clk"
> > should be released. It's the same when gm20b_clk_new()
> > returns from elsewhere following this call.
> This shouldn't be necessary. If a subdev constructor fails, and
> returns a pointer, the core will call the
When gk20a_clk_ctor() returns an error code, pointer "clk"
should be released. It's the same when gm20b_clk_new()
returns from elsewhere following this call.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gm20b.c | 8
1 file changed, 4 insertions(+), 4
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced. For all error
paths after pm_runtime_get_sync(), things are the same.
Signed-off-by: Dinghao Liu
When drm_dev_init() returns an error code, a pairing
runtime PM usage counter decrement is needed to keep
the counter balanced. For error paths after this call,
things are the same.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 +
1 file changed, 1
> Indeed, I'll post a proper patch for that later - I just spotted it
> while looking at the code.
>
> Thanks,
>
> Steve
>
> > Regards,
> > Dinghao
> >
> >
> >> On 20/05/2020 12:05, Dinghao Liu wrote:
> >>> pm_runtime_get_sync()
The caller expects panfrost_job_hw_submit() to increase
runtime PM usage counter. The refcount decrement on the
error branch of WARN_ON() will break the counter balance
and needs to be removed.
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Remove refcount decrement on the error path
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/panfrost/panfrost_job.c | 4 +++-
1 file changed, 3
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 5 -
1 file changed, 4
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +++-
1 file changed, 3
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
1 file changed, 1 insertion
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++-
1 file changed, 3
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/v3d/v3d_gem.c | 4 +++-
1 file changed, 3 insertions
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 3 +++
1 file changed, 3
rds,
Dinghao
> On 20/05/2020 12:05, Dinghao Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > the call returns an error code. Thus a pairing decrement is needed
> > on the error handling path to keep the counter balanced.
> >
32 matches
Mail list logo
