lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 09 Nov 2009 20:15:37 -0500
From:	Gregory Haskins <gregory.haskins@...il.com>
To:	Lucas De Marchi <lucas.de.marchi@...il.com>
CC:	Gregory Haskins <ghaskins@...ell.com>, Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [lucas.de.marchi@...il.com: Bug when changing cpus_allowed of
 RT tasks?]

Lucas De Marchi wrote:
> On Mon, Nov 9, 2009 at 17:35, Gregory Haskins <ghaskins@...ell.com> wrote:
> 
>>>       static int select_task_rq_rt(struct task_struct *p, int sd_flag, int flags)
>>>       {
>>>               [...]
>>>               if (unlikely(rt_task(rq->curr)) &&
>>>                   (p->rt.nr_cpus_allowed > 1)) {
>>>                       int cpu = find_lowest_rq(p);
>>>
>>>                       return (cpu == -1) ? task_cpu(p) : cpu;
>>>               }
> 	/*
> 	 * Otherwise, just let it ride on the affined RQ and the
> 	 * post-schedule router will push the preempted task away
> 	 */
> 	return task_cpu(p);
> 
>>>       }
> I completed the rest of function to emphasize it will return task_cpu(p)
> afterwards.
> 
>> So the intent of this logic is to say "if the task is of type RT, and it can move, see if it can move
>> elsewhere".  Otherwise, we do not try to move it at all.
> 
> I'd say "if _current_ is of type RT, and _p_ can move, see if _p_ can move
> elsewhere". And this check is repeated for p inside find_lowest_rq, so it would
> not be needed here. Just let it call find_lowest_rq and -1 will be returned.

Ah, yes, "current" is correct.  My bad.


> 
>> Until further evidence is presented, I have to respectfully NAK the patch, as I do not think its doing the right thing
>> nor do I think the current code is actually broken.
> 
> I see now it's not doing the right thing. IMO only the double check of
> rt.nr_cpus_allowed is superfluous, but not wrong.
> 

Right.  I have a suspicion that the original code didn't have the
redundant check, but it was patched that way later.  I can't recall, tbh.

> 
> Thanks for clarifications

Np.

Kind Regards,
-Greg


Download attachment "signature.asc" of type "application/pgp-signature" (268 bytes)

Powered by blists - more mailing lists