lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 22 Jan 2014 21:15:13 -0500
From:	Sasha Levin <sasha.levin@...cle.com>
To:	David Rientjes <rientjes@...gle.com>
CC:	khlebnikov@...nvz.org, Andrew Morton <akpm@...ux-foundation.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