> > Ok. I was going by the comments in > > Documentation/volatile-considered-harmful.txt > > where cpu_relax() is also used as a memory barrier. > > I thought you might; I've just submitted a patch for that to akpm, lkml > and linux-arch.
Cheers, I'll take a read. > > In the KGDB case [where this cropped up], if cpu_relax() is left as it is, > > then > > an smp_mb() is required in the architecture independent code. This also > > seems wrong > > because it's only needed for the ARM11MPCore. There may also potentially be > > other > > situations in the Kernel which are prone to deadlock because it is assumed > > that the > > write buffer will always drain. > > Why is KGDB being special about this? Ah yes, it's being brain dead: <snip> > Clearly, kgdb is using atomic_set()/atomic_read() in a way which does not > match this documentation - it's certainly missing the barriers as required > by the above quoted paragraphs. > > Let me repeat: atomic_set() and atomic_read() are NOT atomic. There's > nothing atomic about them. All they do is provide a pair of accessors > to the underlying value in the atomic type. They are no different to > declaring a volatile int and reading/writing it directly. Indeed. I'm not familiar enough with KGDB internals to dive in and look at all the potential barrier conflicts, so I'll submit a patch that addresses the one that's bitten me so far. Maybe it will motivate somebody else to take a closer look! Cheers, Will ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
