On Thu, 27 Oct 2011 09:51:33 EDT, Jeffrey Walton said: > On Thu, Oct 27, 2011 at 9:43 AM, xD 0x41 <secn3t@xxxxxxxxx> wrote: > > You try to change and fiddle here, it would need alot better than just > > the current shell scripting, and, even then, i dnt think it would win > > the race conditiobn. > See Bishop and Dilger's paper: > nob.cs.ucdavis.edu/bishop/papers/1996-compsys/racecond.pdf The other thing that people need to remember is that there's no race condition that's so small that you can't hit it. If there's a race condition, it *can* be won. A while back, a bug was found in the Linux kernel that caused an I/O driver to hang - it got debugged because one guy's machine was tripping over it *totally by accident* every few weeks. It turned out that the timing hole was aboud *3 instructions wide* (two lines of code were reversed, allowing an interrupt to happen one line earlier than was actually safe). Yes - at 3.2Ghz, you're looking at a hole *literally* about a billionth of a second wide - and this guy was hitting it accidentally every 2 weeks or so. And for userspace races, it's usually pretty easy to increase the size of the hole by waiting till just before the hole begins, then spawning a whole bunch of processes that just do 'for(;;)' (or possibly a syscall in a tight loop, depending on the details) - basically just spike the load average way up. This will overwhelm the scheduler (note that with proper timing, none of the just forked processes will accumulate enough time for the scheduler to relabel them as cycle-suckers and will still look "interactive" and likely to schedule). Hopefully this gets you scheduled into the timing hole.
Attachment:
pgp2mefYc6u4s.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/