[PATCH 6/6] sched: Do not attempt to destroy uninitialized rt_bandwidth

[PATCH 6/6] sched: Do not attempt to destroy uninitialized rt_bandwidth

[Jan H. Schönherr]

From: Bianca Lutz <sowilo@cs.tu-berlin.de>

If a task group is to be created and alloc_fair_sched_group() fails,
then the rt_bandwidth of the corresponding task group is not yet
initialized. The caller, sched_create_group(), starts a clean up
procedure which calls free_rt_sched_group() which unconditionally
destroys the not yet initialized rt_bandwidth.

This crashes or hangs the system in lock_hrtimer_base(): UP systems
dereference a NULL pointer, while SMP systems loop endlessly on a
condition that cannot become true.

This patch simply avoids the destruction of rt_bandwidth when the
initialization code path was not reached.

(This was discovered by accident with a custom kernel modification.)

Signed-off-by: Bianca Lutz <sowilo@cs.tu-berlin.de>
Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de>
---
 kernel/sched.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 9a5f4c7..f29077c 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -8268,7 +8268,8 @@ static void free_rt_sched_group(struct task_group *tg)
 {
 	int i;
 
-	destroy_rt_bandwidth(&tg->rt_bandwidth);
+	if (tg->rt_se)
+		destroy_rt_bandwidth(&tg->rt_bandwidth);
 
 	for_each_possible_cpu(i) {
 		if (tg->rt_rq)
-- 
1.7.3.4

Re: [PATCH 5/6] sched: Use leaf_cfs_rqs in load_balance_fair()

[Peter Zijlstra]

On Wed, 2011-07-13 at 20:13 +0200, Jan H. Schönherr wrote:
> Since commit 3d4b47b4 ("sched: Implement on-demand (active) cfs_rq list")
> the leaf_cfs_rqs provide an advantage over the task_group list.
> 
> Make use of it in load_balance_fair(), so that we do not unnecessarily
> iterate over empty cfs_rqs where we cannot pull anything from.

I just send a similar patch today:

https://lkml.org/lkml/2011/7/13/94

Re: [PATCH 3/6] sched: Avoid redundant initialization of runqueues

[Peter Zijlstra]

On Wed, 2011-07-13 at 20:13 +0200, Jan H. Schönherr wrote:
> Within sched_init() the functions init_{cfs,rt}_rq() are called
> unconditionally. However, when group scheduling is enabled, those calls
> are also done in init_tg_{cfs,rt}_entry().
> 
> To avoid this redundant initialization, the direct calls within
> sched_init() to init_{cfs,rt}_rq() are dropped in case of enabled group
> scheduling.

But it adds #ifdef muck.. 

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Peter Zijlstra]

On Wed, 2011-07-13 at 20:13 +0200, Jan H. Schönherr wrote:
> From: =?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <schnhrr@cs.tu-berlin.de>

WTF am I to do with crap like that?! 

Re: [PATCH 0/6] Small scheduling cleanups

[Peter Zijlstra]

On Wed, 2011-07-13 at 20:13 +0200, Jan H. Schönherr wrote:
> Hi Ingo, hi Peter.
> 
> While working with the scheduling subsystem, our code review showed some
> things you might be interested in.
> 
> This series is based on v3.0-rc7.
> 
> 
> Patch 1 fixes a typo.
> 
> Patch 2 drops an unused function.
> 
> Patch 3 and 4 avoid some redundancy during runqueue initialization.
> While not stricly necessary, the code is a bit cleaner afterwards.
> 
> Patch 5 replaces a loop over all task group with a loop over the
> leaf CFS runqueues.
> 
> And patch 6 finally avoids a potential crash if there is suddenly no
> memory during task group creation.

Applied 1,2 and 6. Thanks!

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Jiri Kosina]

On Wed, 13 Jul 2011, Peter Zijlstra wrote:

> > From: =?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <schnhrr@cs.tu-berlin.de>
> 
> WTF am I to do with crap like that?! 

Peter,

well, umm, get a decent e-mai client? :)

git-am can also apply such thing without any problems with proper accents.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Peter Zijlstra]

