Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1577628 > unrolled thread

[PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs Paul Durrant <paul.durrant@citrix.com> - 2017-02-09 15:20 +0100
    Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for  unimplemented IOCTLs "Jan Beulich" <JBeulich@suse.com> - 2017-02-09 15:50 +0100
      RE: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for  unimplemented IOCTLs Paul Durrant <Paul.Durrant@citrix.com> - 2017-02-09 16:40 +0100
      Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for  unimplemented IOCTLs Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-02-09 20:40 +0100

#1577628 — [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

The code goes so far as to set the default return code to -ENOSYS but
then overrides this to -EINVAL in the switch() statement's default
case.

This patch removes this pointless and incorrect override.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
---
 drivers/xen/privcmd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 6e3306f..b4e5e27 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -572,7 +572,6 @@ static long privcmd_ioctl(struct file *file,
 		break;
 
 	default:
-		ret = -EINVAL;
 		break;
 	}
 
-- 
2.1.4

[toc] | [next] | [standalone]

#1577657 — Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

>>> On 09.02.17 at 15:17, <paul.durrant@citrix.com> wrote:
> The code goes so far as to set the default return code to -ENOSYS but
> then overrides this to -EINVAL in the switch() statement's default
> case.

If you already change this, isn't -ENOTTY the traditional way of
indicating unsupported ioctls?

Jan

[toc] | [prev] | [next] | [standalone]

#1577702 — RE: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

> -----Original Message-----
> From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]
> Sent: 09 February 2017 15:26
> To: Jan Beulich <JBeulich@suse.com>; Paul Durrant
> <Paul.Durrant@citrix.com>
> Cc: xen-devel@lists.xenproject.org; Juergen Gross <JGross@suse.com>;
> linux-kernel@vger.kernel.org
> Subject: Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for
> unimplemented IOCTLs
> 
> 
> 
> On 02/09/2017 09:40 AM, Jan Beulich wrote:
> >>>> On 09.02.17 at 15:17, <paul.durrant@citrix.com> wrote:
> >> The code goes so far as to set the default return code to -ENOSYS but
> >> then overrides this to -EINVAL in the switch() statement's default
> >> case.
> >
> > If you already change this, isn't -ENOTTY the traditional way of
> > indicating unsupported ioctls?
> 
> In fact, a while ago David submitted a patch to do just that:
> 
> https://lists.xenproject.org/archives/html/xen-devel/2016-
> 08/msg00744.html
> 
> but it never went anywhere.
> 
> My question is whether anyone might be relying on current error return
> behavior.

I doubt it. It's certainly not a safe thing to do anyway. I'll change to -ENOTTY in v2 of the patch.

  Paul

> 
> 
> -boris

[toc] | [prev] | [next] | [standalone]

#1577899 — Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

On 02/09/2017 09:40 AM, Jan Beulich wrote:
>>>> On 09.02.17 at 15:17, <paul.durrant@citrix.com> wrote:
>> The code goes so far as to set the default return code to -ENOSYS but
>> then overrides this to -EINVAL in the switch() statement's default
>> case.
>
> If you already change this, isn't -ENOTTY the traditional way of
> indicating unsupported ioctls?

In fact, a while ago David submitted a patch to do just that:

https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg00744.html

but it never went anywhere.

My question is whether anyone might be relying on current error return 
behavior.


-boris

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web