linux-kernel - Re: 2.6.25-rc3: 34TB vmalloc total -- overflow in /proc/meminfo?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0803052303590.16768@blonde.site>
Date:	Wed, 5 Mar 2008 23:21:08 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	Christian Kujau <lists@...dbynature.de>
cc:	Pavel Machek <pavel@....cz>,
	kernel list <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: 2.6.25-rc3: 34TB vmalloc total -- overflow in /proc/meminfo?

On Wed, 5 Mar 2008, Christian Kujau wrote:
> 
> Well, if it's "interesting"...here are some more details from the box:
> 
> http://nerdbynature.de/bits/2.6.19.2/

Thanks for putting that together; but I didn't find any clues.

> 
> > Unlikely.  Offhand I'm not quite sure that's impossible, but it's far
> > more likely that we've a kernel bug and vm_committed_space has wrapped
> > negative.
> 
> Huh. When I first saw this I thought "kernel bug" too, but then read the
> documentation to Committed_AS I thought it's just userspace related...

It's pretty sure to be userspace related i.e. kernel bug triggered by
particular userspace usage; and understandably, the bits you put there
don't tell me much about what userspace has been up to.  (And don't
worry, I'm not expecting you to tell me more!  I can't think of
anything useful to ask about it - it's not a question of what mix
of apps you have running there, it's a matter of what system calls,
especially mmaps, they make - I'm not expecting traces of that.)

> 
> > Ancient as your kernel is, I don't notice anything in the ChangeLogs
> > since then to say we've fixed a bug of that kind since 2.6.19.
> > Any idea how to reproduce this?
> 
> Well, the box is running fine and since it's a production machine I don't
> intend to reboot the box very often.

Absolutely.  You mentioned it because it's useful for us to know there's
such an issue about, to keep our eyes open: thank you for doing so.
No need for you to go any further out of your way on it.

> And since it's really an old kernel (for
> lkml discussion, that is) I don't intend to debug this one further. I really
> was only curious if this was userspace related (some app overcommitting) or
> some kernel weirdness.
> 
> > Are you using HugePages at all?
> 
> I have:
> 
> # CONFIG_HUGETLBFS is not set
> # CONFIG_HUGETLB_PAGE is not set
> 
> ...was this, what you meant?

Right, I was forgetting that the various "HugePage" lines of /proc/meminfo
don't even appear when those are configured off, so my question was more
obscure than I'd intended.  You're not using HugePages at all, so we
can rule out that line of inquiry - that's helpful, thanks.

I'll keep my eyes open.

Hugh
--
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/