full-disclosure - Re: [Code-Crunchers] a simple race condition and how you'd solve it

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

Date: Fri, 3 Jul 2009 09:34:37 +0530
From: Phani <pklanka@...il.com>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Code-Crunchers] a simple race condition and
	how you'd solve it

I may be seriously wrong here; But how about implementing a simple bool
cache as a check for cache result computation.

result = cache.select(input)
if result:
    return result
resultcompute = cache.select(resultcompute)
if (resultcompute == true) {
     while(!cache.select(resultcompute)) {
      }
     return cache.select(result)
}
if resultcompute = null {
     cache.insert(resultcompute, true)
     result = compute(input)
     cache.insert(input, result)
     cache.insert(resultcompute, false)
}
return result

I think above code would work enough. I does not remove racy condition in
totality though. E.g. For a condition if two threads are accessing boolean
cache variable at the same time. But since boolean computation and inserting
into cache is a millisecond effort, this probability of two threads coming
at this point at same time is very much reduced.

regards
Phani


On Fri, Jul 3, 2009 at 7:34 AM, <Valdis.Kletnieks@...edu> wrote:

> On Fri, 03 Jul 2009 11:01:34 +1000, silky said:
>
> > Basically, you just need to check if you should still be computing,
> > and, at the end of computation, if your data is still "wanted".
>
> All that does is push the race condition around.  You *still* need to
> do some sort of locking around the tail end.  This is still racy:
>
>    if (update_still_wanted) {
>        stash_my_update();
>        update_still_wanted = false;
>    }
>
> (Admittedly, not *as* racy, especially if you move the assignment first.
> But
> that's still racy enough to actually *trip* on occasion - this sort of bug
> is actually found at least once a month in the Linux kernel in some device
> driver or other...)
>
> And to be honest - the "best" way of fixing this is *really* going to
> depend on
> the relative weight of locking (which can be *very* different if you have 2
> threads on 2 CPUs, or 4096 threads on a 4096-core monster, or are split
> across
> systems possibly in different countries connected by a high or maybe low
> speed
> network), and how much effort goes into the computation, and how much
> correctness matters - for some cases, you *really* want "first to finish"
> (possibly due to side effects of the computation), others "any complete
> answer"
> is good enough, etc..
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/