Re: v3.4 BUG: Bad rss-counter state

[Hugh Dickins <hughd@google.com>]

On Mon, 9 Apr 2012, Konstantin Khlebnikov wrote:
> Markus Trippelsdorf wrote:
> > On 2012.04.08 at 13:39 +0200, Markus Trippelsdorf wrote:
> > > I've hit the following warning after I've tried to link Firofox's libxul
> > > with "-flto -lto-partition=none" on my machine with 8GB memory. I've

I've no notion of what's unusual in that link.

> > > killed the process after it used all the memory and 90% of my swap

Does doing that link push you well into swap on 3.3?

There's a separate mail thread which implicates
CONFIG_ANDROID_LOW_MEMORY_KILLER (how appropriately named!) in memory
leaks on 3.4, so please switch that off if you happened to have it on -
unless you're keen to reproduce these rss-counter messages for us.

> > > space. Before the machine was rebooted I saw these messages:
> > > 
> > > Apr  8 13:11:08 x4 kernel: BUG: Bad rss-counter state mm:ffff88020813c380
> > > idx:1 val:-1
> > > Apr  8 13:11:08 x4 kernel: BUG: Bad rss-counter state mm:ffff88020813c380
> > > idx:2 val:1
> > > Apr  8 13:11:08 x4 kernel: BUG: Bad rss-counter state mm:ffff88021503bb80
> > > idx:1 val:-1
> > > Apr  8 13:11:08 x4 kernel: BUG: Bad rss-counter state mm:ffff8801fb643b80
> > > idx:1 val:-1
> > > Apr  8 13:11:08 x4 kernel: BUG: Bad rss-counter state mm:ffff8801fb643b80
> > > idx:2 val:1
> > > Apr  8 13:11:08 x4 kernel: BUG: Bad rss-counter state mm:ffff88021503bb80
> > > idx:2 val:1
> > > Apr  8 13:11:08 x4 kernel: BUG: Bad rss-counter state mm:ffff88020a4ff800
> > > idx:1 val:-1
> > > Apr  8 13:11:08 x4 kernel: BUG: Bad rss-counter state mm:ffff88020a4ff800
> > > idx:2 val:1
> > > Apr  8 13:11:08 x4 kernel: BUG: Bad rss-counter state mm:ffff88020813ce00
> > > idx:1 val:-1
> > > Apr  8 13:11:08 x4 kernel: BUG: Bad rss-counter state mm:ffff88020813ce00
> > > idx:2 val:1
> > > Apr  8 13:11:08 x4 kernel: BUG: Bad rss-counter state mm:ffff8801fadda680
> > > idx:1 val:-1
> > > Apr  8 13:11:08 x4 kernel: BUG: Bad rss-counter state mm:ffff8801fadda680
> > > idx:2 val:1

Bringing back some text from Markus's original posting:

> > > These warnings were introduced by c3f0327f8e9d7. Wouldn't it make sense to hide
> > > them under some debugging option? AFAICS they contain no information that could
> > > be of any use to a casual user.

Yes, I agree, I would prefer it under CONFIG_DEBUG_VM (as I said at the
time); and KERN_ALERT is way over the top, KERN_WARNING more appropriate.

However, it is very interesting that they have revealed something,
which would have been missed if they hadn't annoyed Markus in this way:
a patch around -rc7 to make it KERN_WARNING under CONFIG_DEBUG_VM would
be good, but until then let's see what else comes up.

> > 
> > BTW, I'm not the only one that sees these messages. Here are two more
> > reports from Ubuntu beta testers:
> > 
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/963672
> > BUG: Bad rss-counter state mm:ffff88022107fb80 idx:1 val:-14
> > BUG: Bad rss-counter state mm:ffff88022107fb80 idx:2 val:14
> > 
> > 
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/965709
> > BUG: Bad rss-counter state mm:c8fd9dc0 idx:1 val:-2
> > BUG: Bad rss-counter state mm:c8fd9dc0 idx:2 val:2
> > usb 5-1: USB disconnect, device number 2
> > usb 5-1: new low-speed USB device number 3 using uhci_hcd
> > input: Mega World Thrustmaster dual analog 3.2 as
> > /devices/pci0000:00/0000:00:1d.0/usb5/5-1/5-1:1.0/input/input13
> > generic-usb 0003:044F:B315.0004: input,hidraw1: USB HID v1.10 Gamepad
> > [Mega World Thrustmaster dual analog 3.2] on usb-0000:00:1d.0-1/input0
> > BUG: Bad rss-counter state mm:c8fd9dc0 idx:1 val:-2
> > BUG: Bad rss-counter state mm:c8fd9dc0 idx:2 val:2
> > BUG: Bad rss-counter state mm:dea3cc40 idx:1 val:-1
> > BUG: Bad rss-counter state mm:dea3cc40 idx:2 val:1
> > 
> > The pattern seem to be:
> > ... idx:1 val:-x
> > ... idx:2 val:x
> > for x=1,2,14
> > 
> 
> Ok, thanks. I'll try to figure out how this is happened.

Thanks: I looked around but didn't find it.

All the numbers, of course, indicate a ptentry being counted as swap
when it's inserted, but anon when it's removed.

I was suspicious of the mm_counter args stuff in fs/exec.c at first;
but I think that that is self-consistent (doesn't matter if entries
get swapped out), despite being an unusual way of using the counters.

zap_pte()'s else block in mm/fremap.c looks ignorant of migration
entries and mm_counters, and ought to be updated; but I think it's
very unlikely to be the cause of the cases seen (sys_remap_file_pages
is unusual in itself, applying it to an already populated area even
more unusual, finding anon-or-swap entries in a VM_SHARED area even
more unusual).

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>