On Thu, 2010-11-04 at 13:02 -0500, Amir G. wrote: > Hi, > > We are seeing corruption of parent stack after fork of a multi-threaded process. > Something that resembles this reported bug: > > http://wiki.parisc-linux.org/TestCases#head-b2a1d5999b1b7cbc6878005693440f9e2960e895 > > We have been seeing this bug on and off for the past year. very hard > to reproduce it. > > The only thing is... we are running our kernel (2.6.32) on ARM, > so I am thinking this problem may be either a generic kernel problem > or common to PA-RISC and ARM. > I don't see anywhere that this problem was ever solved. > > Anyway, I am sitting at Arnd's presentation in LPC at the moment (good talk). > If any of you guys are present, please let me know so we can discuss > the issue face to face. OK, so just to summarise the rather hurried discussion for those not present: I'd always assumed that this problem is parisc specific because no other vipt architecture saw it. However it is possible it's some I/D incoherency issue within the generic kernel itself ... it's just a lot rarer on other architectures. If you see it on arm, this would confirm that view. The main difference between PA and other VIPT architectures is that our equivalency modulus for aliasing is much bigger (we have a 4MB stride). So what I'll do is have a look into this again. I recently successfully resurrected the tmpalias flushing patches (these eliminate the possibility that it's some kind of TLB handling error because they allow cache flushes without a corresponding TLB entry), but I'll look at our generic paths again ... my greatest suspicions would be the handle_mm_fault() path. But basically, the summary is that we see the issue but have never solved it. James -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
