linux-kernel - Possible scheduler bug

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:	Tue, 23 Aug 2011 20:58:43 -0500
From:	seth bollinger <seth.boll@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Possible scheduler bug

Hello All,

We recently ran into an interesting scheduler problem when testing one
of our products. It manifested itself as a user space lockup.  When I
enabled/printed scheduler stats I noticed that the scheduler was
always picking the same task to run, and no task stats were being
updated(clock, sum_exec, sum_sleep, etc.). The scheduler would become
stuck in this state permanently. This problem was ultimately resolved
by the following patch to sched.c

@@ -564,7 +569,7 @@ void check_preempt_curr(struct rq *rq, struct
task_struct *p, int flags)
         * A queue event has occurred, and we're going to schedule.  In
         * this case, we can save a useless back to back clock update.
         */
-       if (test_tsk_need_resched(p))
+       if (rq->curr->se.on_rq && test_tsk_need_resched(rq->curr))
                rq->skip_clock_update = 1;
 }

I have two questions regarding this patch.

1. How was it possible to get the scheduler locked up like that (prior
to patch application)?
2. After patch, is it possible that the scheduler could spin in this
loop until a sched_clock() tick (our clock resolution is unfortunately
10ms)?

We're currently running kernel version 2.6.35.14 on a freescale
i.MX28. I can provide the test code that reproduces the problem (or
explanation of what it does), or a more verbose explanation of the
problem and analysis I've done if it would help.

Thanks,

Seth Bollinger
--
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/