Don't leak sysctl tables if the scheduler registration fails
Subsystems (2)
PATCH 1/1 Don't leak sysctl tables if the scheduler registration fails
In case we load lblc or lblcr module we can leak some sysctl tables if the call to register_ip_vs_scheduler() fails.
I've looked at the register_ip_vs_scheduler() code and saw, that the only reason to fail is the name collision, so I think that with some 3rd party schedulers this becomes a relevant issue. No?
---
net/ipv4/ipvs/ip_vs_lblc.c +6 -1
@@ -580,9 +580,14 @@ static struct ip_vs_scheduler ip_vs_lblc_scheduler =static int __init ip_vs_lblc_init (void ) { +int ret; +INIT_LIST_HEAD (&ip_vs_lblc_scheduler.n_list); sysctl_header =register_sysctl_table (lblc_root_table); -return register_ip_vs_scheduler (&ip_vs_lblc_scheduler); + ret =register_ip_vs_scheduler (&ip_vs_lblc_scheduler); +if (ret) +unregister_sysctl_table (sysctl_header); +return ret; }
net/ipv4/ipvs/ip_vs_lblcr.c +6 -1
@@ -769,9 +769,14 @@ static struct ip_vs_scheduler ip_vs_lblcr_scheduler =static int __init ip_vs_lblcr_init (void ) { +int ret; +INIT_LIST_HEAD (&ip_vs_lblcr_scheduler.n_list); sysctl_header =register_sysctl_table (lblcr_root_table); -return register_ip_vs_scheduler (&ip_vs_lblcr_scheduler); + ret =register_ip_vs_scheduler (&ip_vs_lblcr_scheduler); +if (ret) +unregister_sysctl_table (sysctl_header); +return ret; }
Quoted 2 lines · Pavel Emelyanov
In case we load lblc or lblcr module we can leak some sysctl tables if the call to
register_ip_vs_scheduler()fails.
This looks correct to me.
Quoted 3 lines
I've looked at the
register_ip_vs_scheduler()code and saw, that the only reason to fail is the name collision, so I think that with some 3rd party schedulers this becomes a relevant issue. No?
I guess so. Though presumably register_ip_vs_scheduler() could have other modes of failure in the future.
Quoted 1 line
Signed-off-by Pavel Emelyanov <[email protected]>
Quoted 42 lines
---
net/ipv4/ipvs/ip_vs_lblc.c +6
-1@@ -580,9 +580,14 @@ static struct ip_vs_scheduler ip_vs_lblc_scheduler =static int __init ip_vs_lblc_init (void ) { +int ret; +INIT_LIST_HEAD (&ip_vs_lblc_scheduler.n_list); sysctl_header =register_sysctl_table (lblc_root_table); -return register_ip_vs_scheduler (&ip_vs_lblc_scheduler); + ret =register_ip_vs_scheduler (&ip_vs_lblc_scheduler); +if (ret) +unregister_sysctl_table (sysctl_header); +return ret; }net/ipv4/ipvs/ip_vs_lblcr.c +6
-1@@ -769,9 +769,14 @@ static struct ip_vs_scheduler ip_vs_lblcr_scheduler =static int __init ip_vs_lblcr_init (void ) { +int ret; +INIT_LIST_HEAD (&ip_vs_lblcr_scheduler.n_list); sysctl_header =register_sysctl_table (lblcr_root_table); -return register_ip_vs_scheduler (&ip_vs_lblcr_scheduler); + ret =register_ip_vs_scheduler (&ip_vs_lblcr_scheduler); +if (ret) +unregister_sysctl_table (sysctl_header); +return ret; }
Signature · 1 line
Horms
From: Simon Horman <[email protected]>
Date: Tue, 4 Dec 2007 10:36:48 +0900
Quoted 10 lines · Pavel Emelyanov
Quoted 2 lines
In case we load lblc or lblcr module we can leak some sysctl tables if the call to
register_ip_vs_scheduler()fails.This looks correct to me.
Quoted 3 lines
I've looked at the
register_ip_vs_scheduler()code and saw, that the only reason to fail is the name collision, so I think that with some 3rd party schedulers this becomes a relevant issue. No?
Quoted 6 lines
I guess so. Though presumably
register_ip_vs_scheduler()could have other modes of failure in the future.Quoted 1 line
Signed-off-by Pavel Emelyanov <[email protected]>Acked-by Simon Horman <[email protected]>
Applied, thanks.