On Thu, 2011-07-14 at 00:07 +0200, Jiri Kosina wrote:
> On Wed, 13 Jul 2011, Peter Zijlstra wrote:
> 
> > > From: =?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <schnhrr@cs.tu-berlin.de>
> > 
> > WTF am I to do with crap like that?! 
> 
> Peter,
> 
> well, umm, get a decent e-mai client? :)

its my apply scripts that create rubbish, also I'll take recommendations
for a decent MUA, afaict they're all crap, mutt, claws, thunderbird,
evolution all suck rocks and its basically picking the one that sucks
least for your particular workflow.

> git-am can also apply such thing without any problems with proper accents.

that's assuming I actually use git at that stage, I find git to be an
utter pain to gather patches with.

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Jiri Kosina]

On Thu, 14 Jul 2011, Peter Zijlstra wrote:

> > > > From: =?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <schnhrr@cs.tu-berlin.de>
> > > 
> > > WTF am I to do with crap like that?! 
> > 
> > Peter,
> > 
> > well, umm, get a decent e-mai client? :)
> 
> its my apply scripts that create rubbish, also I'll take recommendations
> for a decent MUA, afaict they're all crap, mutt, claws, thunderbird,
> evolution all suck rocks and its basically picking the one that sucks
> least for your particular workflow.

Well, probably it's just your locale setting that sucks rocks :)

For example pine, mutt and thunderbird (and the later two I almost never 
launch) all show everything correctly for me.

Basically whatever you have in place on your side seems to violate RFC 
2047, which shouldn't cause problems to anybody these days.

Really seems like misconfiguration on your side.

> > git-am can also apply such thing without any problems with proper accents.
> 
> that's assuming I actually use git at that stage, I find git to be an
> utter pain to gather patches with.

Okay, event quilt doesn't chuckle on that patch.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Jesper Juhl]

On Thu, 14 Jul 2011, Peter Zijlstra wrote:

> On Thu, 2011-07-14 at 00:07 +0200, Jiri Kosina wrote:
> > On Wed, 13 Jul 2011, Peter Zijlstra wrote:
> > 
> > > > From: =?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <schnhrr@cs.tu-berlin.de>
> > > 
> > > WTF am I to do with crap like that?! 
> > 
> > Peter,
> > 
> > well, umm, get a decent e-mai client? :)
> 
> its my apply scripts that create rubbish, also I'll take recommendations
> for a decent MUA, afaict they're all crap, mutt, claws, thunderbird,
> evolution all suck rocks and its basically picking the one that sucks
> least for your particular workflow.
> 
I'd recommend alpine/re-alpine - works well with all mails I receive via 
LKML and elsewhere and I never get complaints about mangled emails from 
people I send patches to (ohh and I happen to like the user interface ;-) 
- check it out.

> > git-am can also apply such thing without any problems with proper accents.
> 
> that's assuming I actually use git at that stage, I find git to be an
> utter pain to gather patches with.

Don't know your workflow, but I can tell you what I do. I just have a 
branch for patches that I'm gathering that are not yet in upstream. Apply 
any new stuff there (or cherry-pick from other branches to my queue 
branch) and then regularly rebase that branch on master (Linus' tree).
When I then want to resend some patches it's as simple as checking out my 
queue branch, doing a rebase to make sure there's no obsolete stuff in it 
and then  git format-patch  to generate mails for the patches I want to 
re-send and then read those patches in to re-alpine and send them.
To me that's not very painfull, but of course it may not match your 
workflow - just a description of mine :-) .

-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Peter Zijlstra]

On Thu, 2011-07-14 at 00:25 +0200, Jiri Kosina wrote:
> On Thu, 14 Jul 2011, Peter Zijlstra wrote:
> 
> > > > > From: =?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <schnhrr@cs.tu-berlin.de>
> > > > 
> > > > WTF am I to do with crap like that?! 
> > > 
> > > Peter,
> > > 
> > > well, umm, get a decent e-mai client? :)
> > 
> > its my apply scripts that create rubbish, also I'll take recommendations
> > for a decent MUA, afaict they're all crap, mutt, claws, thunderbird,
> > evolution all suck rocks and its basically picking the one that sucks
> > least for your particular workflow.
> 
> Well, probably it's just your locale setting that sucks rocks :)
> 
> For example pine, mutt and thunderbird (and the later two I almost never 
> launch) all show everything correctly for me.
> 
> Basically whatever you have in place on your side seems to violate RFC 
> 2047, which shouldn't cause problems to anybody these days.
> 
> Really seems like misconfiguration on your side.

