Re: [PATCH] edac: fix memory leaks on failure path in edac_init()

[Borislav Petkov]

On Fri, Feb 06, 2015 at 12:50:53PM +0100, Borislav Petkov wrote:
> On Thu, Feb 05, 2015 at 10:12:42PM -0800, Alexey Khoroshilov wrote:
> > edac_init() does not deallocate already allocated resources on failure path.
> > 
> > Found by Linux Driver Verification project (linuxtesting.org).
> > 
> > Signed-off-by: Alexey Khoroshilov <khoroshilov@xxxxxxxxx>

This causes section mismatches because the
edac_{debugfs,mc_sysfs}_exit() functions have __exit annotation but
you've added them to an __init-annotated function. And I should've
caught that :-\

Anyway, here's a fix I'm queueing ontop:

---
From: Borislav Petkov <bp@xxxxxxx>
Subject: [PATCH] EDAC: Fix section mismatches from edac_init unwind path

192580b45e8e ("EDAC: Properly unwind on failure path in edac_init()")
added an unwind path in case of error but those functions have __exit
annotation and are being used in an __init function, leading to section
mismatches. Drop the section annotation and make them normal functions.

Cc: Alexey Khoroshilov <khoroshilov@xxxxxxxxx>
Signed-off-by: Borislav Petkov <bp@xxxxxxx>
---
 drivers/edac/edac_mc_sysfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 3a283819970b..112d63ad1154 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -914,7 +914,7 @@ int __init edac_debugfs_init(void)
 	return 0;
 }
 
-void __exit edac_debugfs_exit(void)
+void edac_debugfs_exit(void)
 {
 	debugfs_remove(edac_debugfs);
 }
@@ -1155,7 +1155,7 @@ int __init edac_mc_sysfs_init(void)
 	return err;
 }
 
-void __exit edac_mc_sysfs_exit(void)
+void edac_mc_sysfs_exit(void)
 {
 	device_unregister(mci_pdev);
 	edac_put_sysfs_subsys();
-- 
2.2.0.33.gc18b867

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/