linux-kernel - Re: [RFC][PATCH] block: Isolate the buffer cache in it's own mappings.

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:	Wed, 17 Oct 2007 21:32:16 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	ebiederm@...ssion.com (Eric W. Biederman)
Cc:	Chris Mason <chris.mason@...cle.com>,
	Christian Borntraeger <borntraeger@...ibm.com>,
	Nick Piggin <nickpiggin@...oo.com.au>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	"Theodore Ts'o" <tytso@....edu>, stable@...nel.org
Subject: Re: [RFC][PATCH] block: Isolate the buffer cache in it's own
 mappings.

On Wed, 17 Oct 2007 21:59:02 -0600 ebiederm@...ssion.com (Eric W. Biederman) wrote:

> If filesystems care at all they want absolute control over the buffer
> cache.  Controlling which buffers are dirty and when.  Because we
> keep the buffer cache in the page cache for the block device we have
> not quite been giving filesystems that control leading to really weird
> bugs.
> 
> In addition this tieing of the implemetation of block device caching
> and the buffer cache has resulted in a much more complicated and
> limited implementation then necessary.  Block devices for example
> don't need buffer_heads, and it is perfectly reasonable to cache
> block devices in high memory.
> 
> To start untangling the worst of this mess this patch introduces a
> second block device inode for the buffer cache.  All buffer cache
> operations are diverted to that use the new bd_metadata_inode, which
> keeps the weirdness of the metadata requirements isolated in their
> own little world.

I don't think we little angels want to tread here.  There are so many
weirdo things out there which will break if we bust the coherence between
the fs and /dev/hda1.  Online resize, online fs checkers, various local
tools which people have hacked up to look at metadata in a live fs,
direct-io access to the underlying fs, heaven knows how many boot loader
installers, etc.  Cerainly I couldn't enumerate tham all.

The mere thought of all this scares the crap out of me.

I don't actually see what the conceptual problem is with the existing
implementation.  The buffer_head is a finer-grained view onto the
blockdev's pagecache: it provides additional states and additional locking
against a finer-grained section of the page.   It works well.

Yeah, the highmem thing is a bit of a problem (but waning in importance). 
But we can fix that by teaching individual filesystems about kmap and then
tweak the blockdev's caching policy with mapping_set_gfp_mask() at mount
time.  If anyone cares, which they don't.
-
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/