All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: PanBian <bianpan2016@163.com>, Greg KH <gregkh@linuxfoundation.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	James Morse <james.morse@arm.com>,
	linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: EDAC: Fix memory leak in creating CSROW object
Date: Fri, 19 Apr 2019 02:45:16 +0200	[thread overview]
Message-ID: <20190419004516.GC559@zn.tnic> (raw)

On Fri, Apr 19, 2019 at 08:35:36AM +0800, PanBian wrote:
> Yes, I see that. Because the loop start with (--i), there is no put
> operation for the device that fails to create. So, I think we cannot
> rule out the possibility of memory leak.

Ok, so this is not something you trigger - you're basically staring at
the code?

Well, there's something else questionable in that code which I asked
Greg about today but we didn't finish that conversation, let me CC him.

So AFAIU, devices for which device_add() has returned success,
should be removed with their counterpart device_del().
edac_create_csrow_objects(), however, does put_device() on those in the
"unwinding" loop.

And for the case where device_add() fails, you should do put_device() to
it. I.e., what you're saying.

So I think we need to figure what needs to be done when before fixing
this properly.

Greg?

WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: PanBian <bianpan2016@163.com>, Greg KH <gregkh@linuxfoundation.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	James Morse <james.morse@arm.com>,
	linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: EDAC: Fix memory leak in creating CSROW object
Date: Fri, 19 Apr 2019 02:45:16 +0200	[thread overview]
Message-ID: <20190419004516.GC559@zn.tnic> (raw)
Message-ID: <20190419004516.PRDywx2ANuwYUNopjGs5zvND3Nj-Sh-J7Snq_WYkc0s@z> (raw)
In-Reply-To: <20190419003536.GA57795@bianpan2016@163.com>

On Fri, Apr 19, 2019 at 08:35:36AM +0800, PanBian wrote:
> Yes, I see that. Because the loop start with (--i), there is no put
> operation for the device that fails to create. So, I think we cannot
> rule out the possibility of memory leak.

Ok, so this is not something you trigger - you're basically staring at
the code?

Well, there's something else questionable in that code which I asked
Greg about today but we didn't finish that conversation, let me CC him.

So AFAIU, devices for which device_add() has returned success,
should be removed with their counterpart device_del().
edac_create_csrow_objects(), however, does put_device() on those in the
"unwinding" loop.

And for the case where device_add() fails, you should do put_device() to
it. I.e., what you're saying.

So I think we need to figure what needs to be done when before fixing
this properly.

Greg?

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

         reply	other threads:[~2019-04-19  0:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18  2:27 EDAC: Fix memory leak in creating CSROW object Pan Bian
2019-04-18  2:27 ` Pan Bian
2019-04-18 17:25 ` Borislav Petkov
2019-04-18 17:25   ` Borislav Petkov
     [not found]   ` <20190419003536.GA57795@bianpan2016@163.com>
2019-04-19  0:45     ` Borislav Petkov [this message]
2019-04-19  0:45       ` Borislav Petkov
2019-04-27 21:49       ` Greg Kroah-Hartman
2019-04-27 21:49         ` Greg KH
2019-05-08 10:57         ` Borislav Petkov
2019-05-08 12:47           ` Greg KH
2019-05-08 18:50             ` Borislav Petkov
2019-05-08 11:02         ` [PATCH 1/2] EDAC/sysfs: Fix memory leak when creating a csrow object Borislav Petkov
2019-05-08 12:45           ` Greg KH
2019-05-08 11:06         ` [PATCH 2/2] EDAC/sysfs: Drop device references properly Borislav Petkov
2019-05-08 12:47           ` Greg KH

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=20190419004516.GC559@zn.tnic \
    --to=bp@alien8.de \
    --cc=bianpan2016@163.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.morse@arm.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@kernel.org \
    /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.