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: Wed, 03 Mar 2010 18:28:49 +0100 From: Miklos Szeredi <miklos@...redi.hu> To: Valerie Aurora <vaurora@...hat.com> CC: viro@...iv.linux.org.uk, hch@...radead.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, vaurora@...hat.com Subject: Re: [RFC PATCH 0/6] Union mount core rewrite v1 On Tue, 2 Mar 2010, Valerie Aurora wrote: > This is a major rewrite of parts of union mounts, in particular the > pathname lookup code. For more info about union mounts, see: > > http://valerieaurora.org/union/ > > The previous code had two important problems fixed in this series: > > - On file open, is_unionized() grabs vfsmount lock and walks up the > mount tree even for non-union mounts. > > - Pathname lookup required three cut-n-pasted versions of two complex > functions, one for each of cached/real/"hashed" lookups. Looks much better :) > This rewrite reduces the additional cost of a non-union lookup in a > CONFIG_UNION_MOUNT kernel to either 1 or 2 mount flag tests (but adds > the requirement that file systems be unioned only at their root > directories). This rewrite implements lookup with one lookup_union() > function for all types of lookups. > > This posted patch series includes only the union lookup, mount, and > readdir patches and not the relatively uncontroversial whiteout and > fallthru code. Special inode/dentry flags (whiteout, fallthrough, opaque) are not trivially the right solution: - they are invisible from userspace, new APIs are necessary to manipulate them - they are difficult to support on network filesystems - they are not useful for anything other than union mounts/filesystems Extended attributes are a more standard way to add such info to files. Hard links would allow sharing a single inode for all whiteout entries and one for all fallthrough entries. Have these options been considered as an alternative? Thanks, Miklos -- 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