linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 4/4] ->compat_ioctl for 390 tape_char
@ 2005-11-04 22:18 Christoph Hellwig
  2005-11-04 23:10 ` Arnd Bergmann
  0 siblings, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2005-11-04 22:18 UTC (permalink / raw)
  To: akpm, schwidefsky; +Cc: linux-kernel

The only own ioctl, TAPE390_DISPLAY, is compat_clean, everything else
is routed through common translation code.


Index: linux-2.6/drivers/s390/char/tape_char.c
===================================================================
--- linux-2.6.orig/drivers/s390/char/tape_char.c	2005-11-02 11:18:41.000000000 +0100
+++ linux-2.6/drivers/s390/char/tape_char.c	2005-11-02 11:19:12.000000000 +0100
@@ -37,6 +37,8 @@
 static int tapechar_release(struct inode *,struct file *);
 static int tapechar_ioctl(struct inode *, struct file *, unsigned int,
 			  unsigned long);
+static long tapechar_compat_ioctl(struct file *, unsigned int,
+			  unsigned long);
 
 static struct file_operations tape_fops =
 {
@@ -44,6 +46,7 @@
 	.read = tapechar_read,
 	.write = tapechar_write,
 	.ioctl = tapechar_ioctl,
+	.compat_ioctl = tapechar_compat_ioctl,
 	.open = tapechar_open,
 	.release = tapechar_release,
 };
@@ -463,6 +466,21 @@
 	return device->discipline->ioctl_fn(device, no, data);
 }
 
+static long
+tapechar_compat_ioctl(struct file *filp, unsigned int no, unsigned long data)
+{
+	struct tape_device *device = filp->private_data;
+	int rval = -ENOIOCTLCMD;
+
+	if (device->discipline->ioctl_fn) {
+		lock_kernel();
+		rval = device->discipline->ioctl_fn(device, no, data);
+		unlock_kernel();
+	}
+
+	return rval;
+}
+
 /*
  * Initialize character device frontend.
  */
Index: linux-2.6/arch/s390/kernel/compat_ioctl.c
===================================================================
--- linux-2.6.orig/arch/s390/kernel/compat_ioctl.c	2005-11-02 11:19:08.000000000 +0100
+++ linux-2.6/arch/s390/kernel/compat_ioctl.c	2005-11-02 11:19:24.000000000 +0100
@@ -42,9 +42,6 @@
 #include <linux/compat_ioctl.h>
 #define DECLARES
 #include "../../../fs/compat_ioctl.c"
-
-/* s390 only ioctls */
-COMPATIBLE_IOCTL(TAPE390_DISPLAY)
 };
 
 int ioctl_table_size = ARRAY_SIZE(ioctl_start);

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 4/4] ->compat_ioctl for 390 tape_char
  2005-11-04 22:18 [PATCH 4/4] ->compat_ioctl for 390 tape_char Christoph Hellwig
@ 2005-11-04 23:10 ` Arnd Bergmann
  2005-11-04 23:51   ` Christoph Hellwig
  0 siblings, 1 reply; 5+ messages in thread
From: Arnd Bergmann @ 2005-11-04 23:10 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: akpm, schwidefsky, linux-kernel

On Freedag 04 November 2005 23:18, Christoph Hellwig wrote:
> The only own ioctl, TAPE390_DISPLAY, is compat_clean, everything else
> is routed through common translation code.
> 
> 

> +tapechar_compat_ioctl(struct file *filp, unsigned int no, unsigned long data)
> +{
> +       struct tape_device *device = filp->private_data;
> +       int rval = -ENOIOCTLCMD;
> +
> +       if (device->discipline->ioctl_fn) {
> +               lock_kernel();
> +               rval = device->discipline->ioctl_fn(device, no, data);
> +               unlock_kernel();
> +       }
> +
> +       return rval;
> +}

Hmm, isn't ->compat_ioctl called before the translation lookup? If so,
this code would return -EINVAL from tape_34xx_ioctl and result in never
entering the conversion for MTIO* at all.

The same problem seems to be in the other patches of this series, but
I could also be mistaken.

BTW, I now have a set of 25 patches that moves all handlers from
fs/compat_ioctl.c over to the respective drivers and subsystems,
but I'm not sure how to best test that.
I intend to at least give it a test run on my Opteron for the whatever
ioctls I normally use, but the rest is just guesswork. Christoph,
can you review those patches?

	Arnd <><

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 4/4] ->compat_ioctl for 390 tape_char
  2005-11-04 23:10 ` Arnd Bergmann
@ 2005-11-04 23:51   ` Christoph Hellwig
  2005-11-05  1:16     ` Arnd Bergmann
  0 siblings, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2005-11-04 23:51 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: Christoph Hellwig, akpm, schwidefsky, linux-kernel

On Sat, Nov 05, 2005 at 12:10:46AM +0100, Arnd Bergmann wrote:
> Hmm, isn't ->compat_ioctl called before the translation lookup?

Yes.

> If so,
> this code would return -EINVAL from tape_34xx_ioctl and result in never
> entering the conversion for MTIO* at all.

we return -ENOIOCTLCMD if we didn't have a valid compat ioctl, and in
that case the vfs code will try to find it in the core translation
table.

> BTW, I now have a set of 25 patches that moves all handlers from
> fs/compat_ioctl.c over to the respective drivers and subsystems,
> but I'm not sure how to best test that.
> I intend to at least give it a test run on my Opteron for the whatever
> ioctls I normally use, but the rest is just guesswork. Christoph,
> can you review those patches?

