Messages in this thread | | | Date | Wed, 22 Jan 2014 21:15:13 -0500 | From | Sasha Levin <> | Subject | Re: mm: BUG: Bad rss-counter state |
| |
On 01/22/2014 08:39 PM, David Rientjes wrote: > On Wed, 22 Jan 2014, Sasha Levin wrote: > >> Hi all, >> >> While fuzzing with trinity running inside a KVM tools guest using latest -next >> kernel, >> I've stumbled on a "mm: BUG: Bad rss-counter state" error which was pretty >> non-obvious >> in the mix of the kernel spew (why?). >> > > It's not a fatal condition and there's only a few possible stack traces > that could be emitted during the exit() path. I don't see how we could > make it more visible other than its log-level which is already KERN_ALERT.
Would it make sense to add a VM_BUG_ON() to make it more obvious when we have CONFIG_VM_DEBUG enabled? Many of the VM_BUG_ON test cases are non-fatal either, and it would make it easier spotting this issue.
>> I've added a small BUG() after the printk() in check_mm(), and here's the full >> output: >> > > Worst place to add it :) At line 562 of kernel/fork.c in linux-next > you're going to hit BUG() when there may be other counters that are also > bad and they don't get printed.
I gave the condition before curly braces :)
if (unlikely(x)) { printk(KERN_ALERT "BUG: Bad rss-counter state " "mm:%p idx:%d val:%ld\n", mm, i, x); BUG(); }
>> [ 318.334905] BUG: Bad rss-counter state mm:ffff8801e6dec000 idx:0 val:1 > > So our mm has a non-zero MM_FILEPAGES count, but there's nothing that was > cited that would tell us what that is so there's not much to go on, unless > someone already recognizes this as another issue. Is this reproducible on > 3.13 or only on linux-next?
Yup, I see it in v3.13 too, which is odd.
Thanks, Sasha
| |