linux-kernel - Re: [PATCH 11/11] ext4: add cross rename support

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:	Mon, 20 Jan 2014 12:50:10 +0100
From:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	"J. Bruce Fields" <bfields@...ldses.org>, Jan Kara <jack@...e.cz>,
	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>,
	Andy Lutomirski <luto@...capital.net>,
	"mszeredi@...e.cz" <mszeredi@...e.cz>
Subject: Re: [PATCH 11/11] ext4: add cross rename support

On Mon, Jan 20, 2014 at 12:39 PM, Miklos Szeredi <miklos@...redi.hu> wrote:
> On Sat, Jan 18, 2014 at 5:27 PM, J. Bruce Fields <bfields@...ldses.org> wrote:
>> On Sat, Jan 18, 2014 at 07:49:29AM +0100, Miklos Szeredi wrote:
>>> On Fri, Jan 17, 2014 at 11:08 PM, J. Bruce Fields <bfields@...ldses.org> wrote:
>>> > On Fri, Jan 17, 2014 at 11:53:07PM +1300, Michael Kerrisk (man-pages) wrote:
>>> >> >        The following additional errors are defined for renameat2():
>>> >> >
>>> >> >        EOPNOTSUPP
>>> >> >               The filesystem does not support a flag in flags
>>> >>
>>> >> This is not the usual error for an invalid bit flag. Please make it EINVAL.
>>> >
>>> > I agree that EINVAL makes sense for an invalid bit flag.
>>> >
>>> > But renameat2() can also fail when the caller passes a perfectly valid
>>> > flags field but the paths resolve to a filesystem that doesn't support
>>> > the RENAME_EXCHANGE operation.  EOPNOTSUPP looks more appropriate in
>>> > that case.
>>>
>>> OTOH, from the app's perspective, it makes little difference whether a
>>> particular kernel doesn't support the reanameat2 syscall, or it
>>> doesn't support RENAME_FOO flag or if it does support RENAME_FOO but
>>> not in all filesystems.  In all those cases it has to just fall back
>>> to something supported and it doesn't matter *why* it wasn't
>>> supported.
>>
>> Well, in theory it could allow an optimization:
>>
>>         if (kernel_has_foo) {
>>                 ret = rename(.,.,.,.,RENAME_FOO);
>>                 if (ret && errno == EINVAL)
>>                         kernel_has_foo = 0;
>>         }
>>         if (!kernel_has_foo)
>>                 fallback...
>>
>> or maybe even:
>>
>>         if (kernel_has_foo && fs_has_foo[fsid])
>>                 ret = rename(.,.,.,.,RENAME_FOO);
>>                 if (ret && errno == EINVAL)
>>                         kernel_has_foo = 0;
>>                 if (ret && errno == EOPNOTSUPP)
>>                         fs_has_foo[fsid] = 0;
>>         }
>>         if (!kernel_has_foo || !fs_has_foo[fsid])
>>                 fallback...
>>
>> which may both be of dubious value--unless, say, you're implementing a
>> network protocol and making this distinction to your client allows it to
>> save server round trips.
>>
>> That may not be *totally* farfetched--if for example we added rename2 to
>> the nfs protocol then servers probably will be required to make this
>> sort of distinction per filesystem, exactly to allow client logic like
>> the above.
>
> I understand, but that's a protocol issue, not a filesystem issue.
> The server will need to determine per-filesystem if the operation is
> supported or not, but that doesn't depend on the error value returned
> by the filesystem.
>
>> And as long as we can, I'd just rather give the caller more information
>> than less.
>>
>> As for precedent for EOPNOTSUPP: grepping through man-pages the one
>> documented use of EOPNOTSUPP I see for filesystems is fallocate, for a
>> similar "filesystem doesn't support this operation" case.  "git grep
>> EOPNOTSUPP fs/" in the kernel repo suggests there are many more such,
>> but I haven't tried to figure out what any of them are.
>
> The reason I chose EOPNOTSUPP is because it has the specific meaning:
> "this operation is not supported, try to fall back to something else".
>  EINVAL just means "something" is invalid.  That would most likely be
> the "flags" argument in this specific case, and hence it works for
> renameat2().
>
> And differentiating between the "per-filesystem supported" and the
> "per kernel supported" thing based on the error value would also work.
>   I don't really have a preference and I don't think it's a big deal.
>
> Michael?

I don't really have enough knowledge to know if EOPNOTSUPP would be
appropriate for "per-filesystem supported". I called the invalid
'flags' out, because EINVAL is the standard error for invalid flags.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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/