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]
Message-ID: <CAJfpegsNuTOm5VJV9XLt9qu=wZ_-kRCEsmaWHr4M4sxw=WS9tg@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