Size of pointers in sys_call_table?

Size of pointers in sys_call_table?

[Harald Barth]

Most linux kernel ports export the sys_call_table symbol to be used in
modules. I have not succeeded how to automatially figure out the size
of a syscall pointer without inspecting the assembler for the
architecture in question. Examples are mips and sparc64. Have I
missed a syscall_t type available or shouldn't there be one?

Harald.

Re: Size of pointers in sys_call_table?

[Brian Gerst]

Harald Barth wrote:
> 
> Most linux kernel ports export the sys_call_table symbol to be used in
> modules. I have not succeeded how to automatially figure out the size
> of a syscall pointer without inspecting the assembler for the
> architecture in question. Examples are mips and sparc64. Have I
> missed a syscall_t type available or shouldn't there be one?
> 
> Harald.

The layout of the sys_call_table is totally architecture dependant.  The
question to ask here is why do you need to use it?  Modifying it to hook
into syscalls is frowned upon.

--

				Brian Gerst

Re: Size of pointers in sys_call_table?

[Harald Barth]

> The layout of the sys_call_table is totally architecture dependant.  The
> question to ask here is why do you need to use it?  Modifying it to hook
> into syscalls is frowned upon.

I want to set the "frowning upon" aside just for the moment and point
to the fact that the symbol actually is exported and in consequence
should be described by some data type. The data type may be "totally
architecture dependant".

I can join the frowning upon if we extend it to be about the export
of the sys_call_table in the first place, but there are no other means
to populate a syscall from a module, or have I missed something?

The different AFS implementations have used this for years.

Harald.

Re: Size of pointers in sys_call_table?

[Alan Cox]

> The layout of the sys_call_table is totally architecture dependant.  The
> question to ask here is why do you need to use it?  Modifying it to hook
> into syscalls is frowned upon.

And potentially unsafe (think about caching, and non atomic writes on
some platforms)

Re: Size of pointers in sys_call_table?

[Keith Owens]

On Tue, 28 Aug 2001 17:17:24 +0100 (BST), 
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> The layout of the sys_call_table is totally architecture dependant.  The
>> question to ask here is why do you need to use it?  Modifying it to hook
>> into syscalls is frowned upon.
>
>And potentially unsafe (think about caching, and non atomic writes on
>some platforms)

Not forgetting architectures like PPC64 and IA64 that require a
different function pointer format when syscall code is in a module.  A
simple replacement of a pointer in the syscall table will not work on
those architectures.

Re: Size of pointers in sys_call_table?

[Ralf Baechle]

On Tue, Aug 28, 2001 at 05:17:24PM +0100, Alan Cox wrote:

> > The layout of the sys_call_table is totally architecture dependant.  The
> > question to ask here is why do you need to use it?  Modifying it to hook
> > into syscalls is frowned upon.
> 
> And potentially unsafe (think about caching, and non atomic writes on
> some platforms)

Breakage practically guaranteed on MIPS systems where additional information
beyond the pointer is associated with a syscall entry point.  Breakage also
guaranteed on ccNUMA systems that run per-node copies of the kernel.

  Ralf

ioctl conflicts

[Manik Raina]

I was grep-ing on a 2.4 source tree when i found the
following :

./include/linux/videodev.h:#define VIDIOCGCAP          
_IOR('v',1,struct video_capability)
./include/linux/ext2_fs.h:#define  EXT2_IOC_GETVERSION  _IOR('v',1,
long)   

Aren't these supposed to be conflicts ?

-Manik

Re: ioctl conflicts

[Gerd Knorr]

Manik Raina wrote:
>  I was grep-ing on a 2.4 source tree when i found the
>  following :
>  
>  ./include/linux/videodev.h:#define VIDIOCGCAP          
>  _IOR('v',1,struct video_capability)
>  ./include/linux/ext2_fs.h:#define  EXT2_IOC_GETVERSION  _IOR('v',1,
>  long)   

The size of the argument has a different size, so they end up with
different magic numbers because of that.

  Gerd

-- 
Damn lot people confuse usability and eye-candy.

Re: ioctl conflicts

[Manik Raina]

If the parameters were the same, we would have the
same number. Even though they go different places,
we would have the same number mapping into different
ioctls. that doesn't look too good.

> The size of the argument has a different size, so they end up with
> different magic numbers because of that.
>

Re: ioctl conflicts

[Alan Cox]

> I was grep-ing on a 2.4 source tree when i found the
> following :
> 
> ./include/linux/videodev.h:#define VIDIOCGCAP          
> _IOR('v',1,struct video_capability)
> ./include/linux/ext2_fs.h:#define  EXT2_IOC_GETVERSION  _IOR('v',1,
> long)   

Thats fine. ext2 ioctls and video ioctls go to different places

Re: ioctl conflicts

[Andreas Dilger]

On Aug 30, 2001  09:20 +0100, Alan Cox wrote:
> Manik Raina wrote:
> > I was grep-ing on a 2.4 source tree when i found the
> > following :
> > 
> > ./include/linux/videodev.h:#define VIDIOCGCAP          
> > _IOR('v',1,struct video_capability)
> > ./include/linux/ext2_fs.h:#define  EXT2_IOC_GETVERSION  _IOR('v',1,
> > long)   

Note that these ioctls _should_ still have different numbers because
of the struct sizes, but it is still a small conflict.

> Thats fine. ext2 ioctls and video ioctls go to different places

I had proposed a patch to the ext2 folks to remove the use of the 'v'
space ioctls from ext2.  This would (naturally) be a slow process,
first adding new ioctl numbers in the 'f' space with equivalent function,
then when we expect a reasonable percentage of systems with the new
ioctls, change the tools to try the new ones first and fall back to the
old ones, and finally removing the old ioctls completely.

While there were no complaints, it was a rather luke-warm reception.
There is one good reason to fix the conflict - strace doesn't have
to worry about IOC number conflicts, and can print the symbolic name.

Since these particular ioctls (EXT2_IOC_{GET,SET}VERSION) are not
particularly widely used, it shouldn't be a huge effort to change.
The first part of the change is below (it is already part of ext3 for
2.4).  It should pretty much apply cleanly to 2.2 as well as I don't
think this area has changed very much at all, and it can not possibly
do any harm.

Maybe for 2.5/2.6 a warning message would be printed if the old ioctl
number is being used, and 3.x would remove the old ioctl (4+ years
from now or so).

Cheers, Andreas
=======================================================================
diff -ru linux-2.4.7.orig/fs/ext2/ioctl.c linux-2.4.7-aed/fs/ext2/ioctl.c
--- linux-2.4.7.orig/fs/ext2/ioctl.c	Wed Sep 27 14:41:33 2000
+++ linux-2.4.7-aed/fs/ext2/ioctl.c	Tue Jul 31 16:27:55 2001
@@ -73,9 +73,11 @@
 		mark_inode_dirty(inode);
 		return 0;
 	}
-	case EXT2_IOC_GETVERSION:
+	case EXT2_IOC_GETVERSION_OLD:
+	case EXT2_IOC_GETVERSION_NEW:
 		return put_user(inode->i_generation, (int *) arg);
-	case EXT2_IOC_SETVERSION:
+	case EXT2_IOC_SETVERSION_OLD:
+	case EXT2_IOC_SETVERSION_NEW:
 		if ((current->fsuid != inode->i_uid) && !capable(CAP_FOWNER))
 			return -EPERM;
 		if (IS_RDONLY(inode))
diff -ru linux-2.4.7.orig/include/linux/ext2_fs.h linux-2.4.7-aed/include/linux/ext2_fs.h
--- linux-2.4.7.orig/include/linux/ext2_fs.h	Tue Jul 31 15:00:43 2001
+++ linux-2.4.7-aed/include/linux/ext2_fs.h	Tue Jul 31 16:27:45 2001
@@ -208,8 +212,15 @@
  */
 #define	EXT2_IOC_GETFLAGS		_IOR('f', 1, long)
 #define	EXT2_IOC_SETFLAGS		_IOW('f', 2, long)
-#define	EXT2_IOC_GETVERSION		_IOR('v', 1, long)
-#define	EXT2_IOC_SETVERSION		_IOW('v', 2, long)
+#define	EXT2_IOC_GETVERSION_NEW		_IOR('f', 3, long)
+#define	EXT2_IOC_SETVERSION_NEW		_IOW('f', 4, long)
+#define	EXT2_IOC_GETVERSION_OLD		_IOR('v', 1, long)
+#define	EXT2_IOC_SETVERSION_OLD		_IOW('v', 2, long)
+/* Use the old ioctl numbers for now, until we have had the new ioctl
+ * numbers around for a good while (in case user-space includes this file).
+ */
+#define EXT2_IOC_GETVERSION EXT2_IOC_GETVERSION_OLD
+#define EXT2_IOC_SETVERSION EXT2_IOC_SETVERSION_OLD
 
 /*
  * Structure of an inode on the disk
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: ioctl conflicts

[Wichert Akkerman]

In article <E15cN49-0000fz-00@the-village.bc.nu>,
Alan Cox  <alan@lxorguk.ukuu.org.uk> wrote:
>Thats fine. ext2 ioctls and video ioctls go to different places

For some values of fine only, it sucks if you are strace.

Wichert.


-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@wiggy.net                   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: ioctl conflicts

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Thu, 30 Aug 2001 09:20:45 +0100 (BST)

   > I was grep-ing on a 2.4 source tree when i found the
   > following :
   > 
   > ./include/linux/videodev.h:#define VIDIOCGCAP          
   > _IOR('v',1,struct video_capability)
   > ./include/linux/ext2_fs.h:#define  EXT2_IOC_GETVERSION  _IOR('v',1,
   > long)   
   
   Thats fine. ext2 ioctls and video ioctls go to different places

Consider sparc64.

Later,
David S. Miller
davem@redhat.com

Re: ioctl conflicts

[Andreas Schwab]

"David S. Miller" <davem@redhat.com> writes:

|>    From: Alan Cox <alan@lxorguk.ukuu.org.uk>
|>    Date: Thu, 30 Aug 2001 09:20:45 +0100 (BST)
|> 
|>    > I was grep-ing on a 2.4 source tree when i found the
|>    > following :
|>    > 
|>    > ./include/linux/videodev.h:#define VIDIOCGCAP          
|>    > _IOR('v',1,struct video_capability)
|>    > ./include/linux/ext2_fs.h:#define  EXT2_IOC_GETVERSION  _IOR('v',1,
|>    > long)   
|>    
|>    Thats fine. ext2 ioctls and video ioctls go to different places
|> 
|> Consider sparc64.

These ioctl numbers are different due to the different argument size, so
there should be no conflict.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: ioctl conflicts

[Alan Cox]

>    Thats fine. ext2 ioctls and video ioctls go to different places
> Consider sparc64.

If the ioctl translation layer can't handle duplicates it has bigger
problems than that

Re: ioctl conflicts

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Thu, 30 Aug 2001 10:14:45 +0100 (BST)

   >    Thats fine. ext2 ioctls and video ioctls go to different places
   > Consider sparc64.
   
   If the ioctl translation layer can't handle duplicates it has bigger
   problems than that

How else can the current scheme translate arguments correctly
if the ioctl values are identical?

Let's say that the video info struct is two ints, right?
That would make the two ioctl values in question be identical.

I agree whole-heartedly that the current scheme is flawed, what
really should happen is that the translations occur in the ioctl
handlers themselves, not in some funny sparc port sources.

That is something I will be doing in 2.5.x, for sure.

Later,
David S. Miller
davem@redhat.com

Re: ioctl conflicts

[David S. Miller]

   From: Gerd Knorr <kraxel@bytesex.org>
   Date: 30 Aug 2001 08:16:22 GMT

   Manik Raina wrote:
   >  ./include/linux/videodev.h:#define VIDIOCGCAP          
   >  _IOR('v',1,struct video_capability)
   >  ./include/linux/ext2_fs.h:#define  EXT2_IOC_GETVERSION  _IOR('v',1,
   >  long)   
   
   The size of the argument has a different size, so they end up with
   different magic numbers because of that.
   
What if "struct video_capability" were "int[2]"?  Then the values
would be identical.

Later,
David S. Miller
davem@redhat.com