Messages in this thread | | | Date | Thu, 11 Jul 2002 00:19:55 -0700 | From | george anzinger <> | Subject | Re: spinlock assertion macros |
| |
Daniel Phillips wrote: > > On Thursday 11 July 2002 01:36, Jesse Barnes wrote: > > On Thu, Jul 11, 2002 at 12:24:06AM +0200, Daniel Phillips wrote: > > > Acme, which is to replace all those above-the-function lock coverage > > > comments with assert-like thingies: > > > > > > spin_assert(&pagemap_lru_lock); > > > > > > And everbody knows what that does: when compiled with no spinlock > > > debugging it does nothing, but with spinlock debugging enabled, it oopses > > > unless pagemap_lru_lock is held at that point in the code. The practical > > > effect of this is that lots of 3 line comments get replaced with a > > > one line assert that actually does something useful. That is, besides > > > documenting the lock coverage, this thing will actually check to see if > > > you're telling the truth, if you ask it to. > > > > > > Oh, and they will stay up to date much better than the comments do, > > > because nobody needs to to be an ueber-hacker to turn on the option and > > > post any resulting oopses to lkml. > > > > Sounds like a great idea to me. Were you thinking of something along > > the lines of what I have below or perhaps something more > > sophisticated? I suppose it would be helpful to have the name of the > > lock in addition to the file and line number... > > I was thinking of something as simple as: > > #define spin_assert_locked(LOCK) BUG_ON(!spin_is_locked(LOCK)) > > but in truth I'd be happy regardless of the internal implementation. A note > on names: Linus likes to shout the names of his BUG macros. I've never been > one for shouting, but it's not my kernel, and anyway, I'm happy he now likes > asserts. I bet he'd like it more spelled like this though: > > MUST_HOLD(&lock); > > And, dare I say it, what I'd *really* like to happen when the thing triggers > is to get dropped into kdb. Ah well, perhaps in a parallel universe...
I should hope that, when BUG executes the unimplemented instruction, it does go directly to kdb. It certainly does with my kgdb, as do all Oops, NULL dereferences, etc., etc. > > When one of these things triggers I do think you want everything to come to > a screeching halt, since, to misquote Matrix, "you're already dead", and you > don't want any one-per-year warnings to slip off into the gloomy depths of > some forgotten log file. > > -- > Daniel > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |