linux-kernel - Re: [PATCH 17/39] union-mount: Union mounts 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 5 May 2010 09:06:40 -0400
From:	Valerie Aurora <vaurora@...hat.com>
To:	Valdis.Kletnieks@...edu
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Jan Blunck <jblunck@...e.de>
Subject: Re: [PATCH 17/39] union-mount: Union mounts documentation

On Mon, May 03, 2010 at 09:54:12PM -0400, Valdis.Kletnieks@...edu wrote:
> On Mon, 03 May 2010 16:12:16 PDT, Valerie Aurora said:
> 
> > +File copyup
> > +-----------
> > +
> > +Any system call that alters the data or metadata of a file on the
> > +bottom layer, or creates or changes a hard link to it will trigger a
> > +copyup of the target file from the lower layer to the topmost layer
> > +
> > + - open(O_WRITE | O_RDWR | O_APPEND | O_DIRECT)
> > + - truncate()/open(O_TRUNC)
> > + - link()
> > + - rename()
> > + - chmod()
> > + - chown()/lchown()
> > + - utimes()
> > + - setxattr()/lsetxattr()
> 
> I spent some time looking at patch 27 trying to figure it out for myself,
> but my lack of splice()-fu doomed me. :)
> 
> A few quick questions:
> 
> 1) For calls like chmod() that only touch the metadata, does it still
> trigger a copyup of the data, or just the affected metadata?

Yes, it copies up the whole file.  Right now there's no concept of
part of the file on one layer and part on another.

> 2) Is the copyup of data synchronous or async done in the background?
> The comments in union_copyup_len() about "We raced with someone else"
> imply this is synchronous - if so. probably a note should be made that
> an open() may take a little while under some conditions.  There's a *lot* of
> code out there that assumes that open() calls are *really* cheap.

It's synchronous.  Code that assumes open() calls are cheap will have
to be rewritten. :)

> I wonder how many programs don't correctly deal with an ENOSPC on open() of
> an already existing file.

I'm not too worried about that - how many programs deal correctly with
ENOSPC when it is normally returned?

-VAL
--
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/