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

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: <200712141521.24227.nickpiggin@yahoo.com.au>
Date:	Fri, 14 Dec 2007 15:21:23 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	David Howells <dhowells@...hat.com>
Cc:	viro@....linux.org.uk, hch@...radead.org,
	Trond.Myklebust@...app.com, sds@...ho.nsa.gov,
	casey@...aufler-ca.com, linux-kernel@...r.kernel.org,
	selinux@...ho.nsa.gov, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 24/28] AFS: Add a function to excise a rejected write from the pagecache [try #2]

On Thursday 06 December 2007 06:40, David Howells wrote:
> Add a function - cancel_rejected_write() - to excise a rejected write from
> the pagecache.  This function is related to the truncation family of
> routines.  It permits the pages modified by a network filesystem client
> (such as AFS) to be excised and discarded from the pagecache if the attempt
> to write them back to the server fails.
>
> The dirty and writeback states of the afflicted pages are cancelled and the
> pages themselves are detached for recycling.  All PTEs referring to those
> pages are removed.
>
> Note that the locking is tricky as it's very easy to deadlock against
> truncate() and other routines once the pages have been unlocked as part of
> the writeback process.  To this end, the PG_error flag is set, then the
> PG_writeback flag is cleared, and only *then* can lock_page() be called.

This reintroduces the fault vs truncate race window, which must be fixed.

Also, it is adding a fair bit of complexity in an area where we should
instead be reducing it. I think your filesystem should not be doing
writeback caching of dirty data in the cases where it is so problematic
(or at least, disallow mmap and read on the dirty data until it has been
written back or failed).

But otherwise I guess if you really want to discard the dirty data after
a failed writeback attempt, what's wrong with just invalidate_inode_pages2?
--
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/