All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Robert Beckett <bob.beckett@collabora.com>,
	Zeng Chi <zengchi@kylinos.cn>,
	 nas.chung@chipsnmedia.com, jackson.lee@chipsnmedia.com,
	mchehab@kernel.org,  sebastian.fricke@collabora.com,
	hverkuil-cisco@xs4all.nl
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix memory leaks in wave5_vpu_open_enc() and wave5_vpu_open_dec()
Date: Thu, 07 Dec 2023 13:40:56 -0500	[thread overview]
Message-ID: <64d946710b3f3e14bfeb3fa95db01a99e244f264.camel@collabora.com> (raw)
In-Reply-To: <e891ae21-2b3a-4d99-9f5c-fb387438ffef@collabora.com>

Le mardi 05 décembre 2023 à 17:36 +0000, Robert Beckett a écrit :
> On 04/12/2023 13:55, Nicolas Dufresne wrote:
> > Hi,
> > 
> > Le lundi 04 décembre 2023 à 17:16 +0800, Zeng Chi a écrit :
> > > This patch fixes memory leaks on error escapes in wave5_vpu_open_enc()
> > > and wave5_vpu_open_dec().
> > Please avoid sending twice the same patch. This is still a NAK.
> 
> tbf, this is a different patch, concerning the allocation of the 
> codec_info within inst, not inst itself.

I've stopped after reading an identical subject line. I can apology for not
noticing the difference, but I think an effort from the submitter could
certainly help in the future.

Nicolas

> 
> > regards,
> > Nicolas
> > 
> > > Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer")
> > > Signed-off-by: Zeng Chi<zengchi@kylinos.cn>
> > > ---
> > >   drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c | 5 +++--
> > >   drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c | 5 +++--
> > >   2 files changed, 6 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > index 8b1417ece96e..b0a045346bb7 100644
> > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > @@ -1802,9 +1802,10 @@ static int wave5_vpu_open_dec(struct file *filp)
> > >   	spin_lock_init(&inst->state_spinlock);
> > >   
> > >   	inst->codec_info = kzalloc(sizeof(*inst->codec_info), GFP_KERNEL);
> > > -	if (!inst->codec_info)
> > > +	if (!inst->codec_info) {
> > > +		kfree(inst);
> 
> for consistency, would be better to jump to cleanup_inst.
> 
> Also, maybe consider embedding codec_info  in to struct vpu_instance to 
> avoid the double alloc. I've not checked whether this is viable 
> throughout the code, but from a quick scan of the original patch, it 
> looks like it is always allocated and freed alongside inst.
> 
> > >   		return -ENOMEM;
> > > -
> > > +	}
> > >   	v4l2_fh_init(&inst->v4l2_fh, vdev);
> > >   	filp->private_data = &inst->v4l2_fh;
> > >   	v4l2_fh_add(&inst->v4l2_fh);
> > > diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > index f29cfa3af94a..bc94de9ea546 100644
> > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > @@ -1546,9 +1546,10 @@ static int wave5_vpu_open_enc(struct file *filp)
> > >   	inst->ops = &wave5_vpu_enc_inst_ops;
> > >   
> > >   	inst->codec_info = kzalloc(sizeof(*inst->codec_info), GFP_KERNEL);
> > > -	if (!inst->codec_info)
> > > +	if (!inst->codec_info) {
> > > +		kfree(inst);
> > >   		return -ENOMEM;
> > > -
> > > +	}
> > >   	v4l2_fh_init(&inst->v4l2_fh, vdev);
> > >   	filp->private_data = &inst->v4l2_fh;
> > >   	v4l2_fh_add(&inst->v4l2_fh);
> 


  reply	other threads:[~2023-12-07 18:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-04  9:16 [PATCH] Fix memory leaks in wave5_vpu_open_enc() and wave5_vpu_open_dec() Zeng Chi
2023-12-04 13:55 ` Nicolas Dufresne
2023-12-05 17:36   ` Robert Beckett
2023-12-07 18:40     ` Nicolas Dufresne [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-12-04  8:39 Zeng Chi
2023-12-04 13:54 ` Nicolas Dufresne

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=64d946710b3f3e14bfeb3fa95db01a99e244f264.camel@collabora.com \
    --to=nicolas.dufresne@collabora.com \
    --cc=bob.beckett@collabora.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jackson.lee@chipsnmedia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=nas.chung@chipsnmedia.com \
    --cc=sebastian.fricke@collabora.com \
    --cc=zengchi@kylinos.cn \
    /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.