linux-kernel - Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs)

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:	Thu, 22 Nov 2007 13:16:28 +1100
From:	Bron Gondwana <brong@...tmail.fm>
To:	Bron Gondwana <brong@...tmail.fm>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christian Kujau <lists@...dbynature.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	robm@...tmail.fm
Subject: Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel
	Bugs)

On Thu, Nov 22, 2007 at 10:51:15AM +1100, Bron Gondwana wrote:
> On Thu, Nov 15, 2007 at 08:32:22AM -0800, Linus Torvalds wrote:
> > If this patch makes a difference, please holler. I think it's the correct 
> > thing to do, but I'm not going to actually commit it without somebody 
> > saying that it makes a difference (and preferably Peter Zijlstra and 
> > Andrew acking it too).
> 
> mmap: mmap call failed: errno: 12 errmsg: Cannot allocate memory
> 
> Yep, that's "fixed" the problem alright!  No way this puppy is
> dirtying 2Gb of memory any more.
> 
> http://linux.brong.fastmail.fm/2007-11-22/bmtest.pl

Alternatively perhaps I'm just a moron who used a config file with:
CONFIG_PAGE_OFFSET=0x80000000 set to build the new kernel (I hadn't
committed it because it turned out not to solve the issue it was
there for).  That would explain a few things.

[root@lb1 perl]$ free
             total       used       free     shared    buffers     cached
Mem:       4150620    2272284    1878336          0      11212    2066536
-/+ buffers/cache:     194536    3956084
Swap:      2096472          0    2096472

That's more the usage I would expect to see.

Now for the downside.  It works again, but it still runs slow.  Seems to
hit (and this is totally unscientific, I'm just watching the numbers
scroll by) at about 120000 writes rather than 70000 writes, but that's
still not fitting the while file dirty.

I notice that PF_LESS_THROTTLE gets set by nfsd to get an extra 25%
bonus free space allocated.  Potentially dcc could use similar tricks
to claim extra space if that knob is available up in userspace.  I'm
happy to patch dcc as well if I have to, I'm already backporting it,
so adding another little quilt directory and applying it is pretty
trivial (must try guilt/stgit one of these days)

Bron.

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