Btrfs: fix error number in send.c
diff mbox

Message ID 201601220013.AA00000@WIN-5MHF4RKU941.jp.fujitsu.com
State New
Headers show

Commit Message

Tsutomu Itoh Jan. 22, 2016, 12:13 a.m. UTC
ENOTSUPP should not be returned to the user program.
 (cf. include/linux/errno.h)
Therefore, EOPNOTSUPP is used instead of ENOTSUPP.  

Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
---
 fs/btrfs/send.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

David Sterba Jan. 22, 2016, 2 p.m. UTC | #1
On Fri, Jan 22, 2016 at 09:13:25AM +0900, Tsutomu Itoh wrote:
> ENOTSUPP should not be returned to the user program.
>  (cf. include/linux/errno.h)
> Therefore, EOPNOTSUPP is used instead of ENOTSUPP.  

I'm not sure that EOPNOTSUPP is the right error code here. I'd rather
make it EINVAL, the bug we're talking about is a new type of inode
outside of the S_IFMT bits. "not supported" would mean we don't support
it but we could in theory.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tsutomu Itoh Jan. 25, 2016, 2:23 a.m. UTC | #2
Hi, David,

On 2016/01/22 23:00, David Sterba wrote:
> On Fri, Jan 22, 2016 at 09:13:25AM +0900, Tsutomu Itoh wrote:
>> ENOTSUPP should not be returned to the user program.
>>   (cf. include/linux/errno.h)
>> Therefore, EOPNOTSUPP is used instead of ENOTSUPP.
>
> I'm not sure that EOPNOTSUPP is the right error code here. I'd rather
> make it EINVAL, the bug we're talking about is a new type of inode
> outside of the S_IFMT bits. "not supported" would mean we don't support
> it but we could in theory.

Thanks for review.

In the meaning that btrfs-send is not supporting a new type of inode now,
EOPNOTSUPP is acceptable, I think.

Thanks,
Tsutomu

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Sterba Jan. 26, 2016, 1:01 p.m. UTC | #3
On Mon, Jan 25, 2016 at 11:23:51AM +0900, Tsutomu Itoh wrote:
> Hi, David,
> 
> On 2016/01/22 23:00, David Sterba wrote:
> > On Fri, Jan 22, 2016 at 09:13:25AM +0900, Tsutomu Itoh wrote:
> >> ENOTSUPP should not be returned to the user program.
> >>   (cf. include/linux/errno.h)
> >> Therefore, EOPNOTSUPP is used instead of ENOTSUPP.
> >
> > I'm not sure that EOPNOTSUPP is the right error code here. I'd rather
> > make it EINVAL, the bug we're talking about is a new type of inode
> > outside of the S_IFMT bits. "not supported" would mean we don't support
> > it but we could in theory.
> 
> Thanks for review.
> 
> In the meaning that btrfs-send is not supporting a new type of inode now,
> EOPNOTSUPP is acceptable, I think.

It is, there's a warning message printed anyway, the actual error code
does not matter much.

Reviewed-by: David Sterba <dsterba@suse.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 63a6152..b4229e8 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -2576,7 +2576,7 @@  verbose_printk("btrfs: send_create_inode %llu\n", ino);
 	} else {
 		btrfs_warn(sctx->send_root->fs_info, "unexpected inode type %o",
 				(int)(mode & S_IFMT));
-		ret = -ENOTSUPP;
+		ret = -EOPNOTSUPP;
 		goto out;
 	}