linux-kernel - Re: [PATCH 01/24] Unionfs: Documentation

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:	Mon, 8 Jan 2007 22:53:17 +0100 (MET)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Erez Zadok <ezk@...sunysb.edu>
cc:	Andrew Morton <akpm@...l.org>,
	"Josef 'Jeff' Sipek" <jsipek@...sunysb.edu>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	hch@...radead.org, viro@....linux.org.uk, torvalds@...l.org,
	mhalcrow@...ibm.com, David Quigley <dquigley@...sunysb.edu>
Subject: Re: [PATCH 01/24] Unionfs: Documentation 

On Jan 8 2007 15:51, Erez Zadok wrote:
>
>BTW, this is a problem with all stackable file systems, including
>ecryptfs. To be fair, our Unionfs users have come up against this
>problem, usually for the first time they use Unionfs :-).  Then we
>tell not to do that, but that if they have to, to run "uniondbg -g"
>afterward to force a flushing of Unionfs caches.  This practical
>suggestion worked well for our Unionfs users so far.

Speaking of practicality, would not it be easiest to add a mount-time
option that says "don't ever cache"? Or perhaps "enable cache, I
assure you I don't fiddle with the lower layer".

>Another possibility is that after, hopefully, both Unionfs and
>ecryptfs are in, and some more user experience has been accumulated,
>that we'll look into addressing this page-cache consistency problem
>for all stacked f/s.

Not that I know much about memory handling, but...:

When a process writes to a file, the write is cached by default. If
now an origin tag (as in: a struct member) is attached to this cached
object, unionfs/VFS can decide whether the last write access has
happened from within unionfs or something else, and act accordingly,
namely (1) flush when origin tag is not "unionfs" (2) do as usual
like today's unionfs. Think of it like a "last changed by"-attribute.

	-`J'
-- 
-
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/