linux-kernel - Re: [PATCH] sched: Transform resched_task() into resched

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 29 Jun 2014 12:59:41 +0400
From:	Kirill Tkhai <tkhai@...dex.ru>
To:	Andreas Mohr <andi@...as.de>
CC:	linux-kernel@...r.kernel.org, peterz@...radead.org,
	mingo@...hat.com
Subject: Re: [PATCH] sched: Transform resched_task() into resched_curr()

On 29.06.2014 12:36, Andreas Mohr wrote:
> Hi,
> 
> On Sun, Jun 29, 2014 at 11:57:49AM +0400, Kirill Tkhai wrote:
>> resched_curr(rq) means "to reschedule current task of the rq". It does
>> not reschedule rq itself.
>>
>> We already have resched_cpu(), which has cpu agrument, and it's not
>> a task. I think this is just a similar case and we won't have any
>> problems because of this.
>>
>> We only can reschedule the current task, and the patch underlines that fact.
> 
> OK. I was arguing almost purely mechanically, and from a mechanical POV
> I had some doubts.
> 
> I just noticed that there is a part touching rq->idle,
> and ISTR that idle task handling is "special"
> (after all that's the power management side of things).
> Specifically, rq->curr and rq->idle are distinct rq members
> (since they are distinct tasks AFAIK!),
> so there might now be some issues with task state tracking here
> (unless this cleanup happens to unify handling here anyway).

Are you worrying about check_preempt_curr_idle()? I've looked
at check_preempt_curr() and found, we never call this function
in current scheduler logic.

It's called only if just enqueued task is of the same class as
rq's current, but we can't have two idle class tasks enqueued
on the same rq. So, it's just a stub. We can do not worry
about this.

Thanks,
Kirill
--
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/