They show the utf8 string without problems, but calling any one of them
a decent MUA is far beyond where I can go, they're barely usable piles
of crap.

> > > git-am can also apply such thing without any problems with proper accents.
> > 
> > that's assuming I actually use git at that stage, I find git to be an
> > utter pain to gather patches with.
> 
> Okay, event quilt doesn't chuckle on that patch.

I'm sure, quilt doesn't care about what's before the --- line, and in
fact they applied just fine. 

But my cobbled together script doesn't do horrid utf8 demunging and thus
had this terrible mess as a From: field. 

Also isn't the kernel source in LANG=C (aka ASCII?).

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Peter Zijlstra]

On Thu, 2011-07-14 at 00:35 +0200, Jesper Juhl wrote:
> 
> Don't know your workflow, but I can tell you what I do. I just have a 
> branch for patches that I'm gathering that are not yet in upstream. Apply 
> any new stuff there (or cherry-pick from other branches to my queue 
> branch) and then regularly rebase that branch on master (Linus' tree).
> When I then want to resend some patches it's as simple as checking out my 
> queue branch, doing a rebase to make sure there's no obsolete stuff in it 
> and then  git format-patch  to generate mails for the patches I want to 
> re-send and then read those patches in to re-alpine and send them.
> To me that's not very painfull, but of course it may not match your 
> workflow - just a description of mine :-) . 

Right, so I find cherry-picking and rebasing using git the most painful
thing ever.

Also, using quilt you get a plain text version of the patch you can edit
at your leisure, editing a git patch involves some export, import and
rebase foo which is all too much work.

Furthermore, using quilt I get help from useful tools like rej and meld
git-merge otoh creates these god-awful merge markers that no tool can
deal with.

As for re-alpine, I might actually try it, you're the second one
promoting it. Although I had somewhat hoped for a MUA like sup to become
useful (or notmuch to grow a usable front-end). Traditional MUAs simply
can't seem to cope well with today's number of emails.

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Jiri Kosina]

On Thu, 14 Jul 2011, Peter Zijlstra wrote:

> > For example pine, mutt and thunderbird (and the later two I almost never 
> > launch) all show everything correctly for me.
> > 
> > Basically whatever you have in place on your side seems to violate RFC 
> > 2047, which shouldn't cause problems to anybody these days.
> > 
> > Really seems like misconfiguration on your side.
> 
> They show the utf8 string without problems, but calling any one of them
> a decent MUA is far beyond where I can go, they're barely usable piles
> of crap.

Umm, so? :)

> > > > git-am can also apply such thing without any problems with proper accents.
> > > 
> > > that's assuming I actually use git at that stage, I find git to be an
> > > utter pain to gather patches with.
> > 
> > Okay, event quilt doesn't chuckle on that patch.
> 
> I'm sure, quilt doesn't care about what's before the --- line, and in
> fact they applied just fine. 
> 
> But my cobbled together script doesn't do horrid utf8 demunging and thus
> had this terrible mess as a From: field. 
> 
> Also isn't the kernel source in LANG=C (aka ASCII?).

The sources are one thing (and even that doesn't hold ... for example a 
lot of places hold copyright sign that is not '(C)' but this UTF-8 thing). 
But the authorship/changelog information is a different story, right?

Just for code authors with non-ascii names:

$ git log | git shortlog -n | grep '^[^ ]' | grep -P "[\x80-\xFF]" | wc -l
245

(now admittedly some of those are results of broken scripts/systems such 
as yours, but most of them are valid).


