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
| ||
|
Date: Fri, 7 Mar 2014 16:47:39 +0100 From: Sebastian Andrzej Siewior <bigeasy@...utronix.de> To: Marc Kleine-Budde <mkl@...gutronix.de> Cc: David Miller <davem@...emloft.net>, linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org, kernel@...gutronix.de 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: > >http://lxr.free-electrons.com/source/kernel/sched/core.c#L3599 > >> * 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. >Marc Sebastian -- 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/
Powered by blists - more mailing lists