* Size of pointers in sys_call_table? @ 2001-08-28 12:53 Harald Barth 2001-08-28 13:26 ` Brian Gerst 2001-08-30 7:47 ` ioctl conflicts Manik Raina 0 siblings, 2 replies; 17+ messages in thread From: Harald Barth @ 2001-08-28 12:53 UTC (permalink / raw) To: linux-kernel 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Size of pointers in sys_call_table? 2001-08-28 12:53 Size of pointers in sys_call_table? Harald Barth @ 2001-08-28 13:26 ` Brian Gerst 2001-08-28 14:30 ` Harald Barth 2001-08-28 16:17 ` Alan Cox 2001-08-30 7:47 ` ioctl conflicts Manik Raina 1 sibling, 2 replies; 17+ messages in thread From: Brian Gerst @ 2001-08-28 13:26 UTC (permalink / raw) To: Harald Barth, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Size of pointers in sys_call_table? 2001-08-28 13:26 ` Brian Gerst @ 2001-08-28 14:30 ` Harald Barth 2001-08-28 16:17 ` Alan Cox 1 sibling, 0 replies; 17+ messages in thread From: Harald Barth @ 2001-08-28 14:30 UTC (permalink / raw) To: bgerst; +Cc: haba, linux-kernel > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Size of pointers in sys_call_table? 2001-08-28 13:26 ` Brian Gerst 2001-08-28 14:30 ` Harald Barth @ 2001-08-28 16:17 ` Alan Cox 2001-08-29 0:49 ` Keith Owens 2001-08-29 23:26 ` Ralf Baechle 1 sibling, 2 replies; 17+ messages in thread From: Alan Cox @ 2001-08-28 16:17 UTC (permalink / raw) To: Brian Gerst; +Cc: Harald Barth, linux-kernel > 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) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Size of pointers in sys_call_table? 2001-08-28 16:17 ` Alan Cox @ 2001-08-29 0:49 ` Keith Owens 2001-08-29 23:26 ` Ralf Baechle 1 sibling, 0 replies; 17+ messages in thread From: Keith Owens @ 2001-08-29 0:49 UTC (permalink / raw) To: Harald Barth, linux-kernel 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Size of pointers in sys_call_table? 2001-08-28 16:17 ` Alan Cox 2001-08-29 0:49 ` Keith Owens @ 2001-08-29 23:26 ` Ralf Baechle 1 sibling, 0 replies; 17+ messages in thread From: Ralf Baechle @ 2001-08-29 23:26 UTC (permalink / raw) To: Alan Cox; +Cc: Brian Gerst, Harald Barth, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* ioctl conflicts 2001-08-28 12:53 Size of pointers in sys_call_table? Harald Barth 2001-08-28 13:26 ` Brian Gerst @ 2001-08-30 7:47 ` Manik Raina 2001-08-30 8:16 ` Gerd Knorr ` (3 more replies) 1 sibling, 4 replies; 17+ messages in thread From: Manik Raina @ 2001-08-30 7:47 UTC (permalink / raw) To: linux-kernel; +Cc: manik 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ioctl conflicts 2001-08-30 7:47 ` ioctl conflicts Manik Raina @ 2001-08-30 8:16 ` Gerd Knorr 2001-08-30 9:34 ` Manik Raina 2001-08-30 8:20 ` Alan Cox ` (2 subsequent siblings) 3 siblings, 1 reply; 17+ messages in thread From: Gerd Knorr @ 2001-08-30 8:16 UTC (permalink / raw) To: linux-kernel 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ioctl conflicts 2001-08-30 8:16 ` Gerd Knorr @ 2001-08-30 9:34 ` Manik Raina 0 siblings, 0 replies; 17+ messages in thread From: Manik Raina @ 2001-08-30 9:34 UTC (permalink / raw) To: linux-kernel 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. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ioctl conflicts 2001-08-30 7:47 ` ioctl conflicts Manik Raina 2001-08-30 8:16 ` Gerd Knorr @ 2001-08-30 8:20 ` Alan Cox 2001-08-30 9:15 ` Andreas Dilger 2001-09-03 1:06 ` Wichert Akkerman 2001-08-30 8:30 ` David S. Miller 2001-08-30 9:31 ` David S. Miller 3 siblings, 2 replies; 17+ messages in thread From: Alan Cox @ 2001-08-30 8:20 UTC (permalink / raw) To: Manik Raina; +Cc: linux-kernel, manik > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ioctl conflicts 2001-08-30 8:20 ` Alan Cox @ 2001-08-30 9:15 ` Andreas Dilger 2001-09-03 1:06 ` Wichert Akkerman 1 sibling, 0 replies; 17+ messages in thread From: Andreas Dilger @ 2001-08-30 9:15 UTC (permalink / raw) To: Alan Cox; +Cc: Manik Raina, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ioctl conflicts 2001-08-30 8:20 ` Alan Cox 2001-08-30 9:15 ` Andreas Dilger @ 2001-09-03 1:06 ` Wichert Akkerman 1 sibling, 0 replies; 17+ messages in thread From: Wichert Akkerman @ 2001-09-03 1:06 UTC (permalink / raw) To: linux-kernel 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 | ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ioctl conflicts 2001-08-30 7:47 ` ioctl conflicts Manik Raina 2001-08-30 8:16 ` Gerd Knorr 2001-08-30 8:20 ` Alan Cox @ 2001-08-30 8:30 ` David S. Miller 2001-08-30 9:00 ` Andreas Schwab ` (2 more replies) 2001-08-30 9:31 ` David S. Miller 3 siblings, 3 replies; 17+ messages in thread From: David S. Miller @ 2001-08-30 8:30 UTC (permalink / raw) To: alan; +Cc: manik, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ioctl conflicts 2001-08-30 8:30 ` David S. Miller @ 2001-08-30 9:00 ` Andreas Schwab 2001-08-30 9:14 ` Alan Cox 2001-08-30 9:29 ` David S. Miller 2 siblings, 0 replies; 17+ messages in thread From: Andreas Schwab @ 2001-08-30 9:00 UTC (permalink / raw) To: David S. Miller; +Cc: alan, manik, linux-kernel "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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ioctl conflicts 2001-08-30 8:30 ` David S. Miller 2001-08-30 9:00 ` Andreas Schwab @ 2001-08-30 9:14 ` Alan Cox 2001-08-30 9:29 ` David S. Miller 2 siblings, 0 replies; 17+ messages in thread From: Alan Cox @ 2001-08-30 9:14 UTC (permalink / raw) To: David S. Miller; +Cc: alan, manik, linux-kernel > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ioctl conflicts 2001-08-30 8:30 ` David S. Miller 2001-08-30 9:00 ` Andreas Schwab 2001-08-30 9:14 ` Alan Cox @ 2001-08-30 9:29 ` David S. Miller 2 siblings, 0 replies; 17+ messages in thread From: David S. Miller @ 2001-08-30 9:29 UTC (permalink / raw) To: alan; +Cc: manik, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ioctl conflicts 2001-08-30 7:47 ` ioctl conflicts Manik Raina ` (2 preceding siblings ...) 2001-08-30 8:30 ` David S. Miller @ 2001-08-30 9:31 ` David S. Miller 3 siblings, 0 replies; 17+ messages in thread From: David S. Miller @ 2001-08-30 9:31 UTC (permalink / raw) To: kraxel; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2001-09-03 1:07 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-08-28 12:53 Size of pointers in sys_call_table? Harald Barth 2001-08-28 13:26 ` Brian Gerst 2001-08-28 14:30 ` Harald Barth 2001-08-28 16:17 ` Alan Cox 2001-08-29 0:49 ` Keith Owens 2001-08-29 23:26 ` Ralf Baechle 2001-08-30 7:47 ` ioctl conflicts Manik Raina 2001-08-30 8:16 ` Gerd Knorr 2001-08-30 9:34 ` Manik Raina 2001-08-30 8:20 ` Alan Cox 2001-08-30 9:15 ` Andreas Dilger 2001-09-03 1:06 ` Wichert Akkerman 2001-08-30 8:30 ` David S. Miller 2001-08-30 9:00 ` Andreas Schwab 2001-08-30 9:14 ` Alan Cox 2001-08-30 9:29 ` David S. Miller 2001-08-30 9:31 ` David S. Miller
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).