linux-kernel - Re: [RFC PATCH] vfs: add permute operation

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-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFwmUsDW+y0k2jgF-Z0uCiTP3FrioQEwU9ue7UAJVkCDtg@mail.gmail.com>
Date:	Thu, 30 May 2013 18:11:36 +0900
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	David Howells <dhowells@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Zach Brown <zab@...hat.com>
Subject: Re: [RFC PATCH] vfs: add permute operation

On Thu, May 30, 2013 at 5:45 PM, Miklos Szeredi <miklos@...redi.hu> wrote:
>
> The third name is because of the replace-empty-directory wart in the
> rename(2) definition.  With overlay/union that can become
>
>  1) check if destination directory is empty:  upper directory contains a
> whiteout for each lower directory entry and nothing else
>  2) if empty then remove whiteouts in destination directory
>  3) and then go on with the normal rename procedure, replacing the empty
> destination directory with the source directory ,
>
> This is done with directory locking, so atomicity is not usually a problem.
> But in case of a crash between 2) and 3)  we just seriously corrupted the
> overlay.
>
> Suggestions for fixing that?

Why not just do the NFS thing. That has worked forever - using a
sillyrename as a "pending deletion" instead of actually deleting
things.

So in between (1) and (2), silly-rename the pseudo-empty target. At
that point (2) is no longer even an atomicity requirement, because you
can do the whiteout removal later. In fact, you probably want to do it
at the end, after doing the "real" rename.

No, it's not perfect, but it works in practice. NFS may not be POSIX,
but nobody really cares. It's usable.

> We could just refuse to do the rename-over-empty-directory and see if anyone
> complains.  I don't think it's often used, but if something is documented
> then people are bound to find some stupid use for it.

I'm sure there are uses for it, since it's traditional unix behavior.
And I'm sure there are good reasons for it too (eg locking over NFS or
whatever)

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