Now, I have to finally add, I don't care a bit. At all. I just have been 
CCed -- for some odd reason -- on the original patch, and wanted to defend 
Jan against your 'wtf shitty crap you are sending' offenses, as he did 
absolutely nothing wrong (if at least RFCs and 99% of Internet can be 
taken as an etalon), and crap is IMHO located elsewhere :)

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Jesper Juhl]

On Thu, 14 Jul 2011, Peter Zijlstra wrote:

> On Thu, 2011-07-14 at 00:35 +0200, Jesper Juhl wrote:
> > 
> > Don't know your workflow, but I can tell you what I do. I just have a 
> > branch for patches that I'm gathering that are not yet in upstream. Apply 
> > any new stuff there (or cherry-pick from other branches to my queue 
> > branch) and then regularly rebase that branch on master (Linus' tree).
> > When I then want to resend some patches it's as simple as checking out my 
> > queue branch, doing a rebase to make sure there's no obsolete stuff in it 
> > and then  git format-patch  to generate mails for the patches I want to 
> > re-send and then read those patches in to re-alpine and send them.
> > To me that's not very painfull, but of course it may not match your 
> > workflow - just a description of mine :-) . 
> 
> Right, so I find cherry-picking and rebasing using git the most painful
> thing ever.
> 
> Also, using quilt you get a plain text version of the patch you can edit
> at your leisure, editing a git patch involves some export, import and
> rebase foo which is all too much work.
> 

Hmm, if I want to modify a patch in my queue I'll do something like this:

$ git checkout queue

$ git rebase --interactive HEAD~5  (or however long I need to go back)

## change the 'pick' for the patch I want to change to 'edit' in the list 
## that pops up in my editor.

## edit the files I need to edit

$ git add <modified files>

$ git commit --amend

## update patch description (if needed)

$ git rebase --continue

<done>

perhaps that seems too much work to you - for me it works just fine..


> Furthermore, using quilt I get help from useful tools like rej and meld
> git-merge otoh creates these god-awful merge markers that no tool can
> deal with.
> 
don't use those tools, so can't really comment.

> As for re-alpine, I might actually try it, you're the second one
> promoting it. Although I had somewhat hoped for a MUA like sup to become
> useful (or notmuch to grow a usable front-end). Traditional MUAs simply
> can't seem to cope well with today's number of emails.

Do yourself a favour, if you try it, and spend a bit of time in the Setup 
menu configuring it to the threading style you want, the headers you want 
displayed by default, etc etc... The defaults are less than perfect if you 
ask me, but it's quite configurable :)

-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Peter Zijlstra]

On Thu, 2011-07-14 at 01:03 +0200, Jesper Juhl wrote:
> Do yourself a favour, if you try it, and spend a bit of time in the Setup 
> menu configuring it to the threading style you want, the headers you want 
> displayed by default, etc etc... The defaults are less than perfect if you 
> ask me, but it's quite configurable :) 

It seems to suffer the same problem mutt does, trying to sort a folder
with a shade under 600000 emails in it doesn't work (500+ seconds in
waiting and still nothing).

Evolution seems to pull it off in a few seconds, I very frequently flip
between threaded and received time sort, evo's problem is in it
consuming a silly amount of memory to do it (current res footprint of
evo is 1.3g).

I thought this was a solved problem by the VLDB people way back in the
60s or 70s when 0.6M was still large.

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Jesper Juhl]

On Thu, 14 Jul 2011, Peter Zijlstra wrote:

> On Thu, 2011-07-14 at 01:03 +0200, Jesper Juhl wrote:
> > Do yourself a favour, if you try it, and spend a bit of time in the Setup 
> > menu configuring it to the threading style you want, the headers you want 
> > displayed by default, etc etc... The defaults are less than perfect if you 
> > ask me, but it's quite configurable :) 
> 
> It seems to suffer the same problem mutt does, trying to sort a folder
> with a shade under 600000 emails in it doesn't work (500+ seconds in
> waiting and still nothing).
> 
> Evolution seems to pull it off in a few seconds, I very frequently flip
> between threaded and received time sort, evo's problem is in it
> consuming a silly amount of memory to do it (current res footprint of
> evo is 1.3g).
> 
> I thought this was a solved problem by the VLDB people way back in the
> 60s or 70s when 0.6M was still large.
> 

