* 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; 60+ 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] 60+ messages in thread
* Re: export of sys_call_table 2002-10-03 21:39 export of sys_call_table 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ messages in thread
* Re: export of sys_call_table 2002-10-03 21:39 export of sys_call_table 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ messages in thread
* Re: export of sys_call_table 2002-10-03 21:39 export of sys_call_table 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ messages in thread
[parent not found: <mailman.1033691043.6446.linux-kernel2news@redhat.com>]
* 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ messages in thread
* Re: export of sys_call_table 2002-10-03 21:39 export of sys_call_table 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ messages in thread
[parent not found: <20021003153943.E22418@openss7.org.suse.lists.linux.kernel>]
[parent not found: <1033682560.28850.32.camel@irongate.swansea.linux.org.uk.suse.lists.linux.kernel>]
[parent not found: <20021003170608.A30759@openss7.org.suse.lists.linux.kernel>]
[parent not found: <1033722612.1853.1.camel@localhost.localdomain.suse.lists.linux.kernel>]
[parent not found: <20021004051932.A13743@openss7.org.suse.lists.linux.kernel>]
* 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; 60+ 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] 60+ messages in thread
* Re: export of sys_call_table 2002-10-04 13:01 ` Andi Kleen @ 2002-10-04 13:11 ` Brian F. G. Bidulock 2002-10-04 13:15 ` Andi Kleen 0 siblings, 1 reply; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ messages in thread
[parent not found: <20021003221525.GA2221@kroah.com.suse.lists.linux.kernel>]
[parent not found: <20021003222716.GB14919@suse.de.suse.lists.linux.kernel>]
[parent not found: <1033684027.1247.43.camel@phantasy.suse.lists.linux.kernel>]
[parent not found: <20021003233504.GA20570@suse.de.suse.lists.linux.kernel>]
[parent not found: <20021003235022.GA82187@compsoc.man.ac.uk.suse.lists.linux.kernel>]
[parent not found: <mailman.1033691043.6446.linux-kernel2news@redhat.com.suse.lists.linux.kernel>]
[parent not found: <200210040403.g9443Vu03329@devserv.devel.redhat.com.suse.lists.linux.kernel>]
[parent not found: <20021003233221.C31444@openss7.org.suse.lists.linux.kernel>]
[parent not found: <20021004133657.B17216@devserv.devel.redhat.com.suse.lists.linux.kernel>]
* 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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 ` Robert Love @ 2002-10-04 22:21 ` David S. Miller 2002-10-04 22:41 ` Brian F. G. Bidulock 3 siblings, 1 reply; 60+ 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] 60+ 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; 60+ 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] 60+ 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 0 siblings, 0 replies; 60+ 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] 60+ messages in thread
* Re: export of sys_call_table
@ 2002-10-04 21:54 Mark Veltzer
0 siblings, 0 replies; 60+ 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] 60+ messages in thread
end of thread, other threads:[~2003-01-03 8:21 UTC | newest] Thread overview: 60+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-10-03 21:39 export of sys_call_table 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 [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 ` 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 19:43 ` 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-04 21:54 Mark Veltzer
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).