On Mon, Oct 08, 2012 at 02:08:02PM -0500, Eric Sandeen wrote: > I had suggested this on the other list, but will put it here too, though it > might be a long shot. If threadinfo gets corrupted, the irqs_enabled() > test might give the wrong answer. > > Peter also mentioned that he had tried putting WARN_ON(irqs_disabled()) at > various places along the stack above and never got it to trip; until after > the BUG_ON() had fired; this makes me think corruption might be a possibility > after all. Well, there is absolutely no place where we disable interrupts in ext3. In ext4 we do have some spinlock_irqsave/irqresture() calls, but they are tightly bracketed --- and since you can reproduce this with ext3, I think that pretty much exonerates ext4. Hmm.... one possibility might be that it's some XEN-specific paravirt call that happens to be called by ext3/ext4 and which is leaving interrupts disabled on its return due to a missing irqrestore() call? Can you reproduce the problem if you disable XEN and run this on a native system? What if you run a kernel w/o auditing but under Xen? Maybe that will allow you to figure out what the critical variable might be? I'll note that if ext3 or ext4 was playing with interrupts and leaving them disabled, we'd have a huge number of people complaining. So the question is whether it's something unique to audit, or unique to Xen, or perhaps the combination of the two.... - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
