On Wed, May 08, 2019 at 02:47:54PM +0200, Greg KH wrote:
> Looks good to me, ship it!
Thx, done!
:-)
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Wed, May 08, 2019 at 12:57:43PM +0200, Borislav Petkov wrote:
> On Sat, Apr 27, 2019 at 11:49:25PM +0200, Greg KH wrote:
> > How about this patch, I think it fixes up everything you need to do
> > here, right?
>
> Almost, see the two patches as a reply to this message. I've taken
> Pan's origin
On Sat, Apr 27, 2019 at 11:49:25PM +0200, Greg KH wrote:
> How about this patch, I think it fixes up everything you need to do
> here, right?
Almost, see the two patches as a reply to this message. I've taken
Pan's original patch because it is correct and I doubt you're dying for
attribution :-)
On Fri, Apr 19, 2019 at 02:45:16AM +0200, Borislav Petkov wrote:
> 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 o
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 basical
On Thu, Apr 18, 2019 at 10:27:18AM +0800, Pan Bian wrote:
> In the function that creates a CSROW object, the object is not released
> when failing to add the device to device hierarchy.
Are you sure about this?
> This may result in a memory leak bug.
"May"?
I see a loop which unwinds by putting
In the function that creates a CSROW object, the object is not released
when failing to add the device to device hierarchy. This may result in a
memory leak bug.
Signed-off-by: Pan Bian
---
drivers/edac/edac_mc_sysfs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/driv
7 matches
Mail list logo
