linux-kernel - Question regarding put_prev

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-next>] [day] [month] [year] [list]

Date:	Sun, 9 Jun 2013 23:59:36 +0800
From:	Lei Wen <adrian.wenl@...il.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>
Subject: Question regarding put_prev_task in preempted condition

Hi Peter,

While I am checking the preempt related code, I find a interesting part.
That is when preempt_schedule is called, for its preempt_count be added
PREEMPT_ACTIVE, so in __schedule() it could not be dequeued from rq
by deactivate_task.

Thus in put_prev_task, which is called a little later in __schedule(), it
would call put_prev_task_fair, which finally calls put_prev_entity.
For current task is not dequeued from rq, so in this function, it would
enqueue it again to the rq by __enqueue_entity.

Is there any reason to do like this, since entity already is over rq,
why need to queue it again?

And if current rq's vruntime distribution like below, and vruntime with 8
is the task that would be get preempted. So in __enqueue_entity,
its rb_left/rb_right would be set as NULL and reinserted into this RB tree.
Then seems to me now, the entity with vruntime of 3 would be disappeared
from the RB tree.
            13
           /  \
         8    19
        /  \
      3    11

I am not sure whether I understand the whole process correctly...
Would the example as above happen in our real life?

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