linux-kernel - Re: [PATCH 04/11] vfs: add renameat2 syscall

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]

Date:	Thu, 21 Nov 2013 13:37:31 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>,
	Zach Brown <zab@...hat.com>, Jan Kara <jack@...e.cz>,
	Andy Lutomirski <luto@...capital.net>,
	"mszeredi@...e.cz" <mszeredi@...e.cz>
Subject: Re: [PATCH 04/11] vfs: add renameat2 syscall

On Thu, Nov 21, 2013 at 5:10 AM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> Hi all,
>
> On Wed, 20 Nov 2013 14:01:45 +0100 Miklos Szeredi <miklos@...redi.hu> wrote:
>>
>> From: Miklos Szeredi <mszeredi@...e.cz>
>>
>> Add new renameat2 syscall, which is the same as renameat with an added
>> flags argument.
>>
>> Pass flags to vfs_rename() and to i_op->rename() as well.
>>
>> All filesystems check flags and return -EOPNOTSUPP for unsupported flags.
>
> Can we please consider doing this slightly slower (and avoiding
> conflicts/missed new uses etc) by creating a new i_op callback and only
> implementing this when necessary?
>
> From past experience, I can just about guarantee that the patch as it is
> will cause conflicts (for me in linux-next if noone else) and a new use
> case will turn up before (or during) the next merge window.

I understand, but it makes little sense to have two i_op's with almost
exactly the same functionality, so at some point they are bound to be
merged, resulting in the same pain.

So Linus, how about applying the patches 1-4 at the end of this merge
window?  These are simple with no functional changes.  And then the
meat of the patchset can go into the next merge window without fear of
conflicts.

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/