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
| ||
|
Date: Mon, 30 Jun 2008 14:19:27 -0400 From: Erez Zadok <ezk@...sunysb.edu> To: Hugh Dickins <hugh@...itas.com> Cc: Christoph Hellwig <hch@...radead.org>, Erez Zadok <ezk@...sunysb.edu>, Andrew Morton <akpm@...ux-foundation.org>, mhalcrow@...ibm.com, hooanon05@...oo.co.jp, viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] fsstack: fsstack_copy_inode_size locking In message <Pine.LNX.4.64.0806291244440.32708@...nde.site>, Hugh Dickins writes: > On Sun, 29 Jun 2008, Christoph Hellwig wrote: > > > > Btw, I hope fsstack doesn't rely on i_size having any particular > > meaning. As far as the VFS is concerned i_size is field only used by > > the filesystem (or library routines like generic_file_*). > > Interesting point. I can't speak for fsstack itself (I'm not even > sure if it's anything beyond fs/stack.c and the tag I used to identify > where this patch lies); but certainly fs/stack.c doesn't use i_size > for anything, just duplicates it from the lower filesystem. > > unionfs (which I think you don't care for at all in general) does > look as if it assumes it's the lower file size in a few places, > when copying up or truncating. Isn't that reasonable? Wouldn't > users make the same assumption? > > Or are you saying that filesystems which don't support the usual > meaning of inode->i_size (leave it 0?) would supply their own > equivalent to vmtruncate() if they support truncation, and their > own getattr which fills in stat->size from somewhere else. > > Yes, I think you are saying that: unionfs may not play well with them. > > Hugh Hugh, yes, the only place in fsstack where i_size is used is to copy the lower i_size to the upper one verbatim. If this assumption is incorrect for some lower file systems, then stackable file systems in general may have a problem with this assumption; in that case, we'll need an alternative way to "interpret" the lower i_size, and report the i_size in the upper inode (and hence to the user). Is there such an alternative? BTW, ecryptfs may have a problem with this, b/c it uses i_size_read/write b/t the lower and upper inodes. If some filesystems have a different interpretation for i_size, then stacking ecryptfs on top of them could be an issue. Mike? Erez. -- 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/
Powered by blists - more mailing lists