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, 15 Nov 2007 13:14:32 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc:	Bron Gondwana <brong@...tmail.fm>,
	Christian Kujau <lists@...dbynature.de>,
	Andrew Morton <akpm@...ux-foundation.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, 15 Nov 2007, Linus Torvalds wrote:
> 
> Unacceptable. We used to do exactly what your patch does, and it got fixed 
> once. We're not introducing that fundamentally broken concept again.

Examples of non-broken solutions:
 (a) always use lowmem sizes (what we do now)
 (b) always use total mem sizes (sane but potentially dangerous: but the 
     VM pressure should work! It has serious bounce-buffer issues, though, 
     which is why I think it's crazy even if it's otherwise consistent)
 (c) make all dirty counting be *purely* per-bdi, so that everybody can 
     disagree on what the limits are, but at least they also then use 
     different counters

So it's just the "different writers look at the same dirty counts but then 
interpret it to mean totally different things" that I think is so 
fundamentally bogus. I'm not claiming that what we do now is the only way 
to do things, I just don't think your approach is tenable.

Btw, I actually suspect that while (a) is what we do now, for the specific 
case that Bron has, we could have a /proc/sys/vm option to just enable 
(b). So we don't have to have just one consistent model, we can allow odd 
users (and Bron sounds like one - sorry Bron ;) to just force other, odd, 
but consistent models.

I'd also like to point out that while the "bounce buffer" issue is not so 
much a HIGHMEM issue on its own (it's really about the device DMA limits, 
which are _independent_ of HIGHMEM, of course), the reason HIGHMEM is 
special is that without HIGHMEM the bounce buffers generally work 
perfectly fine.

The problem with HIGHMEM is that it causes various metadata (dentries, 
inodes, page struct tables etc) to eat up memory "prime real estate" under 
the same kind of conditions that also dirty a lot of memory. So the reason 
we disallow HIGHMEM from dirty limits is only *partly* the per-device or 
mapping DMA limits, and to a large degree the fact that non-highmem memory 
is special in general, and it is usually the non-highmem areas that are 
constrained - and need to be protected.

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