Sure, some of the sort modes are slow - but only really slow on initial 
load. On refreshes it's much faster. So for someone like me, who just runs 
alpine in a screen on his server, that pain is minimal (only when I need 
to reboot the server do I have to pay the loooooong sort delay).

But, some sort modes are quick, and you can select them when starting 
alpine, like :   $ pine -sort arrival/reverse
That's about as quick as you can get if you just want to start it with a 
uge inbox anbd just have a quick look. But, if you just sort your inbox 
into smaller folders that takes a lot of the pain away. Personally I try 
to keep my inbox (and all other folders) below 20000 emails and then even 
the initial, first run, sorting delay is acceptable (to me).

-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Alan Cox]

On Wed, 13 Jul 2011 22:51:21 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2011-07-13 at 20:13 +0200, Jan H. Schönherr wrote:
> > From: =?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <schnhrr@cs.tu-berlin.de>
> 
> WTF am I to do with crap like that?! 

Fix your mail client ? It should be recognizing the UTF8 indicators, and
git itself is utf-8 clean.

Alan

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Peter Zijlstra]

On Thu, 2011-07-14 at 09:53 +0100, Alan Cox wrote:
> On Wed, 13 Jul 2011 22:51:21 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Wed, 2011-07-13 at 20:13 +0200, Jan H. Schönherr wrote:
> > > From: =?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <schnhrr@cs.tu-berlin.de>
> > 
> > WTF am I to do with crap like that?! 
> 
> Fix your mail client ? It should be recognizing the UTF8 indicators, and
> git itself is utf-8 clean.

So now we should all write complete email parsers? I thought the idea
was to use simple plain ASCII emails to that we could use scripts.

We might as well start accepting patches in attachments and force
everybody to do the MIME crap.

feh.

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Alan Cox]

On Thu, 14 Jul 2011 14:50:53 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, 2011-07-14 at 09:53 +0100, Alan Cox wrote:
> > On Wed, 13 Jul 2011 22:51:21 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Wed, 2011-07-13 at 20:13 +0200, Jan H. Schönherr wrote:
> > > > From: =?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <schnhrr@cs.tu-berlin.de>
> > > 
> > > WTF am I to do with crap like that?! 
> > 
> > Fix your mail client ? It should be recognizing the UTF8 indicators, and
> > git itself is utf-8 clean.
> 
> So now we should all write complete email parsers? I thought the idea
> was to use simple plain ASCII emails to that we could use scripts.

Unfortunately ASCII was invented by Americans and isn't even complete for
English let alone properly writing names in other languages. There are
another 5.75billion people out there !

Alan

Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[Jan Schönherr]

Am 14.07.2011 00:48, schrieb Jiri Kosina:
> I just have been CCed -- for some odd reason -- on the original patch, and
> wanted to defend Jan against your 'wtf shitty crap you are sending'
> offenses, as he did absolutely nothing wrong

Thanks for the defense. As a first time poster (hard trying to
do everything correct) I really appreciate that.

The "odd reason" is probably that I CC'd trivial@kernel.org...
In retrospect, maybe I should have prefixed the patch with
"trivial:"?!

... unwritten rules that you only learn by experience, I guess.

Regards
Jan

PS: Peter took the patch, so no point in becoming active.

Re: [PATCH 5/6] sched: Use leaf_cfs_rqs in load_balance_fair()

[Jan Schönherr]

Am 13.07.2011 22:44, schrieb Peter Zijlstra:
> On Wed, 2011-07-13 at 20:13 +0200, Jan H. Schönherr wrote:
>> Since commit 3d4b47b4 ("sched: Implement on-demand (active) cfs_rq list")
>> the leaf_cfs_rqs provide an advantage over the task_group list.
>>
>> Make use of it in load_balance_fair(), so that we do not unnecessarily
>> iterate over empty cfs_rqs where we cannot pull anything from.
> 
> I just send a similar patch today:
> 
> https://lkml.org/lkml/2011/7/13/94

Yes. I've seen that too late.

Sorry for the noise.

