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]
Message-ID: <20071115115049.GA8297@brong.net>
Date:	Thu, 15 Nov 2007 22:50:49 +1100
From:	Bron Gondwana <brong@...tmail.fm>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Bron Gondwana <brong@...tmail.fm>,
	Christian Kujau <lists@...dbynature.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, robm@...tmail.fm
Subject: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs)

On Wed, Nov 14, 2007 at 09:53:38PM -0800, Linus Torvalds wrote:
> 
> 
> On Wed, 14 Nov 2007, Linus Torvalds wrote:
> > 
> > So even at 100% dirty limits, it won't let you dirty more than 1GB on the 
> > default 32-bit setup.
> 
> Side note: all of these are obviously still just heuristics. If you really 
> *do* run on a 32-bit kernel, and you want to have the pain, I'm sure you 
> can just disable the dirty limits with a one-liner kernel mod. And if it's 
> useful enough, we can certainly expose flags like that.. Not that I expect 
> that much anybody else will ever care, but it's not like it's wrong to 
> expose the silly heuristics the kernel has to users that have very 
> specific loads.
> 
> That said, I still do hope you aren't actually using HIGHMEM64G. I was 
> really hoping that the people who had enough moolah to buy >4GB of RAM had 
> long since also upgraded to a 64-bit machine ;)

I'm afraid we are, which probably explains it.

We have a bunch of 64 bit machines, but this particular machine
is one of our somewhat more ancient IBM x235 machines.  It's
got stacks of fast SCSI drives and a couple of hyperthreading
Xeons in it.  Very nice machine in its day, and very reliable
which is why we have kept them, even though at 6RU it chews
through disk space.

Unfortunately none of the 64 bit machines are world facing,
and we're running HIGHMEM64G on a bunch of machines both for
consistency value and because we only have one machine left
with only 2Gb.

I guess we'll be doing the one-liner kernel mod and testing
that then.  I'd certainly like to build a test case anyway
so I'm not spending too much time rebooting that machine,
it's also our outbound SMTP gateway.

And I'll keep in mind finding a 64 bit capable machine for
the role when I can.

Thanks for the feedback on this - I'll come back with more
details once we've done some testing, but this sounds likely,
and I don't think DCC is going to change how it works, so
we're stuck supporting it.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