linux-kernel - Re: [PATCH 2/4] AFS: Add a function to excise a rejected write from the pagecache

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] [day] [month] [year] [list]

Message-Id: <1180546740.6770.15.camel@heimdal.trondhjem.org>
Date:	Wed, 30 May 2007 13:39:00 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	David Howells <dhowells@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] AFS: Add a function to excise a rejected write
	from the pagecache

On Wed, 2007-05-30 at 11:35 +0100, David Howells wrote:
> Trond Myklebust <trond.myklebust@....uio.no> wrote:
> 
> > All I do is to protect new calls to read() and write() with a call to
> > check if the page cache needs invalidating.
> 
> What about mmap()?  What if someone gets a mapping on a section of file that
> subsequently has a write rejected on it?  If you invalidate only on
> read()/write(), what do you do about such a mapping?

Same philosophy: The people who already have the file mapped will
already be working with corrupted data, so there is little point in
bending over backwards to "fix" the problem. Instead we flush out the
page cache using invalidate_inode_pages2() whenever someone tries to
mmap() a new section of the file.

Trond

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