--
On Sat, 25 Aug 2007, Frank Ch. Eigler wrote:
>
> Steven Rostedt <[email protected]> writes:
>
> > [...]
> > + * [...] We don't need to grab
> > + * any locks, we just keep trying until get all the
> > + * calculations together in one state.
> > + *
> > + * In fact, we __cant__ grab any locks. This
> > + * function is called from the latency_tracer which can
> > + * be called anywhere. To grab any locks (including
> > + * seq_locks) we risk putting ourselves into a deadlock.
>
> Perhaps you could add a comment about why the loop, which appears
> potentially infinite as written, avoids livelock. (It looks rather
> like a seqlock read loop.)
>
I guess I need to rewrite that comment. It shouldn't appear infinitely
looping, since it is basically: do { x=A; func() } while (x != A); which
to me seems that while is most likely to fail unless something touches A.
But yes, it _is_ basically a seq lock, but its on what we are working
with. And we don't even need any memory barriers that a seq lock might
do, since it is very obvious to gcc that the function call can modify the
variables that we are testing.
But do you still think that looks inifinte? If so, I'll reword it.
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
