[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20071021074301.GA14368@elte.hu>
Date: Sun, 21 Oct 2007 09:43:01 +0200
From: Ingo Molnar <mingo@...e.hu>
To: "Milton D. Miller II" <miltonm@...ltime.net>
Cc: Paul Jackson <pj@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix sched_domain sysctl registration again
* Milton D. Miller II <miltonm@...ltime.net> wrote:
> commit 029190c515f15f512ac85de8fc686d4dbd0ae731 (cpuset
> sched_load_balance flag) was not tested SCHED_DEBUG enabled as
> committed as it dereferences NULL when used and it reordered the
> sysctl registration to cause it to never show any domains or their
> tunables.
>
> Fixes:
>
> 1) restore arch_init_sched_domains ordering
> we can't walk the domains before we build them
>
> presently we register cpus with empty directories (no domain
> directories or files).
>
> 2) make unregister_sched_domain_sysctl do nothing when already unregistered
> detach_destroy_domains is now called one set of cpus at a time
> unregister_syctl dereferences NULL if called with a null.
>
> While the the function would always dereference null if called
> twice, in the previous code it was always called once and then
> was followed a register. So only the hidden bug of the
> sysctl_root_table not being allocated followed by an attempt to
> free it would have shown the error.
>
> 3) always call unregister and register in partition_sched_domains
> The code is "smart" about unregistering only needed domains.
> Since we aren't guaranteed any calls to unregister, always
> unregister. Without calling register on the way out we
> will not have a table or any sysctl tree.
>
> 4) warn if register is called without unregistering
> The previous table memory is lost, leaving pointers to the
> later freed memory in sysctl and leaking the memory of the
> tables.
thanks, applied.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists