linux-ext4 - Re: [PATCH] extend e2fsprogs functionality to add EXT2_FLAG

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: <20100112124600.GA7151@infradead.org>
Date:	Tue, 12 Jan 2010 07:46:00 -0500
From:	Christoph Hellwig <hch@...radead.org>
To:	Michal Novotny <minovotn@...hat.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Ric Wheeler <rwheeler@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] extend e2fsprogs functionality to add EXT2_FLAG_DIRECT
	option

On Tue, Jan 12, 2010 at 01:30:40PM +0100, Michal Novotny wrote:
> Not really, pygrub doesn't do any manipulation with file system and  
> also, it's not working on a life file system. It's called before the  
> guest boots up to read information about grub.conf/initrd and kernel for  
> PV guest and after this is read and selected in pygrub then the guest is  
> booted using the kernel and initrd extracted from the image (after which  
> the file is closed). Once again, nothing uses write support and it was  
> added just to make it use O_DIRECT for both read and write operations  
> but only pygrub uses only read support and O_DIRECT passed here is the  
> only way to make it use non-cached data.

So what caches get in the way?  From the above it seems the situation
is the following:

 - filesystem N is a guest filesystem.  It's not usually mounted on the
   host, except for initial setup long time ago
 - before booting a guest your "pygrub" tools needs to read files on
   it, and it's doing so using e2fsprogs
 - once the guest is life it uses the extN kernel driver to access the
   filesystem

nowhere in this cycle you should have any stale cached data.  The kernel
always makes sure to write back data on umount/reboot, as does e2fsprogs
if actually used to write data (which you said is not the case anyway).

The only data that may be in the cache are unmodified data from reads
on the block device from either e2fsprogs or a suboptimal virtual block
device implementation, but these can't cause any problems.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html