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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 7 Mar 2014 16:47:39 +0100
From:	Sebastian Andrzej Siewior <>
To:	Marc Kleine-Budde <>
Cc:	David Miller <>,,,,
Subject: Re: [PATCH] net: sched: dev_deactivate_many(): use msleep(1) instead
 of yield() to wait for outstanding qdisc_run calls

* Marc Kleine-Budde | 2014-03-06 22:39:58 [+0100]:

>> Therefore it should allow lower priority threads to run, not just
>> equal or higher priority ones.
>Yes, we need a call that does what you described, however I'm not sure
>if yield() really does that. According to:
>> * Typical broken usage is:
>> *
>> * while (!event)
>> *      yield();
>> *
>> * where one assumes that yield() will let 'the other' process run that will
>> * make event true. If the current task is a SCHED_FIFO task that will never
>> * happen. Never use yield() as a progress guarantee!!
>My Process runs with SCHED_FIFO and prio > 50, with IRQ at default prio,
>which is 50.
>Maybe the RT guys can comment on this. I found another interesting
>function in the RT patch set: cpu_chill().

If you boot mainline without -RT, use threadirqs, start your application
do the same prio thing then you should end up with exactly the same
outcome. Please say so :)

msleep() is safe as long as it is used outside of the softirq. Nice that
you found cpu_chill() but on non-RT it turns to cpu_relax() and you do
not want this here.

wait_event() would be nice in the end to have. For now I take that patch
for -RT.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists