* Re: export of sys_call_table
[not found] ` <20021004051932.A13743@openss7.org.suse.lists.linux.kernel>
@ 2002-10-04 13:01 ` Andi Kleen
2002-10-04 13:11 ` Brian F. G. Bidulock
0 siblings, 1 reply; 70+ messages in thread
From: Andi Kleen @ 2002-10-04 13:01 UTC (permalink / raw)
To: Brian F. G. Bidulock; +Cc: linux-kernel
"Brian F. G. Bidulock" <bidulock@openss7.org> writes:
> void *dataptr, int band, int flags)
> {
> int ret =3D -ENOSYS;
> read_lock(&streams_call_lock);
I don't think you really want to use any spinlocks this way. They would
make sleeping impossible and you could never legally do a copy_from/to_user
in your system call. And how else would you access dataptr ?
More likely you want an atomic_inc(&modulecounter) or perhaps a rw
semaphore.
-Andi
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 13:01 ` export of sys_call_table Andi Kleen
@ 2002-10-04 13:11 ` Brian F. G. Bidulock
2002-10-04 13:15 ` Andi Kleen
0 siblings, 1 reply; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 13:11 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
Andi,
On Fri, 04 Oct 2002, Andi Kleen wrote:
> "Brian F. G. Bidulock" <bidulock@openss7.org> writes:
>
>
> > void *dataptr, int band, int flags)
> > {
> > int ret =3D -ENOSYS;
> > read_lock(&streams_call_lock);
>
> I don't think you really want to use any spinlocks this way. They would
> make sleeping impossible and you could never legally do a copy_from/to_user
> in your system call. And how else would you access dataptr ?
>
> More likely you want an atomic_inc(&modulecounter) or perhaps a rw
> semaphore.
read_lock and write_lock are a rw semaphores, aren't they?
--brian
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 13:11 ` Brian F. G. Bidulock
@ 2002-10-04 13:15 ` Andi Kleen
2002-10-04 13:22 ` Brian F. G. Bidulock
0 siblings, 1 reply; 70+ messages in thread
From: Andi Kleen @ 2002-10-04 13:15 UTC (permalink / raw)
To: linux-kernel; +Cc: bidulock
On Fri, Oct 04, 2002 at 07:11:06AM -0600, Brian F. G. Bidulock wrote:
> read_lock and write_lock are a rw semaphores, aren't they?
No, they are read/write spinlocks and you are not allowed to sleep
in their critical section In general you should limit them
because they can get very costly, e.g. when you're taking interrupts
with one taken or doing something else which takes a long time
and another CPU has to spin for them.
rw semaphores are down_read()/down_write() etc.
-Andi
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 13:15 ` Andi Kleen
@ 2002-10-04 13:22 ` Brian F. G. Bidulock
2002-10-04 14:11 ` Andi Kleen
0 siblings, 1 reply; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 13:22 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
Andi,
On Fri, 04 Oct 2002, Andi Kleen wrote:
> On Fri, Oct 04, 2002 at 07:11:06AM -0600, Brian F. G. Bidulock wrote:
> > read_lock and write_lock are a rw semaphores, aren't they?
>
> No, they are read/write spinlocks and you are not allowed to sleep
> in their critical section In general you should limit them
> because they can get very costly, e.g. when you're taking interrupts
> with one taken or doing something else which takes a long time
> and another CPU has to spin for them.
Well, for LiS, a process does not sleep on read_lock whenever write_lock
might be called. This is because only invalid getpmsg/putpmsg calls
(wrong file descriptor) can be made during module loading and unloading.
No valid file descriptors exist for getpmsg/putpmsg when the module is
unloading (proper use of MOD_INC/DEC_USE_COUNT). I don't see that it
matters that a process sleeps holding a read_lock() when it is a given
that the write_lock() will never be attempted while the holder of the
read_lock() is sleeping.
--brian
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 13:22 ` Brian F. G. Bidulock
@ 2002-10-04 14:11 ` Andi Kleen
2002-10-04 14:31 ` Brian F. G. Bidulock
0 siblings, 1 reply; 70+ messages in thread
From: Andi Kleen @ 2002-10-04 14:11 UTC (permalink / raw)
To: bidulock, linux-kernel
> Well, for LiS, a process does not sleep on read_lock whenever write_lock
> might be called. This is because only invalid getpmsg/putpmsg calls
See the "userptr" argument. The only way to access it is a
copy_from/to_user, and that sleeps.
> (wrong file descriptor) can be made during module loading and unloading.
> No valid file descriptors exist for getpmsg/putpmsg when the module is
> unloading (proper use of MOD_INC/DEC_USE_COUNT). I don't see that it
> matters that a process sleeps holding a read_lock() when it is a given
> that the write_lock() will never be attempted while the holder of the
> read_lock() is sleeping.
... Just you cannot guarantee that, except for never taking the write_lock,
which would make the whole exercise quite pointless.
-Andi
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 14:11 ` Andi Kleen
@ 2002-10-04 14:31 ` Brian F. G. Bidulock
0 siblings, 0 replies; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 14:31 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
Andi,
On Fri, 04 Oct 2002, Andi Kleen wrote:
> > Well, for LiS, a process does not sleep on read_lock whenever write_lock
> > might be called. This is because only invalid getpmsg/putpmsg calls
>
> See the "userptr" argument. The only way to access it is a
> copy_from/to_user, and that sleeps.
The invalid argument is the fd, so no copy_from/to_user can occur
while another processor spins on the write_lock().
>
> > (wrong file descriptor) can be made during module loading and unloading.
> > No valid file descriptors exist for getpmsg/putpmsg when the module is
> > unloading (proper use of MOD_INC/DEC_USE_COUNT). I don't see that it
> > matters that a process sleeps holding a read_lock() when it is a given
> > that the write_lock() will never be attempted while the holder of the
> > read_lock() is sleeping.
>
> ... Just you cannot guarantee that, except for never taking the write_lock,
> which would make the whole exercise quite pointless.
Yes, it is guaranteed by module use counts.
--brian
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
[not found] ` <20021004133657.B17216@devserv.devel.redhat.com.suse.lists.linux.kernel>
@ 2002-10-04 18:14 ` Andi Kleen
2002-10-04 18:46 ` Alan Cox
0 siblings, 1 reply; 70+ messages in thread
From: Andi Kleen @ 2002-10-04 18:14 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: linux-kernel
Pete Zaitcev <zaitcev@redhat.com> writes:
>
> This leaves syscalltrack, which is pretty interesting in general,
> but I think Mulix suffers from CVS mentality a little here.
> He should aim at getting the hooking mechanism into the kernel.
> I do not think his attempts to act remora and make it transparent
> are safe. Anyway, it's a code which needs to mature and sort it
> out with other hooking mechanisms, we already have dozens of them.
> Let the Darwinean process to work here a little, then we'll see.
privateice also needs it. And there is no easy way to fix it like
oprofile, unless you moved it completely into the kernel.
And AFS of course too for afssyscall.
(both are free)
-Andi
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 18:46 ` Alan Cox
@ 2002-10-04 18:45 ` Alexander Viro
2002-10-04 19:15 ` Brian F. G. Bidulock
1 sibling, 0 replies; 70+ messages in thread
From: Alexander Viro @ 2002-10-04 18:45 UTC (permalink / raw)
To: Alan Cox; +Cc: Andi Kleen, Pete Zaitcev, Linux Kernel Mailing List
On 4 Oct 2002, Alan Cox wrote:
> On Fri, 2002-10-04 at 19:14, Andi Kleen wrote:
> > privateice also needs it. And there is no easy way to fix it like
> > oprofile, unless you moved it completely into the kernel.
> >
> > And AFS of course too for afssyscall.
> >
> > (both are free)
>
> AFS patches a collection of random syscalls in pretty icky ways. Again
> afssyscall wants doing the right way - with a kernel stub like NFS has
Note that even that is not needed - nfsservctl() can be easily removed;
essentially it's a userland code. mkdir /dev/nfsctl, have nfsd mounted
on it and nfsservctl() is
open /dev/nfsctl/blah
write request
possibly read reply
close
Kernel code does exactly that, the only difference is that it creates
a temporary vfsmount not attached anywhere. End of story. Modular
case is handled automatically - if nfsd is not loaded, mounting (either
explicit or do_kern_mount() called in kernel version) will happily
load the module - as with any other filesystem type.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 18:14 ` Andi Kleen
@ 2002-10-04 18:46 ` Alan Cox
2002-10-04 18:45 ` Alexander Viro
2002-10-04 19:15 ` Brian F. G. Bidulock
0 siblings, 2 replies; 70+ messages in thread
From: Alan Cox @ 2002-10-04 18:46 UTC (permalink / raw)
To: Andi Kleen; +Cc: Pete Zaitcev, Linux Kernel Mailing List
On Fri, 2002-10-04 at 19:14, Andi Kleen wrote:
> privateice also needs it. And there is no easy way to fix it like
> oprofile, unless you moved it completely into the kernel.
>
> And AFS of course too for afssyscall.
>
> (both are free)
AFS patches a collection of random syscalls in pretty icky ways. Again
afssyscall wants doing the right way - with a kernel stub like NFS has
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 18:46 ` Alan Cox
2002-10-04 18:45 ` Alexander Viro
@ 2002-10-04 19:15 ` Brian F. G. Bidulock
2002-10-04 19:26 ` Andi Kleen
` (3 more replies)
1 sibling, 4 replies; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 19:15 UTC (permalink / raw)
To: Alan Cox; +Cc: Andi Kleen, Pete Zaitcev, Linux Kernel Mailing List
Alan,
On Fri, 04 Oct 2002, Alan Cox wrote:
>
> AFS patches a collection of random syscalls in pretty icky ways. Again
> afssyscall wants doing the right way - with a kernel stub like NFS has
>
Attached is an untested patch for LiS. AK doesn't like the read/write_lock.
AFAIK it will work for LiS but might not work for AFS. Also LiS doesn't need
module load like nfsd, perhaps afs does. If someone could add an afs patch we
could kill these two birds with one stone. Patch is against 2.4.18 but should
move up fine.
--brian
kernel/ksyms.c | 2 ++
kernel/sys.c | 39 +++++++++++++++++++++++++++++++++++++++
arch/alpha/kernel/entry.S | 2 ++
arch/arm/kernel/calls.S | 4 !!!!
arch/cris/kernel/entry.S | 4 !!!!
arch/i386/kernel/entry.S | 4 !!!!
arch/ia64/kernel/entry.S | 4 !!!!
arch/m68k/kernel/entry.S | 4 !!!!
arch/mips/kernel/syscalls.h | 4 !!!!
arch/mips64/kernel/scall_64.S | 4 !!!!
arch/parisc/kernel/syscall.S | 4 !!!!
arch/ppc/kernel/misc.S | 4 !!!!
arch/s390/kernel/entry.S | 4 !!!!
arch/s390x/kernel/entry.S | 4 !!!!
arch/sh/kernel/entry.S | 4 !!!!
arch/sparc/kernel/systbls.S | 4 !!!!
arch/sparc64/kernel/systbls.S | 6 !!!!!!
include/asm-alpha/unistd.h | 2 ++
include/asm-arm/unistd.h | 4 !!!!
include/asm-sh/unistd.h | 4 !!!!
include/asm-sparc/unistd.h | 4 !!!!
include/asm-sparc64/unistd.h | 4 !!!!
22 files changed, 45 insertions(+), 74 modifications(!)
Index: kernel/ksyms.c
===================================================================
RCS file: /home/common/cvsroot/linux/kernel/ksyms.c,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 ksyms.c
*** kernel/ksyms.c 25 Feb 2002 19:38:13 -0000 1.1.3.1
--- kernel/ksyms.c 4 Oct 2002 17:17:09 -0000
***************
*** 469,474 ****
--- 469,476 ----
#ifndef __mips__
EXPORT_SYMBOL(sys_call_table);
#endif
+ EXPORT_SYMBOL(register_streams_calls);
+ EXPORT_SYMBOL(unregister_streams_calls);
EXPORT_SYMBOL(machine_restart);
EXPORT_SYMBOL(machine_halt);
EXPORT_SYMBOL(machine_power_off);
Index: kernel/sys.c
===================================================================
RCS file: /home/common/cvsroot/linux/kernel/sys.c,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 sys.c
*** kernel/sys.c 25 Feb 2002 19:38:13 -0000 1.1.3.1
--- kernel/sys.c 4 Oct 2002 18:45:03 -0000
***************
*** 167,172 ****
--- 167,211 ----
return notifier_chain_unregister(&reboot_notifier_list, nb);
}
+ static int (*do_putpmsg) (int, void *, void *, int, int) = NULL;
+ static int (*do_getpmsg) (int, void *, void *, int, int) = NULL;
+
+ static rwlock_t streams_call_lock = RW_LOCK_UNLOCKED;
+
+ long asmlinkage sys_putpmsg(int fd, void *ctlptr, void *datptr, int band, int flags)
+ {
+ int ret = -ENOSYS;
+ read_lock(&streams_call_lock);
+ if (do_putpmsg)
+ ret = (*do_putpmsg) (fd, ctrlptr, datptr, band, flags);
+ read_unlock(&streams_call_lock);
+ return ret;
+ }
+
+ long asmlinkage sys_getpmsg(int fd, void *ctlptr, void *datptr, int band, int flags)
+ {
+ int ret = -ENOSYS;
+ read_lock(&streams_call_lock);
+ if (do_getpmsg)
+ ret = (*do_getpmsg) (fd, ctrlptr, datptr, band, flags);
+ read_unlock(&streams_call_lock);
+ return ret;
+ }
+
+ void register_streams_calls(int (*putpmsg) (int, void *, void *, int, int),
+ int (*getpmsg) (int, void *, void *, int, int))
+ {
+ write_lock(&streams_call_lock);
+ do_putpmsg = putpmsg;
+ do_getpmsg = getpmsg;
+ write_unlock(&streams_call_lock);
+ }
+
+ void unregister_streams_calls(void)
+ {
+ register_streams_calls(NULL, NULL);
+ }
+
asmlinkage long sys_ni_syscall(void)
{
return -ENOSYS;
Index: arch/alpha/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/alpha/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 entry.S
*** arch/alpha/kernel/entry.S 9 Nov 2001 21:45:35 -0000 1.1.3.1
--- arch/alpha/kernel/entry.S 4 Oct 2002 17:48:33 -0000
***************
*** 1148,1150 ****
--- 1148,1152 ----
.quad sys_gettid
.quad sys_readahead
.quad sys_ni_syscall /* 380, sys_security */
+ .quad sys_getpmsg
+ .quad sys_putpmsg
Index: arch/arm/kernel/calls.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/arm/kernel/calls.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 calls.S
*** arch/arm/kernel/calls.S 8 Oct 2001 17:39:18 -0000 1.1.3.1
--- arch/arm/kernel/calls.S 4 Oct 2002 18:24:18 -0000
***************
*** 202,209 ****
/* 185 */ .long SYMBOL_NAME(sys_capset)
.long SYMBOL_NAME(sys_sigaltstack_wrapper)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_ni_syscall)
! .long SYMBOL_NAME(sys_ni_syscall)
/* 190 */ .long SYMBOL_NAME(sys_vfork_wrapper)
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
--- 202,209 ----
/* 185 */ .long SYMBOL_NAME(sys_capset)
.long SYMBOL_NAME(sys_sigaltstack_wrapper)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_getpmsg)
! .long SYMBOL_NAME(sys_putpmsg)
/* 190 */ .long SYMBOL_NAME(sys_vfork_wrapper)
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
Index: arch/cris/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/cris/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 entry.S
*** arch/cris/kernel/entry.S 25 Feb 2002 19:37:52 -0000 1.1.3.1
--- arch/cris/kernel/entry.S 4 Oct 2002 17:24:40 -0000
***************
*** 975,982 ****
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_ni_syscall) /* streams1 */
! .long SYMBOL_NAME(sys_ni_syscall) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
--- 975,982 ----
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_getpmsg) /* streams1 */
! .long SYMBOL_NAME(sys_putpmsg) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
Index: arch/i386/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/i386/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 entry.S
*** arch/i386/kernel/entry.S 25 Feb 2002 19:37:53 -0000 1.1.3.1
--- arch/i386/kernel/entry.S 4 Oct 2002 17:24:23 -0000
***************
*** 584,591 ****
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_ni_syscall) /* streams1 */
! .long SYMBOL_NAME(sys_ni_syscall) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
--- 584,591 ----
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_getpmsg) /* streams1 */
! .long SYMBOL_NAME(sys_putpmsg) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
Index: arch/ia64/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/ia64/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 entry.S
*** arch/ia64/kernel/entry.S 9 Nov 2001 22:26:17 -0000 1.1.3.1
--- arch/ia64/kernel/entry.S 4 Oct 2002 17:23:55 -0000
***************
*** 1101,1108 ****
data8 sys_capget // 1185
data8 sys_capset
data8 sys_sendfile
! data8 sys_ni_syscall // sys_getpmsg (STREAMS)
! data8 sys_ni_syscall // sys_putpmsg (STREAMS)
data8 sys_socket // 1190
data8 sys_bind
data8 sys_connect
--- 1101,1108 ----
data8 sys_capget // 1185
data8 sys_capset
data8 sys_sendfile
! data8 sys_getpmsg // sys_getpmsg (STREAMS)
! data8 sys_putpmsg // sys_putpmsg (STREAMS)
data8 sys_socket // 1190
data8 sys_bind
data8 sys_connect
Index: arch/m68k/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/m68k/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 entry.S
*** arch/m68k/kernel/entry.S 8 Oct 2001 17:39:18 -0000 1.1.3.1
--- arch/m68k/kernel/entry.S 4 Oct 2002 17:25:17 -0000
***************
*** 613,620 ****
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_ni_syscall) /* streams1 */
! .long SYMBOL_NAME(sys_ni_syscall) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
--- 613,620 ----
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_getpmsg) /* streams1 */
! .long SYMBOL_NAME(sys_putpmsg) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
Index: arch/mips/kernel/syscalls.h
===================================================================
RCS file: /home/common/cvsroot/linux/arch/mips/kernel/syscalls.h,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 syscalls.h
*** arch/mips/kernel/syscalls.h 8 Oct 2001 17:39:18 -0000 1.1.3.1
--- arch/mips/kernel/syscalls.h 4 Oct 2002 17:31:26 -0000
***************
*** 222,229 ****
SYS(sys_capset, 2) /* 4205 */
SYS(sys_sigaltstack, 0)
SYS(sys_sendfile, 3)
! SYS(sys_ni_syscall, 0)
! SYS(sys_ni_syscall, 0)
SYS(sys_mmap2, 6) /* 4210 */
SYS(sys_truncate64, 2)
SYS(sys_ftruncate64, 2)
--- 222,229 ----
SYS(sys_capset, 2) /* 4205 */
SYS(sys_sigaltstack, 0)
SYS(sys_sendfile, 3)
! SYS(sys_getpmsg, 5)
! SYS(sys_putpmsg, 5)
SYS(sys_mmap2, 6) /* 4210 */
SYS(sys_truncate64, 2)
SYS(sys_ftruncate64, 2)
Index: arch/mips64/kernel/scall_64.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/mips64/kernel/scall_64.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 scall_64.S
*** arch/mips64/kernel/scall_64.S 8 Oct 2001 17:39:18 -0000 1.1.3.1
--- arch/mips64/kernel/scall_64.S 4 Oct 2002 18:26:01 -0000
***************
*** 341,348 ****
PTR sys_capset /* 5205 */
PTR sys_sigaltstack
PTR sys_sendfile
! PTR sys_ni_syscall
! PTR sys_ni_syscall
PTR sys_pivot_root /* 5210 */
PTR sys_mincore
PTR sys_madvise
--- 341,348 ----
PTR sys_capset /* 5205 */
PTR sys_sigaltstack
PTR sys_sendfile
! PTR sys_getpmsg
! PTR sys_putpmsg
PTR sys_pivot_root /* 5210 */
PTR sys_mincore
PTR sys_madvise
Index: arch/parisc/kernel/syscall.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/parisc/kernel/syscall.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 syscall.S
*** arch/parisc/kernel/syscall.S 8 Oct 2001 17:39:18 -0000 1.1.3.1
--- arch/parisc/kernel/syscall.S 4 Oct 2002 17:37:11 -0000
***************
*** 550,557 ****
/***************/
/* struct shmid_ds contains pointers */
ENTRY_UHOH(shmctl) /* 195 */
! ENTRY_SAME(ni_syscall) /* streams1 */
! ENTRY_SAME(ni_syscall) /* streams2 */
.end
--- 550,557 ----
/***************/
/* struct shmid_ds contains pointers */
ENTRY_UHOH(shmctl) /* 195 */
! ENTRY_SAME(getpmsg) /* streams1 */
! ENTRY_SAME(putpmsg) /* streams2 */
.end
Index: arch/ppc/kernel/misc.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/ppc/kernel/misc.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 misc.S
*** arch/ppc/kernel/misc.S 25 Feb 2002 19:37:55 -0000 1.1.3.1
--- arch/ppc/kernel/misc.S 4 Oct 2002 17:38:36 -0000
***************
*** 1101,1108 ****
.long sys_capset
.long sys_sigaltstack /* 185 */
.long sys_sendfile
! .long sys_ni_syscall /* streams1 */
! .long sys_ni_syscall /* streams2 */
.long sys_vfork
.long sys_getrlimit /* 190 */
.long sys_readahead
--- 1101,1108 ----
.long sys_capset
.long sys_sigaltstack /* 185 */
.long sys_sendfile
! .long sys_getpmsg /* streams1 */
! .long sys_putpmsg /* streams2 */
.long sys_vfork
.long sys_getrlimit /* 190 */
.long sys_readahead
Index: arch/s390/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/s390/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 entry.S
*** arch/s390/kernel/entry.S 25 Feb 2002 19:37:56 -0000 1.1.3.1
--- arch/s390/kernel/entry.S 4 Oct 2002 17:39:16 -0000
***************
*** 563,570 ****
.long sys_capset /* 185 */
.long sys_sigaltstack_glue
.long sys_sendfile
! .long sys_ni_syscall /* streams1 */
! .long sys_ni_syscall /* streams2 */
.long sys_vfork_glue /* 190 */
.long sys_getrlimit
.long sys_mmap2
--- 563,570 ----
.long sys_capset /* 185 */
.long sys_sigaltstack_glue
.long sys_sendfile
! .long sys_getpmsg /* streams1 */
! .long sys_putpmsg /* streams2 */
.long sys_vfork_glue /* 190 */
.long sys_getrlimit
.long sys_mmap2
Index: arch/s390x/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/s390x/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 entry.S
*** arch/s390x/kernel/entry.S 25 Feb 2002 19:37:56 -0000 1.1.3.1
--- arch/s390x/kernel/entry.S 4 Oct 2002 17:44:03 -0000
***************
*** 596,603 ****
.long SYSCALL(sys_capset,sys32_capset_wrapper) /* 185 */
.long SYSCALL(sys_sigaltstack_glue,sys32_sigaltstack_glue)
.long SYSCALL(sys_sendfile,sys32_sendfile_wrapper)
! .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* streams1 */
! .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* streams2 */
.long SYSCALL(sys_vfork_glue,sys_vfork_glue) /* 190 */
.long SYSCALL(sys_getrlimit,sys32_old_getrlimit_wrapper)
.long SYSCALL(sys_mmap2,sys32_mmap2_wrapper)
--- 596,603 ----
.long SYSCALL(sys_capset,sys32_capset_wrapper) /* 185 */
.long SYSCALL(sys_sigaltstack_glue,sys32_sigaltstack_glue)
.long SYSCALL(sys_sendfile,sys32_sendfile_wrapper)
! .long SYSCALL(sys_getpmsg,sys_getpmsg) /* streams1 */
! .long SYSCALL(sys_putpmsg,sys_putpmsg) /* streams2 */
.long SYSCALL(sys_vfork_glue,sys_vfork_glue) /* 190 */
.long SYSCALL(sys_getrlimit,sys32_old_getrlimit_wrapper)
.long SYSCALL(sys_mmap2,sys32_mmap2_wrapper)
Index: arch/sh/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/sh/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 entry.S
*** arch/sh/kernel/entry.S 8 Oct 2001 17:39:18 -0000 1.1.3.1
--- arch/sh/kernel/entry.S 4 Oct 2002 18:27:09 -0000
***************
*** 1264,1271 ****
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_ni_syscall) /* streams1 */
! .long SYMBOL_NAME(sys_ni_syscall) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
--- 1264,1271 ----
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_getpmsg) /* streams1 */
! .long SYMBOL_NAME(sys_putpmsg) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
Index: arch/sparc/kernel/systbls.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/sparc/kernel/systbls.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 systbls.S
*** arch/sparc/kernel/systbls.S 21 Oct 2001 17:36:54 -0000 1.1.3.1
--- arch/sparc/kernel/systbls.S 4 Oct 2002 18:37:31 -0000
***************
*** 48,54 ****
/*135*/ .long sys_nis_syscall, sys_mkdir, sys_rmdir, sys_utimes, sys_stat64
/*140*/ .long sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_gettid, sys_getrlimit
/*145*/ .long sys_setrlimit, sys_pivot_root, sys_prctl, sys_pciconfig_read, sys_pciconfig_write
! /*150*/ .long sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_poll, sys_getdents64
/*155*/ .long sys_fcntl64, sys_nis_syscall, sys_statfs, sys_fstatfs, sys_oldumount
/*160*/ .long sys_nis_syscall, sys_nis_syscall, sys_getdomainname, sys_setdomainname, sys_nis_syscall
/*165*/ .long sys_quotactl, sys_nis_syscall, sys_mount, sys_ustat, sys_nis_syscall
--- 48,54 ----
/*135*/ .long sys_nis_syscall, sys_mkdir, sys_rmdir, sys_utimes, sys_stat64
/*140*/ .long sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_gettid, sys_getrlimit
/*145*/ .long sys_setrlimit, sys_pivot_root, sys_prctl, sys_pciconfig_read, sys_pciconfig_write
! /*150*/ .long sys_nis_syscall, sys_getpmsg, sys_putpmsg, sys_poll, sys_getdents64
/*155*/ .long sys_fcntl64, sys_nis_syscall, sys_statfs, sys_fstatfs, sys_oldumount
/*160*/ .long sys_nis_syscall, sys_nis_syscall, sys_getdomainname, sys_setdomainname, sys_nis_syscall
/*165*/ .long sys_quotactl, sys_nis_syscall, sys_mount, sys_ustat, sys_nis_syscall
***************
*** 129,135 ****
.long sunos_gethostid, sunos_nosys, sys_getrlimit
.long sys_setrlimit, sunos_killpg, sunos_nosys
.long sunos_nosys, sunos_nosys
! /*150*/ .long sys_getsockname, sunos_nosys, sunos_nosys
.long sys_poll, sunos_nosys, sunos_nosys
.long sunos_getdirentries, sys_statfs, sys_fstatfs
.long sys_oldumount, sunos_nosys, sunos_nosys
--- 129,135 ----
.long sunos_gethostid, sunos_nosys, sys_getrlimit
.long sys_setrlimit, sunos_killpg, sunos_nosys
.long sunos_nosys, sunos_nosys
! /*150*/ .long sys_getsockname, sys_getpmsg, sys_putpmsg
.long sys_poll, sunos_nosys, sunos_nosys
.long sunos_getdirentries, sys_statfs, sys_fstatfs
.long sys_oldumount, sunos_nosys, sunos_nosys
Index: arch/sparc64/kernel/systbls.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/sparc64/kernel/systbls.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 systbls.S
*** arch/sparc64/kernel/systbls.S 21 Oct 2001 17:36:54 -0000 1.1.3.1
--- arch/sparc64/kernel/systbls.S 4 Oct 2002 18:34:53 -0000
***************
*** 49,55 ****
.word sys_nis_syscall, sys_mkdir, sys_rmdir, sys32_utimes, sys_stat64
/*140*/ .word sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_gettid, sys32_getrlimit
.word sys32_setrlimit, sys_pivot_root, sys32_prctl, sys32_pciconfig_read, sys32_pciconfig_write
! /*150*/ .word sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_poll, sys_getdents64
.word sys32_fcntl64, sys_nis_syscall, sys32_statfs, sys32_fstatfs, sys_oldumount
/*160*/ .word sys_nis_syscall, sys_nis_syscall, sys_getdomainname, sys_setdomainname, sys_nis_syscall
.word sys32_quotactl, sys_nis_syscall, sys32_mount, sys_ustat, sys_nis_syscall
--- 49,55 ----
.word sys_nis_syscall, sys_mkdir, sys_rmdir, sys32_utimes, sys_stat64
/*140*/ .word sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_gettid, sys32_getrlimit
.word sys32_setrlimit, sys_pivot_root, sys32_prctl, sys32_pciconfig_read, sys32_pciconfig_write
! /*150*/ .word sys_nis_syscall, sys_getpmsg, sys_putpmsg, sys_poll, sys_getdents64
.word sys32_fcntl64, sys_nis_syscall, sys32_statfs, sys32_fstatfs, sys_oldumount
/*160*/ .word sys_nis_syscall, sys_nis_syscall, sys_getdomainname, sys_setdomainname, sys_nis_syscall
.word sys32_quotactl, sys_nis_syscall, sys32_mount, sys_ustat, sys_nis_syscall
***************
*** 108,114 ****
.word sys_socketpair, sys_mkdir, sys_rmdir, sys_utimes, sys_nis_syscall
/*140*/ .word sys_nis_syscall, sys_getpeername, sys_nis_syscall, sys_gettid, sys_getrlimit
.word sys_setrlimit, sys_pivot_root, sys_prctl, sys_pciconfig_read, sys_pciconfig_write
! /*150*/ .word sys_getsockname, sys_nis_syscall, sys_nis_syscall, sys_poll, sys_getdents64
.word sys_nis_syscall, sys_nis_syscall, sys_statfs, sys_fstatfs, sys_oldumount
/*160*/ .word sys_nis_syscall, sys_nis_syscall, sys_getdomainname, sys_setdomainname, sys_utrap_install
.word sys_quotactl, sys_nis_syscall, sys_mount, sys_ustat, sys_nis_syscall
--- 108,114 ----
.word sys_socketpair, sys_mkdir, sys_rmdir, sys_utimes, sys_nis_syscall
/*140*/ .word sys_nis_syscall, sys_getpeername, sys_nis_syscall, sys_gettid, sys_getrlimit
.word sys_setrlimit, sys_pivot_root, sys_prctl, sys_pciconfig_read, sys_pciconfig_write
! /*150*/ .word sys_getsockname, sys_getpmsg, sys_putpmsg, sys_poll, sys_getdents64
.word sys_nis_syscall, sys_nis_syscall, sys_statfs, sys_fstatfs, sys_oldumount
/*160*/ .word sys_nis_syscall, sys_nis_syscall, sys_getdomainname, sys_setdomainname, sys_utrap_install
.word sys_quotactl, sys_nis_syscall, sys_mount, sys_ustat, sys_nis_syscall
***************
*** 189,195 ****
.word sunos_gethostid, sunos_nosys, sys32_getrlimit
.word sys32_setrlimit, sunos_killpg, sunos_nosys
.word sunos_nosys, sunos_nosys
! /*150*/ .word sys_getsockname, sunos_nosys, sunos_nosys
.word sys_poll, sunos_nosys, sunos_nosys
.word sunos_getdirentries, sys32_statfs, sys32_fstatfs
.word sys_oldumount, sunos_nosys, sunos_nosys
--- 189,195 ----
.word sunos_gethostid, sunos_nosys, sys32_getrlimit
.word sys32_setrlimit, sunos_killpg, sunos_nosys
.word sunos_nosys, sunos_nosys
! /*150*/ .word sys_getsockname, sys_getpmsg, sys_putpmsg
.word sys_poll, sunos_nosys, sunos_nosys
.word sunos_getdirentries, sys32_statfs, sys32_fstatfs
.word sys_oldumount, sunos_nosys, sunos_nosys
Index: include/asm-alpha/unistd.h
===================================================================
RCS file: /home/common/cvsroot/linux/include/asm-alpha/unistd.h,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 unistd.h
*** include/asm-alpha/unistd.h 9 Nov 2001 21:45:35 -0000 1.1.3.1
--- include/asm-alpha/unistd.h 4 Oct 2002 17:48:03 -0000
***************
*** 318,323 ****
--- 318,325 ----
#define __NR_gettid 378
#define __NR_readahead 379
#define __NR_security 380 /* syscall for security modules */
+ #define __NR_getpmsg 381
+ #define __NR_putpmsg 382
#if defined(__GNUC__)
Index: include/asm-arm/unistd.h
===================================================================
RCS file: /home/common/cvsroot/linux/include/asm-arm/unistd.h,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 unistd.h
*** include/asm-arm/unistd.h 12 Aug 2001 18:14:00 -0000 1.1.3.1
--- include/asm-arm/unistd.h 4 Oct 2002 18:24:15 -0000
***************
*** 206,213 ****
#define __NR_capset (__NR_SYSCALL_BASE+185)
#define __NR_sigaltstack (__NR_SYSCALL_BASE+186)
#define __NR_sendfile (__NR_SYSCALL_BASE+187)
! /* 188 reserved */
! /* 189 reserved */
#define __NR_vfork (__NR_SYSCALL_BASE+190)
#define __NR_ugetrlimit (__NR_SYSCALL_BASE+191) /* SuS compliant getrlimit */
#define __NR_mmap2 (__NR_SYSCALL_BASE+192)
--- 206,213 ----
#define __NR_capset (__NR_SYSCALL_BASE+185)
#define __NR_sigaltstack (__NR_SYSCALL_BASE+186)
#define __NR_sendfile (__NR_SYSCALL_BASE+187)
! #define __NR_getpmsg (__NR_SYSCALL_BASE+188)
! #define __NR_putpmsg (__NR_SYSCALL_BASE+189)
#define __NR_vfork (__NR_SYSCALL_BASE+190)
#define __NR_ugetrlimit (__NR_SYSCALL_BASE+191) /* SuS compliant getrlimit */
#define __NR_mmap2 (__NR_SYSCALL_BASE+192)
Index: include/asm-sh/unistd.h
===================================================================
RCS file: /home/common/cvsroot/linux/include/asm-sh/unistd.h,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 unistd.h
*** include/asm-sh/unistd.h 2 Oct 2000 18:57:34 -0000 1.1.3.1
--- include/asm-sh/unistd.h 4 Oct 2002 18:27:41 -0000
***************
*** 197,204 ****
#define __NR_capset 185
#define __NR_sigaltstack 186
#define __NR_sendfile 187
! #define __NR_streams1 188 /* some people actually want it */
! #define __NR_streams2 189 /* some people actually want it */
#define __NR_vfork 190
#define __NR_ugetrlimit 191 /* SuS compliant getrlimit */
#define __NR_mmap2 192
--- 197,204 ----
#define __NR_capset 185
#define __NR_sigaltstack 186
#define __NR_sendfile 187
! #define __NR_getpmsg 188 /* some people actually want it */
! #define __NR_putpmsg 189 /* some people actually want it */
#define __NR_vfork 190
#define __NR_ugetrlimit 191 /* SuS compliant getrlimit */
#define __NR_mmap2 192
Index: include/asm-sparc/unistd.h
===================================================================
RCS file: /home/common/cvsroot/linux/include/asm-sparc/unistd.h,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 unistd.h
*** include/asm-sparc/unistd.h 21 Oct 2001 17:36:54 -0000 1.1.3.1
--- include/asm-sparc/unistd.h 4 Oct 2002 18:32:40 -0000
***************
*** 166,173 ****
#define __NR_pciconfig_read 148 /* ENOSYS under SunOS */
#define __NR_pciconfig_write 149 /* ENOSYS under SunOS */
#define __NR_getsockname 150 /* Common */
! /* #define __NR_getmsg 151 SunOS Specific */
! /* #define __NR_putmsg 152 SunOS Specific */
#define __NR_poll 153 /* Common */
#define __NR_getdents64 154 /* Linux specific */
#define __NR_fcntl64 155 /* Linux sparc32 Specific */
--- 166,173 ----
#define __NR_pciconfig_read 148 /* ENOSYS under SunOS */
#define __NR_pciconfig_write 149 /* ENOSYS under SunOS */
#define __NR_getsockname 150 /* Common */
! #define __NR_getpmsg 151 /* Common */
! #define __NR_putpmsg 152 /* Common */
#define __NR_poll 153 /* Common */
#define __NR_getdents64 154 /* Linux specific */
#define __NR_fcntl64 155 /* Linux sparc32 Specific */
Index: include/asm-sparc64/unistd.h
===================================================================
RCS file: /home/common/cvsroot/linux/include/asm-sparc64/unistd.h,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 unistd.h
*** include/asm-sparc64/unistd.h 21 Oct 2001 17:36:54 -0000 1.1.3.1
--- include/asm-sparc64/unistd.h 4 Oct 2002 18:35:53 -0000
***************
*** 166,173 ****
#define __NR_pciconfig_read 148 /* ENOSYS under SunOS */
#define __NR_pciconfig_write 149 /* ENOSYS under SunOS */
#define __NR_getsockname 150 /* Common */
! /* #define __NR_getmsg 151 SunOS Specific */
! /* #define __NR_putmsg 152 SunOS Specific */
#define __NR_poll 153 /* Common */
#define __NR_getdents64 154 /* Linux specific */
/* #define __NR_fcntl64 155 Linux sparc32 Specific */
--- 166,173 ----
#define __NR_pciconfig_read 148 /* ENOSYS under SunOS */
#define __NR_pciconfig_write 149 /* ENOSYS under SunOS */
#define __NR_getsockname 150 /* Common */
! #define __NR_getpmsg 151 /* Common */
! #define __NR_putpmsg 152 /* Common */
#define __NR_poll 153 /* Common */
#define __NR_getdents64 154 /* Linux specific */
/* #define __NR_fcntl64 155 Linux sparc32 Specific */
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 19:15 ` Brian F. G. Bidulock
@ 2002-10-04 19:26 ` Andi Kleen
2002-10-04 19:37 ` Pete Zaitcev
` (2 subsequent siblings)
3 siblings, 0 replies; 70+ messages in thread
From: Andi Kleen @ 2002-10-04 19:26 UTC (permalink / raw)
To: Alan Cox, Andi Kleen, Pete Zaitcev, Linux Kernel Mailing List; +Cc: bidulock
On Fri, Oct 04, 2002 at 01:15:47PM -0600, Brian F. G. Bidulock wrote:
> Alan,
>
> On Fri, 04 Oct 2002, Alan Cox wrote:
> >
> > AFS patches a collection of random syscalls in pretty icky ways. Again
> > afssyscall wants doing the right way - with a kernel stub like NFS has
> >
>
> Attached is an untested patch for LiS. AK doesn't like the read/write_lock.
> AFAIK it will work for LiS but might not work for AFS. Also LiS doesn't need
> module load like nfsd, perhaps afs does. If someone could add an afs patch we
> could kill these two birds with one stone. Patch is against 2.4.18 but should
> move up fine.
>
> --brian
>
> kernel/ksyms.c | 2 ++
> kernel/sys.c | 39 +++++++++++++++++++++++++++++++++++++++
> arch/alpha/kernel/entry.S | 2 ++
> arch/arm/kernel/calls.S | 4 !!!!
> arch/cris/kernel/entry.S | 4 !!!!
> arch/i386/kernel/entry.S | 4 !!!!
> arch/ia64/kernel/entry.S | 4 !!!!
> arch/m68k/kernel/entry.S | 4 !!!!
> arch/mips/kernel/syscalls.h | 4 !!!!
> arch/mips64/kernel/scall_64.S | 4 !!!!
> arch/parisc/kernel/syscall.S | 4 !!!!
> arch/ppc/kernel/misc.S | 4 !!!!
> arch/s390/kernel/entry.S | 4 !!!!
> arch/s390x/kernel/entry.S | 4 !!!!
> arch/sh/kernel/entry.S | 4 !!!!
> arch/sparc/kernel/systbls.S | 4 !!!!
> arch/sparc64/kernel/systbls.S | 6 !!!!!!
> include/asm-alpha/unistd.h | 2 ++
> include/asm-arm/unistd.h | 4 !!!!
> include/asm-sh/unistd.h | 4 !!!!
> include/asm-sparc/unistd.h | 4 !!!!
> include/asm-sparc64/unistd.h | 4 !!!!
> 22 files changed, 45 insertions(+), 74 modifications(!)
>
>
> Index: kernel/ksyms.c
> ===================================================================
> RCS file: /home/common/cvsroot/linux/kernel/ksyms.c,v
> retrieving revision 1.1.3.1
> diff -c -r1.1.3.1 ksyms.c
> *** kernel/ksyms.c 25 Feb 2002 19:38:13 -0000 1.1.3.1
> --- kernel/ksyms.c 4 Oct 2002 17:17:09 -0000
> ***************
> *** 469,474 ****
> --- 469,476 ----
> #ifndef __mips__
> EXPORT_SYMBOL(sys_call_table);
> #endif
> + EXPORT_SYMBOL(register_streams_calls);
> + EXPORT_SYMBOL(unregister_streams_calls);
> EXPORT_SYMBOL(machine_restart);
> EXPORT_SYMBOL(machine_halt);
> EXPORT_SYMBOL(machine_power_off);
> Index: kernel/sys.c
> ===================================================================
> RCS file: /home/common/cvsroot/linux/kernel/sys.c,v
> retrieving revision 1.1.3.1
> diff -c -r1.1.3.1 sys.c
> *** kernel/sys.c 25 Feb 2002 19:38:13 -0000 1.1.3.1
> --- kernel/sys.c 4 Oct 2002 18:45:03 -0000
> ***************
> *** 167,172 ****
> --- 167,211 ----
> return notifier_chain_unregister(&reboot_notifier_list, nb);
> }
>
> + static int (*do_putpmsg) (int, void *, void *, int, int) = NULL;
> + static int (*do_getpmsg) (int, void *, void *, int, int) = NULL;
> +
> + static rwlock_t streams_call_lock = RW_LOCK_UNLOCKED;
> +
> + long asmlinkage sys_putpmsg(int fd, void *ctlptr, void *datptr, int band, int flags)
> + {
> + int ret = -ENOSYS;
> + read_lock(&streams_call_lock);
Really you cannot use a spinlock here, because that would disallow
do_putpmsg from ever sleeping. Please review the mails I wrote
earlier.
Either use atomic_inc(&some_counter) or a rw semaphore. I would likely
choose the atomic_inc. Alternatively you could use the RCU infrastructure
and stick a synchronize_kernel into module unload, then everything
would be fine too.
> + if (do_putpmsg)
> + ret = (*do_putpmsg) (fd, ctrlptr, datptr, band, flags);
> + read_unlock(&streams_call_lock);
> + return ret;
Same problem in the other stubs.
-Andi
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 19:15 ` Brian F. G. Bidulock
2002-10-04 19:26 ` Andi Kleen
@ 2002-10-04 19:37 ` Pete Zaitcev
2002-10-04 20:17 ` (off-list) Mail headers (was: Re: export of sys_call_table) Sean Neakums
2002-10-04 19:43 ` export of sys_call_table Robert Love
2002-10-04 22:21 ` David S. Miller
3 siblings, 1 reply; 70+ messages in thread
From: Pete Zaitcev @ 2002-10-04 19:37 UTC (permalink / raw)
To: bidulock; +Cc: Pete Zaitcev, Linux Kernel Mailing List
> Date: Fri, 4 Oct 2002 13:15:47 -0600
> From: "Brian F. G. Bidulock" <bidulock@openss7.org>
> Mail-Followup-To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
> Andi Kleen <ak@suse.de>, Pete Zaitcev <zaitcev@redhat.com>,
> Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
You headers are a little broken - you should include yourself.
> > AFS patches a collection of random syscalls in pretty icky ways. Again
> > afssyscall wants doing the right way - with a kernel stub like NFS has
> Attached is an untested patch for LiS.
How about attaching a tested patch? At unit testing level at least?
> + EXPORT_SYMBOL(register_streams_calls);
> + EXPORT_SYMBOL(unregister_streams_calls);
Isn't it EXPORT_SYMBOL_GPL? Otherwise you are just making general
override hooks.
> + static rwlock_t streams_call_lock = RW_LOCK_UNLOCKED;
Personally, I STONGLY disagree with people who put RW locks
everywhere by default. It's your decision though.
> + long asmlinkage sys_putpmsg(int fd, void *ctlptr, void *datptr, int band, int flags)
> + {
> + int ret = -ENOSYS;
> + read_lock(&streams_call_lock);
> + if (do_putpmsg)
> + ret = (*do_putpmsg) (fd, ctrlptr, datptr, band, flags);
> + read_unlock(&streams_call_lock);
> + return ret;
> + }
Can you sleep in putmsg? Not even for kmalloc?
Just get the pointer into a local variable.
> Index: include/asm-sparc/unistd.h
> ***************
> *** 166,173 ****
> #define __NR_pciconfig_read 148 /* ENOSYS under SunOS */
> #define __NR_pciconfig_write 149 /* ENOSYS under SunOS */
> #define __NR_getsockname 150 /* Common */
> ! /* #define __NR_getmsg 151 SunOS Specific */
> ! /* #define __NR_putmsg 152 SunOS Specific */
> #define __NR_poll 153 /* Common */
> #define __NR_getdents64 154 /* Linux specific */
> #define __NR_fcntl64 155 /* Linux sparc32 Specific */
> --- 166,173 ----
> #define __NR_pciconfig_read 148 /* ENOSYS under SunOS */
> #define __NR_pciconfig_write 149 /* ENOSYS under SunOS */
> #define __NR_getsockname 150 /* Common */
> ! #define __NR_getpmsg 151 /* Common */
> ! #define __NR_putpmsg 152 /* Common */
> #define __NR_poll 153 /* Common */
> #define __NR_getdents64 154 /* Linux specific */
> #define __NR_fcntl64 155 /* Linux sparc32 Specific */
I can take it if you make an oath that arguments are compatible
to SVR4 and SunOS.
-- Pete
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 19:15 ` Brian F. G. Bidulock
2002-10-04 19:26 ` Andi Kleen
2002-10-04 19:37 ` Pete Zaitcev
@ 2002-10-04 19:43 ` Robert Love
2002-10-04 22:21 ` David S. Miller
3 siblings, 0 replies; 70+ messages in thread
From: Robert Love @ 2002-10-04 19:43 UTC (permalink / raw)
To: bidulock; +Cc: Alan Cox, Andi Kleen, Pete Zaitcev, Linux Kernel Mailing List
On Fri, 2002-10-04 at 15:15, Brian F. G. Bidulock wrote:
> Attached is an untested patch for LiS. AK doesn't like the
> read/write_lock. AFAIK it will work for LiS but might not work
> for AFS.
It is not so much that he does not like it but you _cannot_ sleep while
holding a spinlock. It is not just his style but common sense.
grab lock -> sleep -> new task grabs same lock -> deadlock
You need to use a semaphore here or find some other way to provide
protection without becoming atomic.
Robert Love
^ permalink raw reply [flat|nested] 70+ messages in thread
* (off-list) Mail headers (was: Re: export of sys_call_table)
2002-10-04 19:37 ` Pete Zaitcev
@ 2002-10-04 20:17 ` Sean Neakums
2002-10-04 20:33 ` Sean Neakums
0 siblings, 1 reply; 70+ messages in thread
From: Sean Neakums @ 2002-10-04 20:17 UTC (permalink / raw)
To: linux-kernel
commence Pete Zaitcev quotation:
>> Date: Fri, 4 Oct 2002 13:15:47 -0600
>> From: "Brian F. G. Bidulock" <bidulock@openss7.org>
>
>> Mail-Followup-To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
>> Andi Kleen <ak@suse.de>, Pete Zaitcev <zaitcev@redhat.com>,
>> Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
>
> You headers are a little broken - you should include yourself.
Not unless he wants two copies of the followups, which may not be the
case. Getting caught up in an LKML Cc can be very hard on the inbox,
and direct Cc'ing defeats most automatic mail filing schemes, which
usually look for headers inserted by the list software.
Be seeing you,
--
/ |
[|] Sean Neakums | Questions are a burden to others;
[|] <sneakums@zork.net> | answers a prison for oneself.
\ |
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: (off-list) Mail headers (was: Re: export of sys_call_table)
2002-10-04 20:17 ` (off-list) Mail headers (was: Re: export of sys_call_table) Sean Neakums
@ 2002-10-04 20:33 ` Sean Neakums
0 siblings, 0 replies; 70+ messages in thread
From: Sean Neakums @ 2002-10-04 20:33 UTC (permalink / raw)
To: linux-kernel
Quite clearly, that went to the list. My apologies.
--
/ |
[|] Sean Neakums | Questions are a burden to others;
[|] <sneakums@zork.net> | answers a prison for oneself.
\ |
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 19:15 ` Brian F. G. Bidulock
` (2 preceding siblings ...)
2002-10-04 19:43 ` export of sys_call_table Robert Love
@ 2002-10-04 22:21 ` David S. Miller
2002-10-04 22:41 ` Brian F. G. Bidulock
3 siblings, 1 reply; 70+ messages in thread
From: David S. Miller @ 2002-10-04 22:21 UTC (permalink / raw)
To: bidulock; +Cc: alan, ak, zaitcev, linux-kernel
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
Date: Fri, 4 Oct 2002 13:15:47 -0600
Attached is an untested patch for LiS.
The sparc64 changes are absolutely wrong, the syscalls take pointers
and thus must go through a 32-bit ABI to 64-bit ABI syscall
translation routine.
This is another reason I don't want people to be able to register
system calls dynamically, it bypasses being able to verify this for
ppc64, mips64, sparc64, x86_64 x86, and ia64 x86.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 22:41 ` Brian F. G. Bidulock
@ 2002-10-04 22:38 ` David S. Miller
2002-10-08 22:20 ` [PATCH] " Brian F. G. Bidulock
[not found] ` <mailman.1034119380.19047.linux-kernel2news@redhat.com>
0 siblings, 2 replies; 70+ messages in thread
From: David S. Miller @ 2002-10-04 22:38 UTC (permalink / raw)
To: bidulock; +Cc: alan, ak, zaitcev, linux-kernel
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
Date: Fri, 4 Oct 2002 16:41:51 -0600
Do you mean a sys32_*_wrapper ? Would you please offer up those
five lines of code?
Can the person submitting these patches at least test
them before posting them?
I have no desire to see these changes in the tree, and I don't
ask other people to code up things which are my problem to code
up a proper patch I care about.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 22:21 ` David S. Miller
@ 2002-10-04 22:41 ` Brian F. G. Bidulock
2002-10-04 22:38 ` David S. Miller
0 siblings, 1 reply; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 22:41 UTC (permalink / raw)
To: David S. Miller; +Cc: alan, ak, zaitcev, linux-kernel
David,
On Fri, 04 Oct 2002, David S. Miller wrote:
>
> The sparc64 changes are absolutely wrong, the syscalls take pointers
> and thus must go through a 32-bit ABI to 64-bit ABI syscall
> translation routine.
>
Do you mean a sys32_*_wrapper ? Would you please offer up those
five lines of code?
--brian
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH] Re: export of sys_call_table
2002-10-04 22:38 ` David S. Miller
@ 2002-10-08 22:20 ` Brian F. G. Bidulock
2002-10-08 22:27 ` Brian F. G. Bidulock
` (2 more replies)
[not found] ` <mailman.1034119380.19047.linux-kernel2news@redhat.com>
1 sibling, 3 replies; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-08 22:20 UTC (permalink / raw)
To: linux-kernel
Following is a tested patch for i386 architecture for registration
of putpmsg and getpmsg system calls. This version (courtesy of
Dave Grothe at GCOM) uses up/down semaphore instead of read/write
spinlocks. The patch is against 2.4.19 but should apply up and
down a ways as well.
--brian
--- arch/i386/kernel/entry.S.orig 2002-09-04 10:54:01.000000000 -0500
+++ arch/i386/kernel/entry.S 2002-10-08 11:39:14.000000000 -0500
@@ -586,8 +586,8 @@
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
- .long SYMBOL_NAME(sys_ni_syscall) /* streams1 */
- .long SYMBOL_NAME(sys_ni_syscall) /* streams2 */
+ .long SYMBOL_NAME(sys_getpmsg) /* streams1 */
+ .long SYMBOL_NAME(sys_putpmsg) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
--- kernel/ksyms.c.orig 2002-09-04 10:54:06.000000000 -0500
+++ kernel/ksyms.c 2002-10-08 11:39:14.000000000 -0500
@@ -541,6 +541,11 @@
EXPORT_SYMBOL(seq_lseek);
extern int disable_all_usb;
EXPORT_SYMBOL(disable_all_usb);
+extern void register_streams_calls(int (*putpmsg) (int,void *,void *,int,int),
+ int (*getpmsg) (int,void *,void *,int,int));
+extern void unregister_streams_calls(void);
+EXPORT_SYMBOL(register_streams_calls);
+EXPORT_SYMBOL(unregister_streams_calls);
/* Program loader interfaces */
EXPORT_SYMBOL(setup_arg_pages);
--- kernel/sys.c.orig 2002-09-04 10:54:01.000000000 -0500
+++ kernel/sys.c 2002-10-08 11:39:14.000000000 -0500
@@ -168,6 +168,45 @@
return notifier_chain_unregister(&reboot_notifier_list, nb);
}
+static int (*do_putpmsg) (int, void *, void *, int, int) = NULL;
+static int (*do_getpmsg) (int, void *, void *, int, int) = NULL;
+
+static rwlock_t streams_call_lock = RW_LOCK_UNLOCKED;
+
+long asmlinkage sys_putpmsg(int fd, void *ctlptr, void *datptr, int band, int flags)
+{
+ int ret = -ENOSYS;
+ read_lock(&streams_call_lock);
+ if (do_putpmsg)
+ ret = (*do_putpmsg) (fd, ctlptr, datptr, band, flags);
+ read_unlock(&streams_call_lock);
+ return ret;
+}
+
+long asmlinkage sys_getpmsg(int fd, void *ctlptr, void *datptr, int band, int flags)
+{
+ int ret = -ENOSYS;
+ read_lock(&streams_call_lock);
+ if (do_getpmsg)
+ ret = (*do_getpmsg) (fd, ctlptr, datptr, band, flags);
+ read_unlock(&streams_call_lock);
+ return ret;
+}
+
+void register_streams_calls(int (*putpmsg) (int, void *, void *, int, int),
+ int (*getpmsg) (int, void *, void *, int, int))
+{
+ write_lock(&streams_call_lock);
+ do_putpmsg = putpmsg;
+ do_getpmsg = getpmsg;
+ write_unlock(&streams_call_lock);
+}
+
+void unregister_streams_calls(void)
+{
+ register_streams_calls(NULL, NULL);
+}
+
asmlinkage long sys_ni_syscall(void)
{
return -ENOSYS;
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] Re: export of sys_call_table
2002-10-08 22:20 ` [PATCH] " Brian F. G. Bidulock
@ 2002-10-08 22:27 ` Brian F. G. Bidulock
2002-10-08 23:39 ` David S. Miller
2002-10-08 23:18 ` David S. Miller
2002-10-09 0:00 ` Robert Love
2 siblings, 1 reply; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-08 22:27 UTC (permalink / raw)
To: linux-kernel; +Cc: LiS
We are looking for volunteers to test the following patch for architectures
other than i386. If you are running LiS on PPC or IA64 or any of these other
architectures, please test and sumbit the tested patch for you architecture
back. Thx.
--brian
Index: arch/alpha/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/alpha/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/alpha/kernel/entry.S
*** arch/alpha/kernel/entry.S 9 Nov 2001 21:45:35 -0000 1.1.3.1
--- arch/alpha/kernel/entry.S 4 Oct 2002 17:48:33 -0000
***************
*** 1148,1150 ****
--- 1148,1152 ----
.quad sys_gettid
.quad sys_readahead
.quad sys_ni_syscall /* 380, sys_security */
+ .quad sys_getpmsg
+ .quad sys_putpmsg
Index: arch/arm/kernel/calls.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/arm/kernel/calls.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/arm/kernel/calls.S
*** arch/arm/kernel/calls.S 8 Oct 2001 17:39:18 -0000 1.1.3.1
--- arch/arm/kernel/calls.S 4 Oct 2002 18:24:18 -0000
***************
*** 202,209 ****
/* 185 */ .long SYMBOL_NAME(sys_capset)
.long SYMBOL_NAME(sys_sigaltstack_wrapper)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_ni_syscall)
! .long SYMBOL_NAME(sys_ni_syscall)
/* 190 */ .long SYMBOL_NAME(sys_vfork_wrapper)
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
--- 202,209 ----
/* 185 */ .long SYMBOL_NAME(sys_capset)
.long SYMBOL_NAME(sys_sigaltstack_wrapper)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_getpmsg)
! .long SYMBOL_NAME(sys_putpmsg)
/* 190 */ .long SYMBOL_NAME(sys_vfork_wrapper)
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
Index: arch/cris/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/cris/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/cris/kernel/entry.S
*** arch/cris/kernel/entry.S 25 Feb 2002 19:37:52 -0000 1.1.3.1
--- arch/cris/kernel/entry.S 4 Oct 2002 17:24:40 -0000
***************
*** 975,982 ****
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_ni_syscall) /* streams1 */
! .long SYMBOL_NAME(sys_ni_syscall) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
--- 975,982 ----
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_getpmsg) /* streams1 */
! .long SYMBOL_NAME(sys_putpmsg) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
Index: arch/i386/kernel/entry.S
Index: arch/ia64/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/ia64/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/ia64/kernel/entry.S
*** arch/ia64/kernel/entry.S 9 Nov 2001 22:26:17 -0000 1.1.3.1
--- arch/ia64/kernel/entry.S 4 Oct 2002 17:23:55 -0000
***************
*** 1101,1108 ****
data8 sys_capget // 1185
data8 sys_capset
data8 sys_sendfile
! data8 sys_ni_syscall // sys_getpmsg (STREAMS)
! data8 sys_ni_syscall // sys_putpmsg (STREAMS)
data8 sys_socket // 1190
data8 sys_bind
data8 sys_connect
--- 1101,1108 ----
data8 sys_capget // 1185
data8 sys_capset
data8 sys_sendfile
! data8 sys_getpmsg // sys_getpmsg (STREAMS)
! data8 sys_putpmsg // sys_putpmsg (STREAMS)
data8 sys_socket // 1190
data8 sys_bind
data8 sys_connect
Index: arch/m68k/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/m68k/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/m68k/kernel/entry.S
*** arch/m68k/kernel/entry.S 8 Oct 2001 17:39:18 -0000 1.1.3.1
--- arch/m68k/kernel/entry.S 4 Oct 2002 17:25:17 -0000
***************
*** 613,620 ****
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_ni_syscall) /* streams1 */
! .long SYMBOL_NAME(sys_ni_syscall) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
--- 613,620 ----
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_getpmsg) /* streams1 */
! .long SYMBOL_NAME(sys_putpmsg) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
Index: arch/mips/kernel/syscalls.h
===================================================================
RCS file: /home/common/cvsroot/linux/arch/mips/kernel/syscalls.h,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/mips/kernel/syscalls.h
*** arch/mips/kernel/syscalls.h 8 Oct 2001 17:39:18 -0000 1.1.3.1
--- arch/mips/kernel/syscalls.h 4 Oct 2002 17:31:26 -0000
***************
*** 222,229 ****
SYS(sys_capset, 2) /* 4205 */
SYS(sys_sigaltstack, 0)
SYS(sys_sendfile, 3)
! SYS(sys_ni_syscall, 0)
! SYS(sys_ni_syscall, 0)
SYS(sys_mmap2, 6) /* 4210 */
SYS(sys_truncate64, 2)
SYS(sys_ftruncate64, 2)
--- 222,229 ----
SYS(sys_capset, 2) /* 4205 */
SYS(sys_sigaltstack, 0)
SYS(sys_sendfile, 3)
! SYS(sys_getpmsg, 5)
! SYS(sys_putpmsg, 5)
SYS(sys_mmap2, 6) /* 4210 */
SYS(sys_truncate64, 2)
SYS(sys_ftruncate64, 2)
Index: arch/mips64/kernel/scall_64.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/mips64/kernel/scall_64.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/mips64/kernel/scall_64.S
*** arch/mips64/kernel/scall_64.S 8 Oct 2001 17:39:18 -0000 1.1.3.1
--- arch/mips64/kernel/scall_64.S 4 Oct 2002 18:26:01 -0000
***************
*** 341,348 ****
PTR sys_capset /* 5205 */
PTR sys_sigaltstack
PTR sys_sendfile
! PTR sys_ni_syscall
! PTR sys_ni_syscall
PTR sys_pivot_root /* 5210 */
PTR sys_mincore
PTR sys_madvise
--- 341,348 ----
PTR sys_capset /* 5205 */
PTR sys_sigaltstack
PTR sys_sendfile
! PTR sys_getpmsg
! PTR sys_putpmsg
PTR sys_pivot_root /* 5210 */
PTR sys_mincore
PTR sys_madvise
Index: arch/parisc/kernel/syscall.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/parisc/kernel/syscall.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/parisc/kernel/syscall.S
*** arch/parisc/kernel/syscall.S 8 Oct 2001 17:39:18 -0000 1.1.3.1
--- arch/parisc/kernel/syscall.S 4 Oct 2002 17:37:11 -0000
***************
*** 550,557 ****
/***************/
/* struct shmid_ds contains pointers */
ENTRY_UHOH(shmctl) /* 195 */
! ENTRY_SAME(ni_syscall) /* streams1 */
! ENTRY_SAME(ni_syscall) /* streams2 */
.end
--- 550,557 ----
/***************/
/* struct shmid_ds contains pointers */
ENTRY_UHOH(shmctl) /* 195 */
! ENTRY_SAME(getpmsg) /* streams1 */
! ENTRY_SAME(putpmsg) /* streams2 */
.end
Index: arch/ppc/kernel/misc.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/ppc/kernel/misc.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/ppc/kernel/misc.S
*** arch/ppc/kernel/misc.S 25 Feb 2002 19:37:55 -0000 1.1.3.1
--- arch/ppc/kernel/misc.S 4 Oct 2002 17:38:36 -0000
***************
*** 1101,1108 ****
.long sys_capset
.long sys_sigaltstack /* 185 */
.long sys_sendfile
! .long sys_ni_syscall /* streams1 */
! .long sys_ni_syscall /* streams2 */
.long sys_vfork
.long sys_getrlimit /* 190 */
.long sys_readahead
--- 1101,1108 ----
.long sys_capset
.long sys_sigaltstack /* 185 */
.long sys_sendfile
! .long sys_getpmsg /* streams1 */
! .long sys_putpmsg /* streams2 */
.long sys_vfork
.long sys_getrlimit /* 190 */
.long sys_readahead
Index: arch/s390/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/s390/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/s390/kernel/entry.S
*** arch/s390/kernel/entry.S 25 Feb 2002 19:37:56 -0000 1.1.3.1
--- arch/s390/kernel/entry.S 4 Oct 2002 17:39:16 -0000
***************
*** 563,570 ****
.long sys_capset /* 185 */
.long sys_sigaltstack_glue
.long sys_sendfile
! .long sys_ni_syscall /* streams1 */
! .long sys_ni_syscall /* streams2 */
.long sys_vfork_glue /* 190 */
.long sys_getrlimit
.long sys_mmap2
--- 563,570 ----
.long sys_capset /* 185 */
.long sys_sigaltstack_glue
.long sys_sendfile
! .long sys_getpmsg /* streams1 */
! .long sys_putpmsg /* streams2 */
.long sys_vfork_glue /* 190 */
.long sys_getrlimit
.long sys_mmap2
Index: arch/s390x/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/s390x/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/s390x/kernel/entry.S
*** arch/s390x/kernel/entry.S 25 Feb 2002 19:37:56 -0000 1.1.3.1
--- arch/s390x/kernel/entry.S 4 Oct 2002 17:44:03 -0000
***************
*** 596,603 ****
.long SYSCALL(sys_capset,sys32_capset_wrapper) /* 185 */
.long SYSCALL(sys_sigaltstack_glue,sys32_sigaltstack_glue)
.long SYSCALL(sys_sendfile,sys32_sendfile_wrapper)
! .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* streams1 */
! .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* streams2 */
.long SYSCALL(sys_vfork_glue,sys_vfork_glue) /* 190 */
.long SYSCALL(sys_getrlimit,sys32_old_getrlimit_wrapper)
.long SYSCALL(sys_mmap2,sys32_mmap2_wrapper)
--- 596,603 ----
.long SYSCALL(sys_capset,sys32_capset_wrapper) /* 185 */
.long SYSCALL(sys_sigaltstack_glue,sys32_sigaltstack_glue)
.long SYSCALL(sys_sendfile,sys32_sendfile_wrapper)
! .long SYSCALL(sys_getpmsg,sys_getpmsg) /* streams1 */
! .long SYSCALL(sys_putpmsg,sys_putpmsg) /* streams2 */
.long SYSCALL(sys_vfork_glue,sys_vfork_glue) /* 190 */
.long SYSCALL(sys_getrlimit,sys32_old_getrlimit_wrapper)
.long SYSCALL(sys_mmap2,sys32_mmap2_wrapper)
Index: arch/sh/kernel/entry.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/sh/kernel/entry.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/sh/kernel/entry.S
*** arch/sh/kernel/entry.S 8 Oct 2001 17:39:18 -0000 1.1.3.1
--- arch/sh/kernel/entry.S 4 Oct 2002 18:27:09 -0000
***************
*** 1264,1271 ****
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_ni_syscall) /* streams1 */
! .long SYMBOL_NAME(sys_ni_syscall) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
--- 1264,1271 ----
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
! .long SYMBOL_NAME(sys_getpmsg) /* streams1 */
! .long SYMBOL_NAME(sys_putpmsg) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
Index: arch/sparc/kernel/systbls.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/sparc/kernel/systbls.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/sparc/kernel/systbls.S
*** arch/sparc/kernel/systbls.S 21 Oct 2001 17:36:54 -0000 1.1.3.1
--- arch/sparc/kernel/systbls.S 4 Oct 2002 18:37:31 -0000
***************
*** 48,54 ****
/*135*/ .long sys_nis_syscall, sys_mkdir, sys_rmdir, sys_utimes, sys_stat64
/*140*/ .long sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_gettid, sys_getrlimit
/*145*/ .long sys_setrlimit, sys_pivot_root, sys_prctl, sys_pciconfig_read, sys_pciconfig_write
! /*150*/ .long sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_poll, sys_getdents64
/*155*/ .long sys_fcntl64, sys_nis_syscall, sys_statfs, sys_fstatfs, sys_oldumount
/*160*/ .long sys_nis_syscall, sys_nis_syscall, sys_getdomainname, sys_setdomainname, sys_nis_syscall
/*165*/ .long sys_quotactl, sys_nis_syscall, sys_mount, sys_ustat, sys_nis_syscall
--- 48,54 ----
/*135*/ .long sys_nis_syscall, sys_mkdir, sys_rmdir, sys_utimes, sys_stat64
/*140*/ .long sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_gettid, sys_getrlimit
/*145*/ .long sys_setrlimit, sys_pivot_root, sys_prctl, sys_pciconfig_read, sys_pciconfig_write
! /*150*/ .long sys_nis_syscall, sys_getpmsg, sys_putpmsg, sys_poll, sys_getdents64
/*155*/ .long sys_fcntl64, sys_nis_syscall, sys_statfs, sys_fstatfs, sys_oldumount
/*160*/ .long sys_nis_syscall, sys_nis_syscall, sys_getdomainname, sys_setdomainname, sys_nis_syscall
/*165*/ .long sys_quotactl, sys_nis_syscall, sys_mount, sys_ustat, sys_nis_syscall
***************
*** 129,135 ****
.long sunos_gethostid, sunos_nosys, sys_getrlimit
.long sys_setrlimit, sunos_killpg, sunos_nosys
.long sunos_nosys, sunos_nosys
! /*150*/ .long sys_getsockname, sunos_nosys, sunos_nosys
.long sys_poll, sunos_nosys, sunos_nosys
.long sunos_getdirentries, sys_statfs, sys_fstatfs
.long sys_oldumount, sunos_nosys, sunos_nosys
--- 129,135 ----
.long sunos_gethostid, sunos_nosys, sys_getrlimit
.long sys_setrlimit, sunos_killpg, sunos_nosys
.long sunos_nosys, sunos_nosys
! /*150*/ .long sys_getsockname, sys_getpmsg, sys_putpmsg
.long sys_poll, sunos_nosys, sunos_nosys
.long sunos_getdirentries, sys_statfs, sys_fstatfs
.long sys_oldumount, sunos_nosys, sunos_nosys
Index: arch/sparc64/kernel/systbls.S
===================================================================
RCS file: /home/common/cvsroot/linux/arch/sparc64/kernel/systbls.S,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 arch/sparc64/kernel/systbls.S
*** arch/sparc64/kernel/systbls.S 21 Oct 2001 17:36:54 -0000 1.1.3.1
--- arch/sparc64/kernel/systbls.S 4 Oct 2002 18:34:53 -0000
***************
*** 49,55 ****
.word sys_nis_syscall, sys_mkdir, sys_rmdir, sys32_utimes, sys_stat64
/*140*/ .word sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_gettid, sys32_getrlimit
.word sys32_setrlimit, sys_pivot_root, sys32_prctl, sys32_pciconfig_read, sys32_pciconfig_write
! /*150*/ .word sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_poll, sys_getdents64
.word sys32_fcntl64, sys_nis_syscall, sys32_statfs, sys32_fstatfs, sys_oldumount
/*160*/ .word sys_nis_syscall, sys_nis_syscall, sys_getdomainname, sys_setdomainname, sys_nis_syscall
.word sys32_quotactl, sys_nis_syscall, sys32_mount, sys_ustat, sys_nis_syscall
--- 49,55 ----
.word sys_nis_syscall, sys_mkdir, sys_rmdir, sys32_utimes, sys_stat64
/*140*/ .word sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_gettid, sys32_getrlimit
.word sys32_setrlimit, sys_pivot_root, sys32_prctl, sys32_pciconfig_read, sys32_pciconfig_write
! /*150*/ .word sys_nis_syscall, sys_getpmsg, sys_putpmsg, sys_poll, sys_getdents64
.word sys32_fcntl64, sys_nis_syscall, sys32_statfs, sys32_fstatfs, sys_oldumount
/*160*/ .word sys_nis_syscall, sys_nis_syscall, sys_getdomainname, sys_setdomainname, sys_nis_syscall
.word sys32_quotactl, sys_nis_syscall, sys32_mount, sys_ustat, sys_nis_syscall
***************
*** 108,114 ****
.word sys_socketpair, sys_mkdir, sys_rmdir, sys_utimes, sys_nis_syscall
/*140*/ .word sys_nis_syscall, sys_getpeername, sys_nis_syscall, sys_gettid, sys_getrlimit
.word sys_setrlimit, sys_pivot_root, sys_prctl, sys_pciconfig_read, sys_pciconfig_write
! /*150*/ .word sys_getsockname, sys_nis_syscall, sys_nis_syscall, sys_poll, sys_getdents64
.word sys_nis_syscall, sys_nis_syscall, sys_statfs, sys_fstatfs, sys_oldumount
/*160*/ .word sys_nis_syscall, sys_nis_syscall, sys_getdomainname, sys_setdomainname, sys_utrap_install
.word sys_quotactl, sys_nis_syscall, sys_mount, sys_ustat, sys_nis_syscall
--- 108,114 ----
.word sys_socketpair, sys_mkdir, sys_rmdir, sys_utimes, sys_nis_syscall
/*140*/ .word sys_nis_syscall, sys_getpeername, sys_nis_syscall, sys_gettid, sys_getrlimit
.word sys_setrlimit, sys_pivot_root, sys_prctl, sys_pciconfig_read, sys_pciconfig_write
! /*150*/ .word sys_getsockname, sys_getpmsg, sys_putpmsg, sys_poll, sys_getdents64
.word sys_nis_syscall, sys_nis_syscall, sys_statfs, sys_fstatfs, sys_oldumount
/*160*/ .word sys_nis_syscall, sys_nis_syscall, sys_getdomainname, sys_setdomainname, sys_utrap_install
.word sys_quotactl, sys_nis_syscall, sys_mount, sys_ustat, sys_nis_syscall
***************
*** 189,195 ****
.word sunos_gethostid, sunos_nosys, sys32_getrlimit
.word sys32_setrlimit, sunos_killpg, sunos_nosys
.word sunos_nosys, sunos_nosys
! /*150*/ .word sys_getsockname, sunos_nosys, sunos_nosys
.word sys_poll, sunos_nosys, sunos_nosys
.word sunos_getdirentries, sys32_statfs, sys32_fstatfs
.word sys_oldumount, sunos_nosys, sunos_nosys
--- 189,195 ----
.word sunos_gethostid, sunos_nosys, sys32_getrlimit
.word sys32_setrlimit, sunos_killpg, sunos_nosys
.word sunos_nosys, sunos_nosys
! /*150*/ .word sys_getsockname, sys_getpmsg, sys_putpmsg
.word sys_poll, sunos_nosys, sunos_nosys
.word sunos_getdirentries, sys32_statfs, sys32_fstatfs
.word sys_oldumount, sunos_nosys, sunos_nosys
Index: include/asm-alpha/unistd.h
===================================================================
RCS file: /home/common/cvsroot/linux/include/asm-alpha/unistd.h,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 include/asm-alpha/unistd.h
*** include/asm-alpha/unistd.h 9 Nov 2001 21:45:35 -0000 1.1.3.1
--- include/asm-alpha/unistd.h 4 Oct 2002 17:48:03 -0000
***************
*** 318,323 ****
--- 318,325 ----
#define __NR_gettid 378
#define __NR_readahead 379
#define __NR_security 380 /* syscall for security modules */
+ #define __NR_getpmsg 381
+ #define __NR_putpmsg 382
#if defined(__GNUC__)
Index: include/asm-arm/unistd.h
===================================================================
RCS file: /home/common/cvsroot/linux/include/asm-arm/unistd.h,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 include/asm-arm/unistd.h
*** include/asm-arm/unistd.h 12 Aug 2001 18:14:00 -0000 1.1.3.1
--- include/asm-arm/unistd.h 4 Oct 2002 18:24:15 -0000
***************
*** 206,213 ****
#define __NR_capset (__NR_SYSCALL_BASE+185)
#define __NR_sigaltstack (__NR_SYSCALL_BASE+186)
#define __NR_sendfile (__NR_SYSCALL_BASE+187)
! /* 188 reserved */
! /* 189 reserved */
#define __NR_vfork (__NR_SYSCALL_BASE+190)
#define __NR_ugetrlimit (__NR_SYSCALL_BASE+191) /* SuS compliant getrlimit */
#define __NR_mmap2 (__NR_SYSCALL_BASE+192)
--- 206,213 ----
#define __NR_capset (__NR_SYSCALL_BASE+185)
#define __NR_sigaltstack (__NR_SYSCALL_BASE+186)
#define __NR_sendfile (__NR_SYSCALL_BASE+187)
! #define __NR_getpmsg (__NR_SYSCALL_BASE+188)
! #define __NR_putpmsg (__NR_SYSCALL_BASE+189)
#define __NR_vfork (__NR_SYSCALL_BASE+190)
#define __NR_ugetrlimit (__NR_SYSCALL_BASE+191) /* SuS compliant getrlimit */
#define __NR_mmap2 (__NR_SYSCALL_BASE+192)
Index: include/asm-sh/unistd.h
===================================================================
RCS file: /home/common/cvsroot/linux/include/asm-sh/unistd.h,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 include/asm-sh/unistd.h
*** include/asm-sh/unistd.h 2 Oct 2000 18:57:34 -0000 1.1.3.1
--- include/asm-sh/unistd.h 4 Oct 2002 18:27:41 -0000
***************
*** 197,204 ****
#define __NR_capset 185
#define __NR_sigaltstack 186
#define __NR_sendfile 187
! #define __NR_streams1 188 /* some people actually want it */
! #define __NR_streams2 189 /* some people actually want it */
#define __NR_vfork 190
#define __NR_ugetrlimit 191 /* SuS compliant getrlimit */
#define __NR_mmap2 192
--- 197,204 ----
#define __NR_capset 185
#define __NR_sigaltstack 186
#define __NR_sendfile 187
! #define __NR_getpmsg 188 /* some people actually want it */
! #define __NR_putpmsg 189 /* some people actually want it */
#define __NR_vfork 190
#define __NR_ugetrlimit 191 /* SuS compliant getrlimit */
#define __NR_mmap2 192
Index: include/asm-sparc/unistd.h
===================================================================
RCS file: /home/common/cvsroot/linux/include/asm-sparc/unistd.h,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 include/asm-sparc/unistd.h
*** include/asm-sparc/unistd.h 21 Oct 2001 17:36:54 -0000 1.1.3.1
--- include/asm-sparc/unistd.h 4 Oct 2002 18:32:40 -0000
***************
*** 166,173 ****
#define __NR_pciconfig_read 148 /* ENOSYS under SunOS */
#define __NR_pciconfig_write 149 /* ENOSYS under SunOS */
#define __NR_getsockname 150 /* Common */
! /* #define __NR_getmsg 151 SunOS Specific */
! /* #define __NR_putmsg 152 SunOS Specific */
#define __NR_poll 153 /* Common */
#define __NR_getdents64 154 /* Linux specific */
#define __NR_fcntl64 155 /* Linux sparc32 Specific */
--- 166,173 ----
#define __NR_pciconfig_read 148 /* ENOSYS under SunOS */
#define __NR_pciconfig_write 149 /* ENOSYS under SunOS */
#define __NR_getsockname 150 /* Common */
! #define __NR_getpmsg 151 /* Common */
! #define __NR_putpmsg 152 /* Common */
#define __NR_poll 153 /* Common */
#define __NR_getdents64 154 /* Linux specific */
#define __NR_fcntl64 155 /* Linux sparc32 Specific */
Index: include/asm-sparc64/unistd.h
===================================================================
RCS file: /home/common/cvsroot/linux/include/asm-sparc64/unistd.h,v
retrieving revision 1.1.3.1
diff -c -r1.1.3.1 include/asm-sparc64/unistd.h
*** include/asm-sparc64/unistd.h 21 Oct 2001 17:36:54 -0000 1.1.3.1
--- include/asm-sparc64/unistd.h 4 Oct 2002 18:35:53 -0000
***************
*** 166,173 ****
#define __NR_pciconfig_read 148 /* ENOSYS under SunOS */
#define __NR_pciconfig_write 149 /* ENOSYS under SunOS */
#define __NR_getsockname 150 /* Common */
! /* #define __NR_getmsg 151 SunOS Specific */
! /* #define __NR_putmsg 152 SunOS Specific */
#define __NR_poll 153 /* Common */
#define __NR_getdents64 154 /* Linux specific */
/* #define __NR_fcntl64 155 Linux sparc32 Specific */
--- 166,173 ----
#define __NR_pciconfig_read 148 /* ENOSYS under SunOS */
#define __NR_pciconfig_write 149 /* ENOSYS under SunOS */
#define __NR_getsockname 150 /* Common */
! #define __NR_getpmsg 151 /* Common */
! #define __NR_putpmsg 152 /* Common */
#define __NR_poll 153 /* Common */
#define __NR_getdents64 154 /* Linux specific */
/* #define __NR_fcntl64 155 Linux sparc32 Specific */
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] Re: export of sys_call_table
2002-10-08 22:20 ` [PATCH] " Brian F. G. Bidulock
2002-10-08 22:27 ` Brian F. G. Bidulock
@ 2002-10-08 23:18 ` David S. Miller
2002-10-09 0:21 ` Brian F. G. Bidulock
2002-10-09 0:00 ` Robert Love
2 siblings, 1 reply; 70+ messages in thread
From: David S. Miller @ 2002-10-08 23:18 UTC (permalink / raw)
To: bidulock; +Cc: linux-kernel
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
Date: Tue, 8 Oct 2002 16:20:17 -0600
This version (courtesy of Dave Grothe at GCOM) uses up/down
semaphore instead of read/write spinlocks.
Oh really?
+static int (*do_putpmsg) (int, void *, void *, int, int) = NULL;
+static int (*do_getpmsg) (int, void *, void *, int, int) = NULL;
+
+static rwlock_t streams_call_lock = RW_LOCK_UNLOCKED;
^^^^^^^^
+
+long asmlinkage sys_putpmsg(int fd, void *ctlptr, void *datptr, int band, int flags)
+{
+ int ret = -ENOSYS;
+ read_lock(&streams_call_lock);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ if (do_putpmsg)
+ ret = (*do_putpmsg) (fd, ctlptr, datptr, band, flags);
+ read_unlock(&streams_call_lock);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ return ret;
+}
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] Re: export of sys_call_table
2002-10-08 22:27 ` Brian F. G. Bidulock
@ 2002-10-08 23:39 ` David S. Miller
0 siblings, 0 replies; 70+ messages in thread
From: David S. Miller @ 2002-10-08 23:39 UTC (permalink / raw)
To: bidulock; +Cc: linux-kernel, linux-streams
1) How can anyone test this, the new syscall entries point
to nothing so the final kernel image won't even link.
2) Did you even check if the SunOS and Linux streams system
calls take the same arguments?
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] Re: export of sys_call_table
2002-10-08 22:20 ` [PATCH] " Brian F. G. Bidulock
2002-10-08 22:27 ` Brian F. G. Bidulock
2002-10-08 23:18 ` David S. Miller
@ 2002-10-09 0:00 ` Robert Love
2 siblings, 0 replies; 70+ messages in thread
From: Robert Love @ 2002-10-09 0:00 UTC (permalink / raw)
To: bidulock; +Cc: linux-kernel
On Tue, 2002-10-08 at 18:20, Brian F. G. Bidulock wrote:
> This version (courtesy of Dave Grothe at GCOM) uses up/down
> semaphore instead of read/write spinlocks.
> +static rwlock_t streams_call_lock = RW_LOCK_UNLOCKED;
> + read_lock(&streams_call_lock);
> + read_unlock(&streams_call_lock);
> + read_lock(&streams_call_lock);
> + read_unlock(&streams_call_lock);
> + write_lock(&streams_call_lock);
> + write_unlock(&streams_call_lock);
Eh? These are all read-write spinlocks, not semaphores.
Robert Love
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] Re: export of sys_call_table
2002-10-08 23:18 ` David S. Miller
@ 2002-10-09 0:21 ` Brian F. G. Bidulock
0 siblings, 0 replies; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-09 0:21 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, LiS
David,
On Tue, 08 Oct 2002, David S. Miller wrote:
> Oh really?
Many apologies. Of course it is the wrong patch...
(My excuse: Finger trouble late in the day.)
Here is the correct patch:
--- arch/i386/kernel/entry.S.orig 2002-08-02 19:39:42.000000000 -0500
+++ arch/i386/kernel/entry.S 2002-10-08 15:43:08.000000000 -0500
@@ -584,8 +584,8 @@
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
- .long SYMBOL_NAME(sys_ni_syscall) /* streams1 */
- .long SYMBOL_NAME(sys_ni_syscall) /* streams2 */
+ .long SYMBOL_NAME(sys_getpmsg) /* streams1 */
+ .long SYMBOL_NAME(sys_putpmsg) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
--- kernel/ksyms.c.orig 2002-08-02 19:39:46.000000000 -0500
+++ kernel/ksyms.c 2002-10-08 15:44:37.000000000 -0500
@@ -497,6 +497,11 @@
EXPORT_SYMBOL(seq_release);
EXPORT_SYMBOL(seq_read);
EXPORT_SYMBOL(seq_lseek);
+extern void register_streams_calls(int (*putpmsg) (int,void *,void *,int,int),
+ int (*getpmsg) (int,void *,void *,int,int));
+extern void unregister_streams_calls(void);
+EXPORT_SYMBOL(register_streams_calls);
+EXPORT_SYMBOL(unregister_streams_calls);
/* Program loader interfaces */
EXPORT_SYMBOL(setup_arg_pages);
--- kernel/sys.c.orig 2002-08-02 19:39:46.000000000 -0500
+++ kernel/sys.c 2002-10-08 16:46:55.000000000 -0500
@@ -167,6 +167,45 @@
return notifier_chain_unregister(&reboot_notifier_list, nb);
}
+static int (*do_putpmsg) (int, void *, void *, int, int) = NULL;
+static int (*do_getpmsg) (int, void *, void *, int, int) = NULL;
+
+static DECLARE_RWSEM(streams_call_sem) ;
+
+long asmlinkage sys_putpmsg(int fd, void *ctlptr, void *datptr, int band, int flags)
+{
+ int ret = -ENOSYS;
+ down_read(&streams_call_sem);
+ if (do_putpmsg)
+ ret = (*do_putpmsg) (fd, ctlptr, datptr, band, flags);
+ up_read(&streams_call_sem);
+ return ret;
+}
+
+long asmlinkage sys_getpmsg(int fd, void *ctlptr, void *datptr, int band, int flags)
+{
+ int ret = -ENOSYS;
+ down_read(&streams_call_sem);
+ if (do_getpmsg)
+ ret = (*do_getpmsg) (fd, ctlptr, datptr, band, flags);
+ up_read(&streams_call_sem);
+ return ret;
+}
+
+void register_streams_calls(int (*putpmsg) (int, void *, void *, int, int),
+ int (*getpmsg) (int, void *, void *, int, int))
+{
+ down_write(&streams_call_sem);
+ do_putpmsg = putpmsg;
+ do_getpmsg = getpmsg;
+ up_write(&streams_call_sem);
+}
+
+void unregister_streams_calls(void)
+{
+ register_streams_calls(NULL, NULL);
+}
+
asmlinkage long sys_ni_syscall(void)
{
return -ENOSYS;
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] Re: export of sys_call_table
[not found] ` <mailman.1034119380.19047.linux-kernel2news@redhat.com>
@ 2002-10-09 0:30 ` Pete Zaitcev
2002-10-09 0:40 ` Brian F. G. Bidulock
0 siblings, 1 reply; 70+ messages in thread
From: Pete Zaitcev @ 2002-10-09 0:30 UTC (permalink / raw)
To: bidulock; +Cc: linux-kernel
> Following is a tested patch for i386 architecture for registration
> of putpmsg and getpmsg system calls. This version (courtesy of
> Dave Grothe at GCOM) uses up/down semaphore instead of read/write
> spinlocks. The patch is against 2.4.19 but should apply up and
> down a ways as well.
> +EXPORT_SYMBOL(register_streams_calls);
> +EXPORT_SYMBOL(unregister_streams_calls);
EXPORT_SYMBOL_GPL perhaps? Otherwise it's just a disguised hook,
just like nVidia's shell driver.
> +static rwlock_t streams_call_lock = RW_LOCK_UNLOCKED;
Does not look like a semaphore to me...
-- Pete
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] Re: export of sys_call_table
2002-10-09 0:30 ` Pete Zaitcev
@ 2002-10-09 0:40 ` Brian F. G. Bidulock
0 siblings, 0 replies; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-09 0:40 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: linux-kernel
Pete,
Sorry, wrong patch. See correct patch re-posted on this thread.
BTW no other symbols in ksyms are exported with EXPORT_SYMBOL_GPL
in 2.4.19.
--brian
On Tue, 08 Oct 2002, Pete Zaitcev wrote:
> > Following is a tested patch for i386 architecture for registration
> > of putpmsg and getpmsg system calls. This version (courtesy of
> > Dave Grothe at GCOM) uses up/down semaphore instead of read/write
> > spinlocks. The patch is against 2.4.19 but should apply up and
> > down a ways as well.
>
> > +EXPORT_SYMBOL(register_streams_calls);
> > +EXPORT_SYMBOL(unregister_streams_calls);
>
> EXPORT_SYMBOL_GPL perhaps? Otherwise it's just a disguised hook,
> just like nVidia's shell driver.
>
> > +static rwlock_t streams_call_lock = RW_LOCK_UNLOCKED;
>
> Does not look like a semaphore to me...
>
> -- Pete
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-06 14:17 ` Kasper Dupont
@ 2003-01-03 8:28 ` Eric W. Biederman
0 siblings, 0 replies; 70+ messages in thread
From: Eric W. Biederman @ 2003-01-03 8:28 UTC (permalink / raw)
To: Kasper Dupont
Cc: Arjan van de Ven, Andy Pfiffer, Michal Jaegermann, linux-kernel
Kasper Dupont <kasperd@daimi.au.dk> writes:
> Arjan van de Ven wrote:
> >
> > I wonder why kmonte can't just use a reboot notifier.... existing
> > infrastructure already ;(
>
> Because it doesn't hook sys_reboot to get notified about reboots.
> It hooks sys_reboot to add new calls, it could have been a new
> system call, but what monte does is slightly related to a reboot.
>
> I have myself added a feature to monte where it was essential to
> hook the sys_reboot call and do something else when a reboot was
> requested. Maybe I could have used a reboot notifier.
>
> What really bothers me about monte is:
> 1) Doesn't work on SMP
> 2) Doesn't seem to be maintened (does it even work on 2.5)?
> 3) Is not completely stable
> 4) Only available as a module, cannot be compiled in kernel.
> 5) I couldn't get my additional feature working with the latest
> version of monte.
>
> Perhaps there is some better alternative which I don't know?
kexec...
It was an inch from being accepted into 2.5 last time I looked.
Eric
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 21:06 ` David S. Miller
2002-10-04 21:44 ` Brian F. G. Bidulock
@ 2002-10-12 5:43 ` Eric Blade
1 sibling, 0 replies; 70+ messages in thread
From: Eric Blade @ 2002-10-12 5:43 UTC (permalink / raw)
To: linux-kernel
> There is simply no portable way to make changes to the system call
> table, so exporting it makes zero sense.
I think, upon reading this entire conversation so far, that the
functionality is just about useless (ie, any programs that have taken
advantage of sys_call_table have been patched to not necessarily do so)
.. but if it were necessary, there could quite probably relatively
easily be a "addto_syscall_table" function or some such. hmm.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 9:20 ` Arjan van de Ven
@ 2002-10-06 14:17 ` Kasper Dupont
2003-01-03 8:28 ` Eric W. Biederman
0 siblings, 1 reply; 70+ messages in thread
From: Kasper Dupont @ 2002-10-06 14:17 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Andy Pfiffer, Michal Jaegermann, linux-kernel
Arjan van de Ven wrote:
>
> I wonder why kmonte can't just use a reboot notifier.... existing
> infrastructure already ;(
Because it doesn't hook sys_reboot to get notified about reboots.
It hooks sys_reboot to add new calls, it could have been a new
system call, but what monte does is slightly related to a reboot.
I have myself added a feature to monte where it was essential to
hook the sys_reboot call and do something else when a reboot was
requested. Maybe I could have used a reboot notifier.
What really bothers me about monte is:
1) Doesn't work on SMP
2) Doesn't seem to be maintened (does it even work on 2.5)?
3) Is not completely stable
4) Only available as a module, cannot be compiled in kernel.
5) I couldn't get my additional feature working with the latest
version of monte.
Perhaps there is some better alternative which I don't know?
--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 17:36 ` Pete Zaitcev
@ 2002-10-05 1:39 ` John Levon
0 siblings, 0 replies; 70+ messages in thread
From: John Levon @ 2002-10-05 1:39 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: linux-kernel
On Fri, Oct 04, 2002 at 01:36:57PM -0400, Pete Zaitcev wrote:
> The oprofile author seems to have things fixed already,
> though the change did not filter down yet. He's also thin
> skinned and was fuming a little
Simple I find it a little poor form to change the kernel API
significantly, without taking the courtesy to notify people. I do not
classify this as "thin-skinned".
It's no big deal and is entirely irrelevant to the technical issues
involved.
> seriously rattled by DaveM in similar circumstances, and coming
> out just fine.
I believe I shall survive ;)
regards
john
--
"Me and my friends are so smart, we invented this new kind of art:
Post-modernist throwing darts"
- the Moldy Peaches
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
@ 2002-10-04 21:54 Mark Veltzer
0 siblings, 0 replies; 70+ messages in thread
From: Mark Veltzer @ 2002-10-04 21:54 UTC (permalink / raw)
To: Linux kernel mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 05 October 2002 00:06, David S. Miller wrote:
> There is simply no portable way to make changes to the system call
> table, so exporting it makes zero sense.
> -
I don't wish to comment on the need or lack thereof of exporting the sys call
table but it sounds to me that this is an area where some work would be
beneficial.
Is it too complication to produce a portable API along the lines of:
syscall_entry_replace(int,func_t)
Which will be implemented per architecture with the appropriate locks ?
And if locking is the problem then even a trimmed version that doesn't do
locking and maybe could be used for other in kernel purposes in code where
the locking is not needed ?
Just wondering,
Mark.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9ng4yxlxDIcceXTgRApJPAKDTC5SMk5NTYtxdRyR24rjahJc6oACgwWJ6
LzVp9BpimttoWdFDyDgL5QU=
=5eOR
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 21:06 ` David S. Miller
@ 2002-10-04 21:44 ` Brian F. G. Bidulock
2002-10-12 5:43 ` Eric Blade
1 sibling, 0 replies; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 21:44 UTC (permalink / raw)
To: David S. Miller; +Cc: alan, linux-kernel
David,
How many other architecture-specific exported symbols are there?
It appears to me that many of the system calls themselves are
architecture-specific, particularly so where 64-bit machines
are involved. Is that a reason to not make them accessible?
--brian
On Fri, 04 Oct 2002, David S. Miller wrote:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Date: 03 Oct 2002 23:02:40 +0100
>
> Overwriting syscall table entries is not safe. Its not safe because
> there is no locking mechanism, and its not safe because of the pentium
> III errata.
>
> It is also non-portable, such syscall overwriting requires knowledge
> of the layout of the table on every architecture. On some platforms
> it is a list of pointers + argument count, on some 64-bit platforms
> it is a list of 32-bit truncated pointers to save space.
>
> There is simply no portable way to make changes to the system call
> table, so exporting it makes zero sense.
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 22:02 ` Alan Cox
2002-10-03 23:06 ` Brian F. G. Bidulock
2002-10-03 23:10 ` Michal Jaegermann
@ 2002-10-04 21:06 ` David S. Miller
2002-10-04 21:44 ` Brian F. G. Bidulock
2002-10-12 5:43 ` Eric Blade
2 siblings, 2 replies; 70+ messages in thread
From: David S. Miller @ 2002-10-04 21:06 UTC (permalink / raw)
To: alan; +Cc: bidulock, linux-kernel
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: 03 Oct 2002 23:02:40 +0100
Overwriting syscall table entries is not safe. Its not safe because
there is no locking mechanism, and its not safe because of the pentium
III errata.
It is also non-portable, such syscall overwriting requires knowledge
of the layout of the table on every architecture. On some platforms
it is a list of pointers + argument count, on some 64-bit platforms
it is a list of 32-bit truncated pointers to save space.
There is simply no portable way to make changes to the system call
table, so exporting it makes zero sense.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 5:32 ` Brian F. G. Bidulock
2002-10-04 11:42 ` John Levon
@ 2002-10-04 17:36 ` Pete Zaitcev
2002-10-05 1:39 ` John Levon
1 sibling, 1 reply; 70+ messages in thread
From: Pete Zaitcev @ 2002-10-04 17:36 UTC (permalink / raw)
To: Pete Zaitcev, linux-kernel
> Date: Thu, 3 Oct 2002 23:32:21 -0600
> From: "Brian F. G. Bidulock" <bidulock@openss7.org>
> > GPLed code has no problem linking with sys_call_table.
> The code in question (LiS) is LGPL and open source. The iBCS
> packge is GPL and open source.
I looked at the code scene a little here, and I do not think
there's anything that needs the syscall table.
The oprofile author seems to have things fixed already,
though the change did not filter down yet. He's also thin
skinned and was fuming a little, but I expect technical merit
to take the upper hand in his clueful head. I remember being
seriously rattled by DaveM in similar circumstances, and coming
out just fine.
LiS is crap and has to die, so it's not a problem. We actually
had a *very* big customer who used it, got a relatively decent
performance too (as much as could be expected from, ahem, the
framework :-), but it kept crashing all the time. Took a little
work to move them off LiS, but it was worth it.
iBCS is interesting for vendors, which I think, are cool with
shipping a patch. That's something SCO will happily sell to you
if you want to run old binaries casually. A standalone person who
risks running complicated UNIX binaries and debugs when they fail
can do the patch too, there's no chilling effect.
This leaves syscalltrack, which is pretty interesting in general,
but I think Mulix suffers from CVS mentality a little here.
He should aim at getting the hooking mechanism into the kernel.
I do not think his attempts to act remora and make it transparent
are safe. Anyway, it's a code which needs to mature and sort it
out with other hooking mechanisms, we already have dozens of them.
Let the Darwinean process to work here a little, then we'll see.
> And what about AFS? I see that it uses a sys_ni_syscall slot as
> well...
Dhowell's kafs will take care of it. It should not need to overwrite
syscalls anyway.
-- Pete
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 16:19 ` Brian F. G. Bidulock
@ 2002-10-04 16:25 ` Christoph Hellwig
0 siblings, 0 replies; 70+ messages in thread
From: Christoph Hellwig @ 2002-10-04 16:25 UTC (permalink / raw)
To: Christoph Hellwig, linux-kernel
On Fri, Oct 04, 2002 at 10:19:59AM -0600, Brian F. G. Bidulock wrote:
> Christoph,
>
> On Fri, 04 Oct 2002, Christoph Hellwig wrote:
> > >
> > > iBCS is right there in arch/sparc64/solaris/socksys.c, timod.c, systbl.S
> >
> > No that's not iBCS. Even if some code is derivaed it's ceratainly something
> > different.
>
> If you consider 99% some...
Please try to actually read the code instead of spreading fud.
*plonk*
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 15:28 ` Christoph Hellwig
@ 2002-10-04 16:19 ` Brian F. G. Bidulock
2002-10-04 16:25 ` Christoph Hellwig
0 siblings, 1 reply; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 16:19 UTC (permalink / raw)
To: Christoph Hellwig, linux-kernel
Christoph,
On Fri, 04 Oct 2002, Christoph Hellwig wrote:
> >
> > iBCS is right there in arch/sparc64/solaris/socksys.c, timod.c, systbl.S
>
> No that's not iBCS. Even if some code is derivaed it's ceratainly something
> different.
If you consider 99% some...
--brian
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 15:15 ` Brian F. G. Bidulock
@ 2002-10-04 15:28 ` Christoph Hellwig
2002-10-04 16:19 ` Brian F. G. Bidulock
0 siblings, 1 reply; 70+ messages in thread
From: Christoph Hellwig @ 2002-10-04 15:28 UTC (permalink / raw)
To: linux-kernel
On Fri, Oct 04, 2002 at 09:15:17AM -0600, Brian F. G. Bidulock wrote:
> Christoph,
>
> On Fri, 04 Oct 2002, Christoph Hellwig wrote:
> >
> > There is no such thing as iBCS for 2.4+. iBCS/Linux-ABI are for foreign
> > personalities only anyway and don't need to touch sys_call_table.
> >
>
> iBCS is right there in arch/sparc64/solaris/socksys.c, timod.c, systbl.S
No that's not iBCS. Even if some code is derivaed it's ceratainly something
different.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 13:58 ` Christoph Hellwig
@ 2002-10-04 15:15 ` Brian F. G. Bidulock
2002-10-04 15:28 ` Christoph Hellwig
0 siblings, 1 reply; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 15:15 UTC (permalink / raw)
To: Christoph Hellwig, kernel
Christoph,
On Fri, 04 Oct 2002, Christoph Hellwig wrote:
>
> There is no such thing as iBCS for 2.4+. iBCS/Linux-ABI are for foreign
> personalities only anyway and don't need to touch sys_call_table.
>
iBCS is right there in arch/sparc64/solaris/socksys.c, timod.c, systbl.S
--brian
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 21:39 Brian F. G. Bidulock
` (2 preceding siblings ...)
2002-10-03 22:15 ` Greg KH
@ 2002-10-04 13:58 ` Christoph Hellwig
2002-10-04 15:15 ` Brian F. G. Bidulock
3 siblings, 1 reply; 70+ messages in thread
From: Christoph Hellwig @ 2002-10-04 13:58 UTC (permalink / raw)
To: kernel
On Thu, Oct 03, 2002 at 03:39:43PM -0600, Brian F. G. Bidulock wrote:
> I see that RH, in their infinite wisdom, have seen fit to remove
> the export of sys_call_table in 8.0 kernels breaking any loadable
> modules that wish to implement non-implemented system calls such
> as LiS's or iBCS implementation of putmsg/getmsg.
There is no such thing as iBCS for 2.4+. iBCS/Linux-ABI are for foreign
personalities only anyway and don't need to touch sys_call_table.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 11:42 ` John Levon
2002-10-04 12:03 ` Brian F. G. Bidulock
@ 2002-10-04 13:02 ` Alan Cox
1 sibling, 0 replies; 70+ messages in thread
From: Alan Cox @ 2002-10-04 13:02 UTC (permalink / raw)
To: John Levon; +Cc: Pete Zaitcev, Linux Kernel Mailing List
On Fri, 2002-10-04 at 12:42, John Levon wrote:
> Btw, anybody know what the BKL is actually protecting against in
> sys_nfsservctl ?
rmmod while executing an nfs call
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 11:19 ` Brian F. G. Bidulock
2002-10-04 11:31 ` Arjan van de Ven
@ 2002-10-04 13:00 ` Alan Cox
1 sibling, 0 replies; 70+ messages in thread
From: Alan Cox @ 2002-10-04 13:00 UTC (permalink / raw)
To: bidulock; +Cc: Arjan van de Ven, Linux Kernel Mailing List
Which ends up looking suspiciously like an overcomplicated way to
implement "ioctl", and wrap the message stuff up as ioctls. Getting
getmsg/putmsg loadable interfaces right looks a good thing for 2.5
though
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 11:42 ` John Levon
@ 2002-10-04 12:03 ` Brian F. G. Bidulock
2002-10-04 13:02 ` Alan Cox
1 sibling, 0 replies; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 12:03 UTC (permalink / raw)
To: John Levon; +Cc: Pete Zaitcev, linux-kernel
John,
On Fri, 04 Oct 2002, John Levon wrote:
>
> Look, why don't you submit the module-loading patch for LiS already ?
>
> Btw, anybody know what the BKL is actually protecting against in
> sys_nfsservctl ?
Start of one earlier on thread without the BKL.
--brian
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 11:31 ` Arjan van de Ven
@ 2002-10-04 11:55 ` Brian F. G. Bidulock
0 siblings, 0 replies; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 11:55 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Alan Cox, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]
Arjan,
On Fri, 04 Oct 2002, Arjan van de Ven wrote:
> > static long asmlinkage sys_spipe(int *fd)
> > {
> > int ret = -ENOSYS;
> > read_lock(&streams_call_lock);
> > if (do_spipe)
> > ret = do_spipe(fd);
> > read_unlock(&streams_call_lock);
> > return ret;
> > }
>
> ehm sys_spipe doesn't exist, neither do all but 2 of the others you
> showed.
spipe, fattach, fdetach can sometimes be faked with ioctl().
Perhaps we can reserve these while we're at it.
>
> iBCS is dead. It's called linux-abi nowadays.....
AFAIK it lives on as socksys under sparc architecture. See
for example solaris_putmsg and solaris_getmsg in 2.4.18
arch/sparc64/solaris/systbl.S and arch/sparc64/solaris/timod.c
> > But this is repetative and doesn't solve replacement of existing
> > system calls for profilers and such.
>
> Profilers don't actually NEED this.... OProfile is fixed for this for
> example in the 2.5 branch.
Fair enough. I only really care about the STREAMS system calls...
--brian
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 5:32 ` Brian F. G. Bidulock
@ 2002-10-04 11:42 ` John Levon
2002-10-04 12:03 ` Brian F. G. Bidulock
2002-10-04 13:02 ` Alan Cox
2002-10-04 17:36 ` Pete Zaitcev
1 sibling, 2 replies; 70+ messages in thread
From: John Levon @ 2002-10-04 11:42 UTC (permalink / raw)
To: Pete Zaitcev, linux-kernel
On Thu, Oct 03, 2002 at 11:32:21PM -0600, Brian F. G. Bidulock wrote:
> You do know that there *is* open source code which is not
> contained in the Linux kernel ;)
I think the fact that downloading the kernel source, applying a patch,
fixing the conflicts, and rebooting, can be a significant PITA for
admin/developers has completely passed them by.
> development kernels only), because the symbol is no longer
> exported and no registration procedure was provided for
> registering otherwise non-implemented system calls (in
> particular the UNIX98 and iBCS/ABI standard putmsg/getmsg
> calls).
Look, why don't you submit the module-loading patch for LiS already ?
Btw, anybody know what the BKL is actually protecting against in
sys_nfsservctl ?
> And what about AFS? I see that it uses a sys_ni_syscall slot as
> well...
I thought it got fixed last time round.
regards
john
--
"Me and my friends are so smart, we invented this new kind of art:
Post-modernist throwing darts"
- the Moldy Peaches
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 11:19 ` Brian F. G. Bidulock
@ 2002-10-04 11:31 ` Arjan van de Ven
2002-10-04 11:55 ` Brian F. G. Bidulock
2002-10-04 13:00 ` Alan Cox
1 sibling, 1 reply; 70+ messages in thread
From: Arjan van de Ven @ 2002-10-04 11:31 UTC (permalink / raw)
To: bidulock; +Cc: Alan Cox, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2971 bytes --]
On Fri, 2002-10-04 at 13:19, Brian F. G. Bidulock wrote:
> > Why ?
> > Adding "unknown" syscalls is I doubt EVER a good idea.
> > LiS has *known* and *official* syscalls, they can easily live with a
> > stub like nfsd uses.... few lines of code and it's safe.
>
> Well, nfsd does something like this:
>
> struct nfsd_linkage *nfsd_linkage = NULL;
>
> long
> asmlinkage sys_nfsservctl(int cmd, void *argp, void *resp)
> {
> int ret = -ENOSYS;
>
> lock_kernel();
>
> if (nfsd_linkage ||
> (request_module ("nfsd") == 0 && nfsd_linkage))
> ret = nfsd_linkage->do_nfsservctl(cmd, argp, resp);
>
> unlock_kernel();
> return ret;
> }
> EXPORT_SYMBOL(nfsd_linkage);
>
> I take it that this system call is not in nsfd's main data flow
> (probably write() and read are()). Taking the big kernel lock is
> excessive across every putpmsg() and getpmsg() operation and would
> seriously impact LiS performance on multiple processors. In effect,
> only one processor would run for LiS. A reader/write lock would be
> better.
The kernel has such locks too, no big deal
>
> Also, LiS does not require module loading on system call, but
> (questionably) needs unloading protection -- LiS does not really
> need to unload once loaded. This turns into something more like:
>
> static int (*do_putpmsg) (int, void *, void *, int, int) = NULL;
> static int (*do_getpmsg) (int, void *, void *, int, int) = NULL;
> static int (*do_spipe) (int *) = NULL;
> static int (*do_fattach) (int, const char *) = NULL;
> static int (*do_fdetach) (const char *) = NULL;
>
> static rwlock_t streams_call_lock = RW_LOCK_UNLOCKED;
>
> static long asmlinkage sys_putpmsg(int fd, void *ctlptr,
> void *dataptr, int band, int flags)
> {
> int ret = -ENOSYS;
> read_lock(&streams_call_lock);
> if (do_putpmsg)
> ret = do_putpmsg(fd, ctrptr, dataptr, band, flags);
> read_unlock(&streams_call_lock);
> return ret;
> }
not to bad...
>
> static long asmlinkage sys_spipe(int *fd)
> {
> int ret = -ENOSYS;
> read_lock(&streams_call_lock);
> if (do_spipe)
> ret = do_spipe(fd);
> read_unlock(&streams_call_lock);
> return ret;
> }
ehm sys_spipe doesn't exist, neither do all but 2 of the others you
showed.
>
> The module (LiS or iBCS) calls register_streams_calls after it loads and calls
> unregister_streams_calls before it unloads.
iBCS is dead. It's called linux-abi nowadays.....
> But this is repetative and doesn't solve replacement of existing
> system calls for profilers and such.
Profilers don't actually NEED this.... OProfile is fixed for this for
example in the 2.5 branch.
Taking over "random" unimplemented system calls really sounds bad..... I
mean, for the next minor release of the kernel Linus can assign that
number to something official and different......
Greetings,
Arjan van de Ven
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 9:10 ` Arjan van de Ven
@ 2002-10-04 11:19 ` Brian F. G. Bidulock
2002-10-04 11:31 ` Arjan van de Ven
2002-10-04 13:00 ` Alan Cox
0 siblings, 2 replies; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 11:19 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Alan Cox, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 5566 bytes --]
Arjan,
On Fri, 04 Oct 2002, Arjan van de Ven wrote:
> On Fri, 2002-10-04 at 01:06, Brian F. G. Bidulock wrote:
> > Alan,
> >
> > Would it be possible to put a secondary call table behind
> > the call gate wrappered in sys_ni_syscall that a module
> > could register against.
> Why ?
> Adding "unknown" syscalls is I doubt EVER a good idea.
> LiS has *known* and *official* syscalls, they can easily live with a
> stub like nfsd uses.... few lines of code and it's safe.
Well, nfsd does something like this:
struct nfsd_linkage *nfsd_linkage = NULL;
long
asmlinkage sys_nfsservctl(int cmd, void *argp, void *resp)
{
int ret = -ENOSYS;
lock_kernel();
if (nfsd_linkage ||
(request_module ("nfsd") == 0 && nfsd_linkage))
ret = nfsd_linkage->do_nfsservctl(cmd, argp, resp);
unlock_kernel();
return ret;
}
EXPORT_SYMBOL(nfsd_linkage);
I take it that this system call is not in nsfd's main data flow
(probably write() and read are()). Taking the big kernel lock is
excessive across every putpmsg() and getpmsg() operation and would
seriously impact LiS performance on multiple processors. In effect,
only one processor would run for LiS. A reader/write lock would be
better.
Also, LiS does not require module loading on system call, but
(questionably) needs unloading protection -- LiS does not really
need to unload once loaded. This turns into something more like:
static int (*do_putpmsg) (int, void *, void *, int, int) = NULL;
static int (*do_getpmsg) (int, void *, void *, int, int) = NULL;
static int (*do_spipe) (int *) = NULL;
static int (*do_fattach) (int, const char *) = NULL;
static int (*do_fdetach) (const char *) = NULL;
static rwlock_t streams_call_lock = RW_LOCK_UNLOCKED;
static long asmlinkage sys_putpmsg(int fd, void *ctlptr,
void *dataptr, int band, int flags)
{
int ret = -ENOSYS;
read_lock(&streams_call_lock);
if (do_putpmsg)
ret = do_putpmsg(fd, ctrptr, dataptr, band, flags);
read_unlock(&streams_call_lock);
return ret;
}
static long asmlinkage sys_getpmsg(int fd, void *ctlptr,
void *dataptr, int band, int flags)
{
int ret = -ENOSYS;
read_lock(&streams_call_lock);
if (do_getpmsg)
ret = do_getpmsg(fd, ctrptr, dataptr, band, flags);
read_unlock(&streams_call_lock);
return ret;
}
static long asmlinkage sys_spipe(int *fd)
{
int ret = -ENOSYS;
read_lock(&streams_call_lock);
if (do_spipe)
ret = do_spipe(fd);
read_unlock(&streams_call_lock);
return ret;
}
static long asmlinkage sys_fattach(int fd, const char *path)
{
int ret = -ENOSYS;
read_lock(&streams_call_lock);
if (do_fattach)
ret = do_fattach(fd, path);
read_unlock(&streams_call_lock);
return ret;
}
static long asmlinkage sys_fdetach(const char *path)
{
int ret = -ENOSYS;
read_lock(&streams_call_lock);
if (do_fdetach)
ret = do_fdetach(path);
read_unlock(&streams_call_lock);
return ret;
}
void register_streams_calls(int (*putpmsg) (int, void *, void *, int, int),
int (*getpmsg) (int, void *, void *, int, int),
int (*spipe) (int *),
int (*fattach) (int, const char *),
int (*fdetach) (const char *))
{
write_lock(&streams_call_lock);
do_putpmsg = putpmsg;
do_getpmsg = getpmsg;
do_spipe = spipe;
do_fattach = fattach;
do_fdetach = fdetach;
write_unlock(&streams_call_lock);
}
void unregister_streams_calls(void)
{
register_streams_calls(NULL, NULL, NULL, NULL, NULL);
}
EXPORT_SYMBOL(register_streams_calls);
EXPORT_SYMBOL(unregister_streams_calls);
The module (LiS or iBCS) calls register_streams_calls after it loads and calls
unregister_streams_calls before it unloads.
But this is repetative and doesn't solve replacement of existing
system calls for profilers and such. Having a single secondary
call table approch such as:
struct sys_secondary_call {
rwlock_t lock;
long asmlinkage(*call) (void);
} sys_secondary_call_table[256];
void *replace_syscall(__u8 nr, void *newcall)
{
void *oldcall;
write_lock(&sys_secondary_call_table[nr].lock);
oldcall = xchg(&sys_secondary_call_table[nr].call, newcall);
write_unlock(&sys_secondary_call_table[nr].lock);
return (oldcall);
}
EXPORT_SYMBOL(replace_syscall);
#define SYSCALL_STUB(num) \
long asmlinkage sys_call_ # num (void) { \
int ret = -ENOSYS; \
read_lock(&sys_secondary_call_table[num].lock); \
if (sys_secondary_call_table[num].call) { \
ret = (*sys_secondary_call_table.call) (); \
read_unlock(&sys_secondary_call_table[num].lock); \
return (ret); \
}
SYSCALL_STUB(__NR_setup);
SYSCALL_STUB(__NR_exit);
SYSCALL_STUB(__NR_fork);
.
.
.
etc.
With entry.S looking like:
.data
ENTRY(sys_call_table)
.long SYMBOL_NAME(sys_call_0)
.long SYMBOL_NAME(sys_call_1)
.
.
.
.long SYMBOL_NAME(sys_call_255)
Then any module could both replace or implement otherwise non-implemented
system calls. It just seems that the general purpose approach could work
better for most things (even nfsd).
--brian
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 0:32 ` Andy Pfiffer
@ 2002-10-04 9:20 ` Arjan van de Ven
2002-10-06 14:17 ` Kasper Dupont
0 siblings, 1 reply; 70+ messages in thread
From: Arjan van de Ven @ 2002-10-04 9:20 UTC (permalink / raw)
To: Andy Pfiffer; +Cc: Michal Jaegermann, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
On Fri, 2002-10-04 at 02:32, Andy Pfiffer wrote:
(Beowulf support) also relies on this ability.
> > Or at least "kmonte" trick to load and switch to a new kernel.
>
> The last kmonte that I worked with would preserve, then overwrite,
> sys_call_table[__NT_reboot] with a pointer to it's version of reboot()
> when the kmonte module was loaded.
>
> If asked to unload, the original version of reboot() was restored prior
> to being unloaded.
this actually gets very messy if you have ANOTHER module that tries to
do the same at the same time....
I wonder why kmonte can't just use a reboot notifier.... existing
infrastructure already ;(
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 23:06 ` Brian F. G. Bidulock
@ 2002-10-04 9:10 ` Arjan van de Ven
2002-10-04 11:19 ` Brian F. G. Bidulock
0 siblings, 1 reply; 70+ messages in thread
From: Arjan van de Ven @ 2002-10-04 9:10 UTC (permalink / raw)
To: bidulock; +Cc: Alan Cox, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
On Fri, 2002-10-04 at 01:06, Brian F. G. Bidulock wrote:
> Alan,
>
> Would it be possible to put a secondary call table behind
> the call gate wrappered in sys_ni_syscall that a module
> could register against.
Why ?
Adding "unknown" syscalls is I doubt EVER a good idea.
LiS has *known* and *official* syscalls, they can easily live with a
stub like nfsd uses.... few lines of code and it's safe.
Greetings,
Arjan van de Ven
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 4:03 ` Pete Zaitcev
@ 2002-10-04 5:32 ` Brian F. G. Bidulock
2002-10-04 11:42 ` John Levon
2002-10-04 17:36 ` Pete Zaitcev
0 siblings, 2 replies; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 5:32 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: linux-kernel
Pete,
On Fri, 04 Oct 2002, Pete Zaitcev wrote:
>
> Also, if you are a provider of a binary-only crapware which wants
> to override syscalls, there's one very important document for
> you to see: it's called Fig.1.
>
> GPLed code has no problem linking with sys_call_table.
>
The code in question (LiS) is LGPL and open source. The iBCS
packge is GPL and open source.
You do know that there *is* open source code which is not
contained in the Linux kernel ;)
So, in this case, GPL and LGPL modules do have a problem linking
with the sys_call_table (on RH 8.0 and I suppose some
development kernels only), because the symbol is no longer
exported and no registration procedure was provided for
registering otherwise non-implemented system calls (in
particular the UNIX98 and iBCS/ABI standard putmsg/getmsg
calls).
And what about AFS? I see that it uses a sys_ni_syscall slot as
well...
In fact all these components are opensource.
--brian
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 4:46 ` Greg KH
@ 2002-10-04 4:53 ` Muli Ben-Yehuda
0 siblings, 0 replies; 70+ messages in thread
From: Muli Ben-Yehuda @ 2002-10-04 4:53 UTC (permalink / raw)
To: Greg KH; +Cc: Linux-Kernel
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
On Thu, Oct 03, 2002 at 09:46:53PM -0700, Greg KH wrote:
> On Fri, Oct 04, 2002 at 07:05:03AM +0300, Muli Ben-Yehuda wrote:
> >
> > http://marc.theaimsgroup.com/?l=kernelnewbies&m=102267164910800&w=2,
>
> You didn't read my post to that same thread did you:
>
> http://marc.theaimsgroup.com/?l=kernelnewbies&m=102130770415962
I did, and considered using LSM, but decided not to since, as you
mention below, it doesn't give me the capabilities I need.
> And for the most part, the people on kernelnewbies have given up on
> trying to explain to new people why this does not work. I know I sure
> have :)
As I've written, I maintain that it does work on *some* archs (atomic
pointer updates are required) and with certain precautions (no module
unload).
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=101821127019203&w=2
> >
> > [2] Can the LSM hooks be used for notification and modification on
> > every system call's entry and exit?
>
> No. See the LSM mailing list archives for why we did not decide to do
> this. (hint, you don't really achieve what you want to by doing
> this.)
Well, since I want to hook every system call, I get exactly what I
want ;-)
I'm not doing access policies or security. I'm doing "who is deleting
my file?" and "who is calling settimeoday on my router once in a blue
moon.", and even "if process foo calls getpid(), tell it's actually
process bar".
> If you _really_ want to hook things like this, look at LTT or dprobes.
> They should work just fine for you.
Neither is in the core kernel (AFAIK), and I'm not sure how useful
they are for a module only solution. I'll take a look, though.
Thanks,
Muli.
--
Muli Ben-Yehuda http://www.mulix.org/
mulix@mulix.org:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/
Quis custodes ipsos custodiet?
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-04 4:05 ` Muli Ben-Yehuda
@ 2002-10-04 4:46 ` Greg KH
2002-10-04 4:53 ` Muli Ben-Yehuda
0 siblings, 1 reply; 70+ messages in thread
From: Greg KH @ 2002-10-04 4:46 UTC (permalink / raw)
To: Muli Ben-Yehuda; +Cc: Linux-Kernel
On Fri, Oct 04, 2002 at 07:05:03AM +0300, Muli Ben-Yehuda wrote:
>
> http://marc.theaimsgroup.com/?l=kernelnewbies&m=102267164910800&w=2,
You didn't read my post to that same thread did you:
http://marc.theaimsgroup.com/?l=kernelnewbies&m=102130770415962
And for the most part, the people on kernelnewbies have given up on
trying to explain to new people why this does not work. I know I sure
have :)
> http://marc.theaimsgroup.com/?l=linux-kernel&m=101821127019203&w=2
>
> [2] Can the LSM hooks be used for notification and modification on
> every system call's entry and exit?
No. See the LSM mailing list archives for why we did not decide to do
this. (hint, you don't really achieve what you want to by doing this.)
If you _really_ want to hook things like this, look at LTT or dprobes.
They should work just fine for you.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 22:58 ` John Levon
2002-10-03 23:10 ` Alexander Viro
@ 2002-10-04 4:05 ` Muli Ben-Yehuda
2002-10-04 4:46 ` Greg KH
1 sibling, 1 reply; 70+ messages in thread
From: Muli Ben-Yehuda @ 2002-10-04 4:05 UTC (permalink / raw)
To: Linux-Kernel
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]
On Thu, Oct 03, 2002 at 11:58:42PM +0100, John Levon wrote:
> Sort of. They've broken IA64 oprofile, and they seem not to care.
They've also broken syscalltrack, and I'll be surprised if they care.
Would someone please explain to me why a mechanism which *is* safe
under certain circumstances[1] is removed *without any suitable
alternative for modules*[2], just because it's "ugly"? We've had this
discussion before, numerous times. Ref:
http://marc.theaimsgroup.com/?l=linux-kernel&m=101820103913072&w=2
I agree that it should not be done. I maintain that sometimes, if you
want to keep your code as a module only (because forcing users to
recompile their kernel is not a viable solution) it can be done safely
if you observe certain precautions and your architecture supports
it[3]. So why remove it?
[1]
http://marc.theaimsgroup.com/?l=kernelnewbies&m=102267164910800&w=2,
http://marc.theaimsgroup.com/?l=linux-kernel&m=101821127019203&w=2
[2] Can the LSM hooks be used for notification and modification on
every system call's entry and exit?
[3] I'd like to know if I'm wrong, of course.
--
Muli Ben-Yehuda http://www.mulix.org/
mulix@mulix.org:~$ sctrace strace /bin/foo http://syscalltrack.sf.net/
Quis custodes ipsos custodiet?
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
[not found] ` <mailman.1033691043.6446.linux-kernel2news@redhat.com>
@ 2002-10-04 4:03 ` Pete Zaitcev
2002-10-04 5:32 ` Brian F. G. Bidulock
0 siblings, 1 reply; 70+ messages in thread
From: Pete Zaitcev @ 2002-10-04 4:03 UTC (permalink / raw)
To: bidulock; +Cc: linux-kernel
>> Right, it's buggered on Red Hat's kernel. Not really a problem; they
>> have a bugzilla and it's not big deal to redirect users there.
>
> Been there, done that:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74902
>
> Interested parties are welcome to join the fray.
Bugzilla is not a place for "fray". If you want to get flamed,
I can oblige without screwing Bugzilla.
Also, if you are a provider of a binary-only crapware which wants
to override syscalls, there's one very important document for
you to see: it's called Fig.1.
GPLed code has no problem linking with sys_call_table.
-- Pete
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 23:10 ` Michal Jaegermann
@ 2002-10-04 0:32 ` Andy Pfiffer
2002-10-04 9:20 ` Arjan van de Ven
0 siblings, 1 reply; 70+ messages in thread
From: Andy Pfiffer @ 2002-10-04 0:32 UTC (permalink / raw)
To: Michal Jaegermann; +Cc: linux-kernel
On Thu, 2002-10-03 at 16:10, Michal Jaegermann wrote:
> On Thu, Oct 03, 2002 at 11:02:40PM +0100, Alan Cox wrote:
> > On Thu, 2002-10-03 at 22:39, Brian F. G. Bidulock wrote:
> >
> > > Until now, loadable modules have been able to just overwrite
> ...
> >
> > Not actually safely implementable. The right way to do this is a
> > relevant 2.5 question.
> Hm, IIRC bproc stuff (Beowulf support) also relies on this ability.
> Or at least "kmonte" trick to load and switch to a new kernel.
The last kmonte that I worked with would preserve, then overwrite,
sys_call_table[__NT_reboot] with a pointer to it's version of reboot()
when the kmonte module was loaded.
If asked to unload, the original version of reboot() was restored prior
to being unloaded.
Andy
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 23:50 ` John Levon
@ 2002-10-04 0:17 ` Brian F. G. Bidulock
[not found] ` <mailman.1033691043.6446.linux-kernel2news@redhat.com>
1 sibling, 0 replies; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-04 0:17 UTC (permalink / raw)
To: John Levon; +Cc: Dave Jones, Robert Love, Greg KH, kernel
John,
On Fri, 04 Oct 2002, John Levon wrote:
>
> Right, it's buggered on Red Hat's kernel. Not really a problem; they
> have a bugzilla and it's not big deal to redirect users there.
Been there, done that:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74902
Interested parties are welcome to join the fray.
--brian
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 23:35 ` Dave Jones
@ 2002-10-03 23:50 ` John Levon
2002-10-04 0:17 ` Brian F. G. Bidulock
[not found] ` <mailman.1033691043.6446.linux-kernel2news@redhat.com>
0 siblings, 2 replies; 70+ messages in thread
From: John Levon @ 2002-10-03 23:50 UTC (permalink / raw)
To: Dave Jones, Robert Love, Greg KH, kernel
On Fri, Oct 04, 2002 at 12:35:04AM +0100, Dave Jones wrote:
> Hrmmm, HEAD CVS from a few minutes ago still does.
> John's work on getting things done correctly for 2.6 doesn't
> change the fact that it's buggered on Red Hat's 2.4 kernel.
> Or does it ?
Right, it's buggered on Red Hat's kernel. Not really a problem; they
have a bugzilla and it's not big deal to redirect users there.
Actually what I'd really like is for the Red Hat people to backport the
patch. It shouldn't be too hard.
This doesn't change the situation for users on other 2.4 kernels, of
course. But sys_call_table is still there for them.
regards
john
--
"Me and my friends are so smart, we invented this new kind of art:
Post-modernist throwing darts"
- the Moldy Peaches
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 22:27 ` Robert Love
2002-10-03 22:58 ` John Levon
@ 2002-10-03 23:35 ` Dave Jones
2002-10-03 23:50 ` John Levon
1 sibling, 1 reply; 70+ messages in thread
From: Dave Jones @ 2002-10-03 23:35 UTC (permalink / raw)
To: Robert Love; +Cc: Greg KH, kernel
On Thu, Oct 03, 2002 at 06:27:06PM -0400, Robert Love wrote:
> > Hmm, I guess this means oprofile has no chance of working
> > on Red Hat's kernels ? Bummer.
> Newer oprofile does not need the exported syscall table.
Hrmmm, HEAD CVS from a few minutes ago still does.
John's work on getting things done correctly for 2.6 doesn't
change the fact that it's buggered on Red Hat's 2.4 kernel.
Or does it ?
> I believe Red Hat 8.0 even ships with oprofile :)
Interesting. Maybe I'll download a copy sometime 8)
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 23:10 ` Alexander Viro
@ 2002-10-03 23:14 ` John Levon
0 siblings, 0 replies; 70+ messages in thread
From: John Levon @ 2002-10-03 23:14 UTC (permalink / raw)
To: Alexander Viro; +Cc: kernel
On Thu, Oct 03, 2002 at 07:10:28PM -0400, Alexander Viro wrote:
> > Sort of. They've broken IA64 oprofile, and they seem not to care.
>
> More or less off-topic, but could the persons who'd invented that
> name stand up and tell what the hell were they thinking about?
Guilty. You would prefer "Turdometer" ?
> Al, who can't help misreading that name 10 times out of 10. The worst
> thing being, coprofile sounds like a very apt description of way too many
> files in drivers/*...
heh :)
It's not my fault you find yourself adding an extra 'c'
The [a-z]profile namespace is pretty crowded ... as it is, I share name
with some Windows "tool"
regards
john
--
"Me and my friends are so smart, we invented this new kind of art:
Post-modernist throwing darts"
- the Moldy Peaches
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 22:58 ` John Levon
@ 2002-10-03 23:10 ` Alexander Viro
2002-10-03 23:14 ` John Levon
2002-10-04 4:05 ` Muli Ben-Yehuda
1 sibling, 1 reply; 70+ messages in thread
From: Alexander Viro @ 2002-10-03 23:10 UTC (permalink / raw)
To: John Levon; +Cc: kernel, rml, davej, torvalds
On Thu, 3 Oct 2002, John Levon wrote:
> Sort of. They've broken IA64 oprofile, and they seem not to care.
More or less off-topic, but could the persons who'd invented that
name stand up and tell what the hell were they thinking about?
Al, who can't help misreading that name 10 times out of 10. The worst
thing being, coprofile sounds like a very apt description of way too many
files in drivers/*...
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 22:02 ` Alan Cox
2002-10-03 23:06 ` Brian F. G. Bidulock
@ 2002-10-03 23:10 ` Michal Jaegermann
2002-10-04 0:32 ` Andy Pfiffer
2002-10-04 21:06 ` David S. Miller
2 siblings, 1 reply; 70+ messages in thread
From: Michal Jaegermann @ 2002-10-03 23:10 UTC (permalink / raw)
To: linux-kernel
On Thu, Oct 03, 2002 at 11:02:40PM +0100, Alan Cox wrote:
> On Thu, 2002-10-03 at 22:39, Brian F. G. Bidulock wrote:
>
> > Until now, loadable modules have been able to just overwrite
...
>
> Not actually safely implementable. The right way to do this is a
> relevant 2.5 question. In general however you shouldnt need to register
> syscalls because the upper layer interfaces already exist (the LiS stuff
> is an example otherwise I grant).
Hm, IIRC bproc stuff (Beowulf support) also relies on this ability.
Or at least "kmonte" trick to load and switch to a new kernel.
Michal
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 22:02 ` Alan Cox
@ 2002-10-03 23:06 ` Brian F. G. Bidulock
2002-10-04 9:10 ` Arjan van de Ven
2002-10-03 23:10 ` Michal Jaegermann
2002-10-04 21:06 ` David S. Miller
2 siblings, 1 reply; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-03 23:06 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
Alan,
Would it be possible to put a secondary call table behind
the call gate wrappered in sys_ni_syscall that a module
could register against. Is it merely the fact that the
call gate table itself must be static? A secondary table
and a mechanism to register against the secondary table with
kernel locks taken behind the call gate would be trivial,
I think.
Does that sound like the best way to go about it?
--brian
On Thu, 03 Oct 2002, Alan Cox wrote:
> On Thu, 2002-10-03 at 22:39, Brian F. G. Bidulock wrote:
> > I see that RH, in their infinite wisdom, have seen fit to remove
> > the export of sys_call_table in 8.0 kernels breaking any loadable
> > modules that wish to implement non-implemented system calls such
> > as LiS's or iBCS implementation of putmsg/getmsg.
>
> Overwriting syscall table entries is not safe. Its not safe because
> there is no locking mechanism, and its not safe because of the pentium
> III errata.
>
> > Until now, loadable modules have been able to just overwrite
> > the non implemented point in the sys_call_table when they load
> > and putting it back when they unload. There is no mechanism
> > for registering system calls.
>
> Not actually safely implementable. The right way to do this is a
> relevant 2.5 question. In general however you shouldnt need to register
> syscalls because the upper layer interfaces already exist (the LiS stuff
> is an example otherwise I grant).
>
> Alan
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 22:27 ` Robert Love
@ 2002-10-03 22:58 ` John Levon
2002-10-03 23:10 ` Alexander Viro
2002-10-04 4:05 ` Muli Ben-Yehuda
2002-10-03 23:35 ` Dave Jones
1 sibling, 2 replies; 70+ messages in thread
From: John Levon @ 2002-10-03 22:58 UTC (permalink / raw)
To: kernel; +Cc: rml, davej, torvalds
On Thu, Oct 03, 2002 at 06:27:06PM -0400, Robert Love wrote:
> > Hmm, I guess this means oprofile has no chance of working
> > on Red Hat's kernels ? Bummer.
>
> Newer oprofile does not need the exported syscall table.
Right. Assuming Linus is interested in merging the patch.
I've yet to see any kind of comment from him.
> I believe Red Hat 8.0 even ships with oprofile :)
Sort of. They've broken IA64 oprofile, and they seem not to care.
I'm pretty disgusted Arjan sent this patch without even the courtesy of
a Cc: to lkml (apologies if I just missed it).
regards
john
--
"Me and my friends are so smart, we invented this new kind of art:
Post-modernist throwing darts"
- the Moldy Peaches
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 22:15 ` Greg KH
@ 2002-10-03 22:27 ` Dave Jones
2002-10-03 22:27 ` Robert Love
0 siblings, 1 reply; 70+ messages in thread
From: Dave Jones @ 2002-10-03 22:27 UTC (permalink / raw)
To: Greg KH; +Cc: kernel
On Thu, Oct 03, 2002 at 03:15:25PM -0700, Greg KH wrote:
> > What is the kernel.org take on this?
> It is a good thing that the sys_call_table is now not exported.
Hmm, I guess this means oprofile has no chance of working
on Red Hat's kernels ? Bummer.
--
| Dave Jones. http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 22:27 ` Dave Jones
@ 2002-10-03 22:27 ` Robert Love
2002-10-03 22:58 ` John Levon
2002-10-03 23:35 ` Dave Jones
0 siblings, 2 replies; 70+ messages in thread
From: Robert Love @ 2002-10-03 22:27 UTC (permalink / raw)
To: Dave Jones; +Cc: Greg KH, kernel
On Thu, 2002-10-03 at 18:27, Dave Jones wrote:
> Hmm, I guess this means oprofile has no chance of working
> on Red Hat's kernels ? Bummer.
Newer oprofile does not need the exported syscall table.
I believe Red Hat 8.0 even ships with oprofile :)
Robert Love
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 22:14 ` Robert Love
2002-10-03 22:23 ` Robert Love
@ 2002-10-03 22:24 ` Patrick Mochel
1 sibling, 0 replies; 70+ messages in thread
From: Patrick Mochel @ 2002-10-03 22:24 UTC (permalink / raw)
To: bidulock; +Cc: kernel
> > What is the kernel.org take on this?
I'm not sure if kernel.org has an opinion. ;)
But, Linus appears to be open to the notion, since it's now in his BK
tree:
http://linus.bkbits.net:8080/linux-2.5/cset@1.692?nav=index.html|ChangeSet@-1d
-pat
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 22:14 ` Robert Love
@ 2002-10-03 22:23 ` Robert Love
2002-10-03 22:24 ` Patrick Mochel
1 sibling, 0 replies; 70+ messages in thread
From: Robert Love @ 2002-10-03 22:23 UTC (permalink / raw)
To: bidulock; +Cc: kernel
On Thu, 2002-10-03 at 18:14, Robert Love wrote:
> I do not think it matters what our opinion is.
And if it does, it looks like as-of cset 1.692 2.5 no longer exports the
table either.
Robert Love
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 21:39 Brian F. G. Bidulock
2002-10-03 22:02 ` Alan Cox
2002-10-03 22:14 ` Robert Love
@ 2002-10-03 22:15 ` Greg KH
2002-10-03 22:27 ` Dave Jones
2002-10-04 13:58 ` Christoph Hellwig
3 siblings, 1 reply; 70+ messages in thread
From: Greg KH @ 2002-10-03 22:15 UTC (permalink / raw)
To: kernel
On Thu, Oct 03, 2002 at 03:39:43PM -0600, Brian F. G. Bidulock wrote:
> I see that RH, in their infinite wisdom, have seen fit to remove
> the export of sys_call_table in 8.0 kernels breaking any loadable
> modules that wish to implement non-implemented system calls such
> as LiS's or iBCS implementation of putmsg/getmsg.
>
> sys_call_table is exported in current 2.4 and 2.5 kernels.
As of 2.5.40bk it is now also not exported, which is a good thing.
> Until now, loadable modules have been able to just overwrite
> the non implemented point in the sys_call_table when they load
> and putting it back when they unload. There is no mechanism
> for registering system calls.
That's a racy, easily breakable thing to do. Don't do it.
> What is the kernel.org take on this?
It is a good thing that the sys_call_table is now not exported.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 21:39 Brian F. G. Bidulock
2002-10-03 22:02 ` Alan Cox
@ 2002-10-03 22:14 ` Robert Love
2002-10-03 22:23 ` Robert Love
2002-10-03 22:24 ` Patrick Mochel
2002-10-03 22:15 ` Greg KH
2002-10-04 13:58 ` Christoph Hellwig
3 siblings, 2 replies; 70+ messages in thread
From: Robert Love @ 2002-10-03 22:14 UTC (permalink / raw)
To: bidulock; +Cc: kernel
On Thu, 2002-10-03 at 17:39, Brian F. G. Bidulock wrote:
> I see that RH, in their infinite wisdom, have seen fit to remove
> the export of sys_call_table in 8.0 kernels breaking any loadable
> modules that wish to implement non-implemented system calls such
> as LiS's or iBCS implementation of putmsg/getmsg.
It is not safe.
> What is the kernel.org take on this?
I do not think it matters what our opinion is. Red Hat is free to do
whatever they wish. They certainly give enough back to kernel
development that they are able to. In this case, however, I see good
reason for it - overwriting syscall table entries has a number of sticky
points...
Robert Love
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: export of sys_call_table
2002-10-03 21:39 Brian F. G. Bidulock
@ 2002-10-03 22:02 ` Alan Cox
2002-10-03 23:06 ` Brian F. G. Bidulock
` (2 more replies)
2002-10-03 22:14 ` Robert Love
` (2 subsequent siblings)
3 siblings, 3 replies; 70+ messages in thread
From: Alan Cox @ 2002-10-03 22:02 UTC (permalink / raw)
To: bidulock; +Cc: Linux Kernel Mailing List
On Thu, 2002-10-03 at 22:39, Brian F. G. Bidulock wrote:
> I see that RH, in their infinite wisdom, have seen fit to remove
> the export of sys_call_table in 8.0 kernels breaking any loadable
> modules that wish to implement non-implemented system calls such
> as LiS's or iBCS implementation of putmsg/getmsg.
Overwriting syscall table entries is not safe. Its not safe because
there is no locking mechanism, and its not safe because of the pentium
III errata.
> Until now, loadable modules have been able to just overwrite
> the non implemented point in the sys_call_table when they load
> and putting it back when they unload. There is no mechanism
> for registering system calls.
Not actually safely implementable. The right way to do this is a
relevant 2.5 question. In general however you shouldnt need to register
syscalls because the upper layer interfaces already exist (the LiS stuff
is an example otherwise I grant).
Alan
^ permalink raw reply [flat|nested] 70+ messages in thread
* export of sys_call_table
@ 2002-10-03 21:39 Brian F. G. Bidulock
2002-10-03 22:02 ` Alan Cox
` (3 more replies)
0 siblings, 4 replies; 70+ messages in thread
From: Brian F. G. Bidulock @ 2002-10-03 21:39 UTC (permalink / raw)
To: kernel
I see that RH, in their infinite wisdom, have seen fit to remove
the export of sys_call_table in 8.0 kernels breaking any loadable
modules that wish to implement non-implemented system calls such
as LiS's or iBCS implementation of putmsg/getmsg.
sys_call_table is exported in current 2.4 and 2.5 kernels.
Until now, loadable modules have been able to just overwrite
the non implemented point in the sys_call_table when they load
and putting it back when they unload. There is no mechanism
for registering system calls.
What is the kernel.org take on this?
--brian
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
^ permalink raw reply [flat|nested] 70+ messages in thread
end of thread, other threads:[~2003-01-03 8:21 UTC | newest]
Thread overview: 70+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20021003153943.E22418@openss7.org.suse.lists.linux.kernel>
[not found] ` <1033682560.28850.32.camel@irongate.swansea.linux.org.uk.suse.lists.linux.kernel>
[not found] ` <20021003170608.A30759@openss7.org.suse.lists.linux.kernel>
[not found] ` <1033722612.1853.1.camel@localhost.localdomain.suse.lists.linux.kernel>
[not found] ` <20021004051932.A13743@openss7.org.suse.lists.linux.kernel>
2002-10-04 13:01 ` export of sys_call_table Andi Kleen
2002-10-04 13:11 ` Brian F. G. Bidulock
2002-10-04 13:15 ` Andi Kleen
2002-10-04 13:22 ` Brian F. G. Bidulock
2002-10-04 14:11 ` Andi Kleen
2002-10-04 14:31 ` Brian F. G. Bidulock
[not found] ` <20021003221525.GA2221@kroah.com.suse.lists.linux.kernel>
[not found] ` <20021003222716.GB14919@suse.de.suse.lists.linux.kernel>
[not found] ` <1033684027.1247.43.camel@phantasy.suse.lists.linux.kernel>
[not found] ` <20021003233504.GA20570@suse.de.suse.lists.linux.kernel>
[not found] ` <20021003235022.GA82187@compsoc.man.ac.uk.suse.lists.linux.kernel>
[not found] ` <mailman.1033691043.6446.linux-kernel2news@redhat.com.suse.lists.linux.kernel>
[not found] ` <200210040403.g9443Vu03329@devserv.devel.redhat.com.suse.lists.linux.kernel>
[not found] ` <20021003233221.C31444@openss7.org.suse.lists.linux.kernel>
[not found] ` <20021004133657.B17216@devserv.devel.redhat.com.suse.lists.linux.kernel>
2002-10-04 18:14 ` Andi Kleen
2002-10-04 18:46 ` Alan Cox
2002-10-04 18:45 ` Alexander Viro
2002-10-04 19:15 ` Brian F. G. Bidulock
2002-10-04 19:26 ` Andi Kleen
2002-10-04 19:37 ` Pete Zaitcev
2002-10-04 20:17 ` (off-list) Mail headers (was: Re: export of sys_call_table) Sean Neakums
2002-10-04 20:33 ` Sean Neakums
2002-10-04 19:43 ` export of sys_call_table Robert Love
2002-10-04 22:21 ` David S. Miller
2002-10-04 22:41 ` Brian F. G. Bidulock
2002-10-04 22:38 ` David S. Miller
2002-10-08 22:20 ` [PATCH] " Brian F. G. Bidulock
2002-10-08 22:27 ` Brian F. G. Bidulock
2002-10-08 23:39 ` David S. Miller
2002-10-08 23:18 ` David S. Miller
2002-10-09 0:21 ` Brian F. G. Bidulock
2002-10-09 0:00 ` Robert Love
[not found] ` <mailman.1034119380.19047.linux-kernel2news@redhat.com>
2002-10-09 0:30 ` Pete Zaitcev
2002-10-09 0:40 ` Brian F. G. Bidulock
2002-10-04 21:54 Mark Veltzer
-- strict thread matches above, loose matches on Subject: below --
2002-10-03 21:39 Brian F. G. Bidulock
2002-10-03 22:02 ` Alan Cox
2002-10-03 23:06 ` Brian F. G. Bidulock
2002-10-04 9:10 ` Arjan van de Ven
2002-10-04 11:19 ` Brian F. G. Bidulock
2002-10-04 11:31 ` Arjan van de Ven
2002-10-04 11:55 ` Brian F. G. Bidulock
2002-10-04 13:00 ` Alan Cox
2002-10-03 23:10 ` Michal Jaegermann
2002-10-04 0:32 ` Andy Pfiffer
2002-10-04 9:20 ` Arjan van de Ven
2002-10-06 14:17 ` Kasper Dupont
2003-01-03 8:28 ` Eric W. Biederman
2002-10-04 21:06 ` David S. Miller
2002-10-04 21:44 ` Brian F. G. Bidulock
2002-10-12 5:43 ` Eric Blade
2002-10-03 22:14 ` Robert Love
2002-10-03 22:23 ` Robert Love
2002-10-03 22:24 ` Patrick Mochel
2002-10-03 22:15 ` Greg KH
2002-10-03 22:27 ` Dave Jones
2002-10-03 22:27 ` Robert Love
2002-10-03 22:58 ` John Levon
2002-10-03 23:10 ` Alexander Viro
2002-10-03 23:14 ` John Levon
2002-10-04 4:05 ` Muli Ben-Yehuda
2002-10-04 4:46 ` Greg KH
2002-10-04 4:53 ` Muli Ben-Yehuda
2002-10-03 23:35 ` Dave Jones
2002-10-03 23:50 ` John Levon
2002-10-04 0:17 ` Brian F. G. Bidulock
[not found] ` <mailman.1033691043.6446.linux-kernel2news@redhat.com>
2002-10-04 4:03 ` Pete Zaitcev
2002-10-04 5:32 ` Brian F. G. Bidulock
2002-10-04 11:42 ` John Levon
2002-10-04 12:03 ` Brian F. G. Bidulock
2002-10-04 13:02 ` Alan Cox
2002-10-04 17:36 ` Pete Zaitcev
2002-10-05 1:39 ` John Levon
2002-10-04 13:58 ` Christoph Hellwig
2002-10-04 15:15 ` Brian F. G. Bidulock
2002-10-04 15:28 ` Christoph Hellwig
2002-10-04 16:19 ` Brian F. G. Bidulock
2002-10-04 16:25 ` 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).