Regards
Jan

Re: [PATCH] sched: Separate group-scheduling code more clearly

[Peter Zijlstra]

On Thu, 2011-07-14 at 18:32 +0200, Jan H. Schönherr wrote:
> 
> I get your point, then what about doing it the other way round?
> The patch below should be more to your liking.

Yes, Thanks!

> One could do something similar with sched_init() to get rid of
> some #ifdefs, i. e. separating code based on features instead
> of handling all features intermixed. Not sure whether it is 
> worth the effort, though...

I'll try and remember next time someone needs to touch that code ;-)

> PS: This time with an extra From line, so that your tools hopefully
> work without any problems. :) 

They do, again thanks!

[tip:sched/core] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

[tip-bot for Jan Schoenherr]

Commit-ID:  5f817d676b7b7ac4a29f5ed93063ae7a24550c12
Gitweb:     http://git.kernel.org/tip/5f817d676b7b7ac4a29f5ed93063ae7a24550c12
Author:     Jan Schoenherr <schnhrr@cs.tu-berlin.de>
AuthorDate: Wed, 13 Jul 2011 20:13:31 +0200
Committer:  Ingo Molnar <mingo@elte.hu>
CommitDate: Thu, 21 Jul 2011 18:01:48 +0200

sched: Fix (harmless) typo 'CONFG_FAIR_GROUP_SCHED'

This patch fixes a typo located in a comment.

Signed-off-by: Jan Schoenherr <schnhrr@cs.tu-berlin.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1310580816-10861-2-git-send-email-schnhrr@cs.tu-berlin.de
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/sched.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 474f341..3b3826e 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -8362,7 +8362,7 @@ static inline void unregister_fair_sched_group(struct task_group *tg, int cpu)
 	list_del_leaf_cfs_rq(tg->cfs_rq[cpu]);
 	raw_spin_unlock_irqrestore(&rq->lock, flags);
 }
-#else /* !CONFG_FAIR_GROUP_SCHED */
+#else /* !CONFIG_FAIR_GROUP_SCHED */
 static inline void free_fair_sched_group(struct task_group *tg)
 {
 }

[tip:sched/core] sched: Do not attempt to destroy uninitialized rt_bandwidth

[tip-bot for Bianca Lutz]

Commit-ID:  99bc52429f11d1f4f81495ac8237085aaeb6bccf
Gitweb:     http://git.kernel.org/tip/99bc52429f11d1f4f81495ac8237085aaeb6bccf
Author:     Bianca Lutz <sowilo@cs.tu-berlin.de>
AuthorDate: Wed, 13 Jul 2011 20:13:36 +0200
Committer:  Ingo Molnar <mingo@elte.hu>
CommitDate: Thu, 21 Jul 2011 18:01:51 +0200

sched: Do not attempt to destroy uninitialized rt_bandwidth

If a task group is to be created and alloc_fair_sched_group() fails,
then the rt_bandwidth of the corresponding task group is not yet
initialized. The caller, sched_create_group(), starts a clean up
procedure which calls free_rt_sched_group() which unconditionally
destroys the not yet initialized rt_bandwidth.

This crashes or hangs the system in lock_hrtimer_base(): UP systems
dereference a NULL pointer, while SMP systems loop endlessly on a
condition that cannot become true.

This patch simply avoids the destruction of rt_bandwidth when the
initialization code path was not reached.

(This was discovered by accident with a custom kernel modification.)

Signed-off-by: Bianca Lutz <sowilo@cs.tu-berlin.de>
Signed-off-by: Jan Schoenherr <schnhrr@cs.tu-berlin.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1310580816-10861-7-git-send-email-schnhrr@cs.tu-berlin.de
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/sched.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 3b3826e..f107204 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -8383,7 +8383,8 @@ static void free_rt_sched_group(struct task_group *tg)
 {
 	int i;
 
-	destroy_rt_bandwidth(&tg->rt_bandwidth);
+	if (tg->rt_se)
+		destroy_rt_bandwidth(&tg->rt_bandwidth);
 
 	for_each_possible_cpu(i) {
 		if (tg->rt_rq)