export of sys_call_table

export of sys_call_table

[Brian F. G. Bidulock]

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 ¦

Re: export of sys_call_table

[Alan Cox]

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

Re: export of sys_call_table

[Brian F. G. Bidulock]

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 ¦

Re: export of sys_call_table

[Arjan van de Ven]

[-- 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 --]

Re: export of sys_call_table

[Brian F. G. Bidulock]

[-- 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 --]

Re: export of sys_call_table

[Arjan van de Ven]

[-- 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 --]

Re: export of sys_call_table

[Brian F. G. Bidulock]

[-- 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 --]

Re: export of sys_call_table

[Alan Cox]

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

Re: export of sys_call_table

[Michal Jaegermann]

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

Re: export of sys_call_table

[Andy Pfiffer]

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

Re: export of sys_call_table

[Arjan van de Ven]

[-- 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 --]

Re: export of sys_call_table

[Kasper Dupont]

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

Re: export of sys_call_table

[Eric W. Biederman]

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

Re: export of sys_call_table

[David S. Miller]

   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.

Re: export of sys_call_table

[Brian F. G. Bidulock]

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 ¦

Re: export of sys_call_table

[Eric Blade]

> 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.
	

Re: export of sys_call_table

[Robert Love]

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

Re: export of sys_call_table

[Robert Love]

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

Re: export of sys_call_table

[Patrick Mochel]

> > 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

Re: export of sys_call_table

[Greg KH]

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

Re: export of sys_call_table

[Dave Jones]

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

Re: export of sys_call_table

[Robert Love]

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

Re: export of sys_call_table

[John Levon]

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

Re: export of sys_call_table

[Alexander Viro]

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/*...

Re: export of sys_call_table

[John Levon]

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

Re: export of sys_call_table

[Muli Ben-Yehuda]

[-- 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 --]

Re: export of sys_call_table

[Greg KH]

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

Re: export of sys_call_table

[Muli Ben-Yehuda]

[-- 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 --]

Re: export of sys_call_table

[Dave Jones]

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

Re: export of sys_call_table

[John Levon]

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

Re: export of sys_call_table

[Brian F. G. Bidulock]

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 ¦

Re: export of sys_call_table

[Pete Zaitcev]

>> 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

Re: export of sys_call_table

[Brian F. G. Bidulock]

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 ¦

Re: export of sys_call_table

[John Levon]

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

Re: export of sys_call_table

[Brian F. G. Bidulock]

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 ¦

Re: export of sys_call_table

[Alan Cox]

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

Re: export of sys_call_table

[Pete Zaitcev]

> 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

Re: export of sys_call_table

[John Levon]

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

Re: export of sys_call_table

[Christoph Hellwig]

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.

Re: export of sys_call_table

[Brian F. G. Bidulock]

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

Re: export of sys_call_table

[Christoph Hellwig]

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.

Re: export of sys_call_table

[Brian F. G. Bidulock]

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 ¦

Re: export of sys_call_table

[Christoph Hellwig]

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*

Re: export of sys_call_table

[Andi Kleen]

"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

Re: export of sys_call_table

[Brian F. G. Bidulock]

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 ¦

Re: export of sys_call_table

[Andi Kleen]

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

Re: export of sys_call_table

[Brian F. G. Bidulock]

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 ¦

Re: export of sys_call_table

[Andi Kleen]

> 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

Re: export of sys_call_table

[Brian F. G. Bidulock]

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 ¦

Re: export of sys_call_table

[Andi Kleen]

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

Re: export of sys_call_table

[Alan Cox]

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

Re: export of sys_call_table

[Alexander Viro]

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.

Re: export of sys_call_table

[Brian F. G. Bidulock]

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                      */

Re: export of sys_call_table

[Andi Kleen]

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

Re: export of sys_call_table

[Pete Zaitcev]

> 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

Re: export of sys_call_table

[Robert Love]

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

Re: export of sys_call_table

[David S. Miller]

   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.

Re: export of sys_call_table

[Brian F. G. Bidulock]

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

Re: export of sys_call_table

[David S. Miller]

   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.

Re: export of sys_call_table

[Mark Veltzer]

-----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-----