> From: Jörg Sommer [mailto:joerg@xxxxxxxxxxxx] > Sent: Monday, March 12, 2012 2:01 PM > To: Greg Kroah-Hartman > Cc: Dan Magenheimer; Seth Jennings; devel@xxxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH] zcache: Use WARN_ON_SMP in ASSERT_SPINLOCK > > Greg Kroah-Hartman hat am Sun 11. Mar, 19:50 (-0700) geschrieben: > > On Sun, Mar 11, 2012 at 10:00:54PM +0100, Jörg Sommer wrote: > > > As the description of WARN_ON_SMP in bug.h says, one can not use > > > spin_is_locked() in assertions for non‐SMP configurations, because it > > > always returns the lock is not held. Otherwise a warning is thrown > > > everytime on a uniprocessor system. > > > --- > > > drivers/staging/zcache/tmem.h | 2 +- > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > diff --git a/drivers/staging/zcache/tmem.h b/drivers/staging/zcache/tmem.h > > > index ed147c4..b543694 100644 > > > --- a/drivers/staging/zcache/tmem.h > > > +++ b/drivers/staging/zcache/tmem.h > > > @@ -47,7 +47,7 @@ > > > #define ASSERT_INVERTED_SENTINEL(_x, _y) do { } while (0) > > > #endif > > > > > > -#define ASSERT_SPINLOCK(_l) WARN_ON(!spin_is_locked(_l)) > > > +#define ASSERT_SPINLOCK(_l) WARN_ON_SMP(!spin_is_locked(_l)) > > > > Why do we even have asserts in this code in the first place? Shouldn't > > they all be removed by now? > > I don't know, why the asserts are there. But if the asserts get removed, > the sentinel zones can be removed, too, because noone checks them. This > would be a big interference. If the code is stable enough, it can be > cleaned up. But I can't say anything about it. I couldn't use zcache > until now, because the kernel flooded the log with warnings. > > Regards, Jörg. > -- > Der Klügere gibt so lange nach bis er der Dumme ist. Hi Jorg and Greg -- Jorg, thanks for fixing that! I admit I never run with SMP disabled anymore so I'm sorry it interfered with your use. Greg, I think while zcache is continuing rapid development (e.g Seth and Nitin's new allocator, my RAMster layer built on top of zcache, etc.) and being used by new architectures (PowerPC and ARM), it makes sense to retain the assertions. Most or all should be removed before promotion out of staging. If you disagree, please let us know! Dan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel