LKML Archive on
help / color / mirror / Atom feed
From: Steven Rostedt <>
To: Ingo Molnar <>
Cc: LKML <>,
	Thomas Gleixner <>,
	Peter Zijlstra <>,
	Linus Torvalds <>,
	Andrew Morton <>
Subject: Re: [PATCH] ring-buffer: add paranoid checks for loops
Date: Thu, 30 Oct 2008 15:00:59 -0400 (EDT)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, 30 Oct 2008, Ingo Molnar wrote:
> hm, all those magic constants look a bit like voodoo and make the 
> patch ugly, and people who read this will be confused about the 
> purpose for sure.

Point taken.

> But the checks are still worth having in practice. So could you please 
> improve the comments, to come up with some tangible calculation that 
> leads to these constants?
> For example the '1000' constant, how did you come to that? Could you 
> estimate what type of interrupt storm is needed to trigger it falsely? 
> So instead of this comment:

My original number was 100,000, but I thought that a bit high ;-)
Since it is OK for an interrupt to preempt this code and perform a trace, 
which would make the condition fail by the one being preempted. The 
likelyhood of an interrupt coming in at that location 1000 times in a row 
seems to be awefully low. It's not enough that a 1000 interrupts come in, 
the task being preempted must loop 1000 times and have a trace interrupt 
cause the condition to fail each time. I'll explain it this way in the 

I picked a big number because I can see a traced interrupt that is very 
active causing several interruptions in this code.

> > +	 * If we loop here 1,000 times, that means we are either
> > +	 * in an interrupt storm, or we have something buggy.
> > +	 * Bail!
> something like this might look more acceptable:
> > +	 * If we loop here 1,000 times, that means we are either
> > +	 * in an interrupt storm that preempted the same trace-entry
> > +	 * attempt 1000 times in a row, or we have a bug in the tracer.
> > +	 * Bail!
> i.e. please exaplain every single magic number there so that it can be 
> followed how you got to that number, and what precise effects that 
> number has.
> In the cases where you just guessed a number based on experiments, 
> please think it through and insert an analysis about the effects of 
> that number.
> Would this be doable?

Again, there are small "allowable" races that causes the code to loop a 
few times.  I'll try to explain them a bit better in the comments.
There's small races between the reader and writer that can hit just right 
to cause a "loop again". But these chances are much smaller than the 
interrupt tracing situation.

I'll look deeper at the reasons for the races and explain them a bit 


-- Steve

  reply	other threads:[~2008-10-30 19:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-29 22:48 Steven Rostedt
2008-10-30 18:45 ` Ingo Molnar
2008-10-30 19:00   ` Steven Rostedt [this message]
2008-10-31  3:16   ` [PATCH -v2] " Steven Rostedt
2008-10-31  9:38     ` Ingo Molnar
2008-10-31 13:58       ` [PATCH -v3] " Steven Rostedt
2008-11-03 10:10         ` Ingo Molnar
2008-10-31 14:00       ` [PATCH -v2] " Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] ring-buffer: add paranoid checks for loops' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).