On Fri, Jun 19, 2015 at 06:34:18PM +0200, Sebastian Andrzej Siewior wrote: > Clark stumbled over a VM_BUG_ON() in -RT which was then was removed by > Johannes in commit f371763a79d ("mm: memcontrol: fix false-positive > VM_BUG_ON() on -rt"). The comment before that patch was a tiny bit > better than it is now. While the patch claimed to fix a false-postive on > -RT this was not the case. None of the -RT folks ACKed it and it was not a > false positive report. That was a *real* problem. The real problem is that irqs_disabled() on -rt is returning false negatives. Having it return false within a spin_lock_irq() section is broken. > This patch updates the comment that is improper because it refers to > "disabled preemption" as a consequence of that lock being taken. A > spin_lock() disables preemption, true, but in this case the code relies on > the fact that the lock _also_ disables interrupts once it is acquired. And > this is the important detail (which was checked the VM_BUG_ON()) which needs > to be pointed out. This is the hint one needs while looking at the code. It > was explained by Johannes on the list that the per-CPU variables are protected > by local_irq_save(). The BUG_ON() was helpful. This code has been workarounded > in -RT in the meantime. I wouldn't mind running into more of those if the code > in question uses *special* kind of locking since now there is no no > verification (in terms of lockdep or BUG_ON()). I'd be happy to re-instate the VM_BUG_ON that checks for disabled interrupts as before, that was the most obvious documentation. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>