I'm not sure moving everything from fs/compat_ioctl.c is a good idea.
Everything that is just in a single driver or subsystem that has
common ioctl code - sure.  else it doesn't make a lot of sense.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 4/4] ->compat_ioctl for 390 tape_char
  2005-11-04 23:51   ` Christoph Hellwig
@ 2005-11-05  1:16     ` Arnd Bergmann
  2005-11-07  4:01       ` Christoph Hellwig
  0 siblings, 1 reply; 5+ messages in thread
From: Arnd Bergmann @ 2005-11-05  1:16 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: akpm, schwidefsky, linux-kernel

On Sünnavend 05 November 2005 00:51, Christoph Hellwig wrote:
> we return -ENOIOCTLCMD if we didn't have a valid compat ioctl, and in
> that case the vfs code will try to find it in the core translation
> table.

No, the function you wrote returns -ENOIOCTLCMD only if
device->discipline->ioctl_fn is NULL, otherwise it returns the
code it gets from that function, which is -EINVAL.

> I'm not sure moving everything from fs/compat_ioctl.c is a good idea.
> Everything that is just in a single driver or subsystem that has
> common ioctl code - sure.  else it doesn't make a lot of sense.

It turns out that almost everything is a single driver, the exceptions
are:

- tty ioctls: I move the conversion into drivers/char/tty_io.c with a
  relatively big switch() statement. All drivers implementing these
  use tty_operations.
- block ioctl: similar for drivers/block/ioctl.c
- net ioctl: similar for net/compat.c. I also add compat_ioctl methods
  for proto_ops.
- cdrom, tape, v4l: I create a new file that contains a compat_ioctl
  file operation that can be used in each driver, either by pointing
  directly to it or by calling it from their own compat_ioctl
  handler. The handlers end up calling f_op->ioctl() internally.
- file systems: many file systems implement EXT2_IOC_GETFLAGS etc.
  those are trivial to handle, so I duplicate the code for each of those
  file systems.

	Arnd <><

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 4/4] ->compat_ioctl for 390 tape_char
  2005-11-05  1:16     ` Arnd Bergmann
@ 2005-11-07  4:01       ` Christoph Hellwig
  0 siblings, 0 replies; 5+ messages in thread
From: Christoph Hellwig @ 2005-11-07  4:01 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: Christoph Hellwig, akpm, schwidefsky, linux-kernel

On Sat, Nov 05, 2005 at 02:16:56AM +0100, Arnd Bergmann wrote:
> On S?nnavend 05 November 2005 00:51, Christoph Hellwig wrote:
> > we return -ENOIOCTLCMD if we didn't have a valid compat ioctl, and in
> > that case the vfs code will try to find it in the core translation
> > table.
> 
> No, the function you wrote returns -ENOIOCTLCMD only if
> device->discipline->ioctl_fn is NULL, otherwise it returns the
> code it gets from that function, which is -EINVAL.

indeed.  updated patch below that handles that case.  I couldn't find
a problem like that in the other patches.


Index: linux-2.6/drivers/s390/char/tape_char.c
===================================================================
--- linux-2.6.orig/drivers/s390/char/tape_char.c	2005-11-06 20:06:55.000000000 +0100
+++ linux-2.6/drivers/s390/char/tape_char.c	2005-11-06 20:19:11.000000000 +0100
@@ -37,6 +37,8 @@
 static int tapechar_release(struct inode *,struct file *);
 static int tapechar_ioctl(struct inode *, struct file *, unsigned int,
 			  unsigned long);
+static long tapechar_compat_ioctl(struct file *, unsigned int,
+			  unsigned long);
 
 static struct file_operations tape_fops =
 {
@@ -44,6 +46,7 @@
 	.read = tapechar_read,
 	.write = tapechar_write,
 	.ioctl = tapechar_ioctl,
+	.compat_ioctl = tapechar_compat_ioctl,
 	.open = tapechar_open,
 	.release = tapechar_release,
 };
@@ -463,6 +466,23 @@
 	return device->discipline->ioctl_fn(device, no, data);
 }
 
+static long
+tapechar_compat_ioctl(struct file *filp, unsigned int no, unsigned long data)
+{
+	struct tape_device *device = filp->private_data;
+	int rval = -ENOIOCTLCMD;
+
+	if (device->discipline->ioctl_fn) {
+		lock_kernel();
+		rval = device->discipline->ioctl_fn(device, no, data);
+		unlock_kernel();
+		if (rval == -EINVAL)
+			rval = -ENOIOCTLCMD;
+	}
+
+	return rval;
+}
+
 /*
  * Initialize character device frontend.
  */
Index: linux-2.6/arch/s390/kernel/compat_ioctl.c
===================================================================
--- linux-2.6.orig/arch/s390/kernel/compat_ioctl.c	2005-11-06 20:17:52.000000000 +0100
+++ linux-2.6/arch/s390/kernel/compat_ioctl.c	2005-11-06 20:17:58.000000000 +0100
@@ -42,9 +42,6 @@
 #include <linux/compat_ioctl.h>
 #define DECLARES
 #include "../../../fs/compat_ioctl.c"
-
-/* s390 only ioctls */
-COMPATIBLE_IOCTL(TAPE390_DISPLAY)
 };
 
 int ioctl_table_size = ARRAY_SIZE(ioctl_start);

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2005-11-07  4:01 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-04 22:18 [PATCH 4/4] ->compat_ioctl for 390 tape_char Christoph Hellwig
2005-11-04 23:10 ` Arnd Bergmann
2005-11-04 23:51   ` Christoph Hellwig
2005-11-05  1:16     ` Arnd Bergmann
2005-11-07  4:01       ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).