public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: Arjan van de Ven <arjanv@fenrus.demon.nl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: export of sys_call_table
Date: Fri, 4 Oct 2002 05:19:32 -0600	[thread overview]
Message-ID: <20021004051932.A13743@openss7.org> (raw)
In-Reply-To: <1033722612.1853.1.camel@localhost.localdomain>; from arjanv@fenrus.demon.nl on Fri, Oct 04, 2002 at 11:10:12AM +0200

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

  reply	other threads:[~2002-10-04 11:14 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2002-10-04 21:54 Mark Veltzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021004051932.A13743@openss7.org \
    --to=bidulock@openss7.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjanv@fenrus.demon.nl \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox