On Thu, Apr 20, 2000 at 07:59:49PM +0100, Tigran Aivazian wrote:
> On Thu, 20 Apr 2000, Tigran Aivazian wrote:
> > > On Thu, Apr 20, 2000 at 07:12:03PM +0100, Tigran Aivazian wrote:
> > > > On Thu, 20 Apr 2000, Borislav Deianov wrote:
> > > > > Modifying sys_call_table from a module works fine but is architecture
> > > > > specific (I'm told) and gets interesting when two modules try to
> > > > > intercept the same system call.
> > > >
> > > > this interesting part can be resolved rather straightforward
> > > > by providing an (exported) read-write spinlock that is taken
> > > > for read on each system call and write by those wishing to
> > > > modify sys_call_table[]. (this is not nice because of the
> > > > effort of taking even a read spinlock on each syscall)
> >
> > oops, I just realized that I shouldn't have said above or put a smiley in
> > front of it :)
> >
> > Ok, since you fell for it - let's at least make a useful excercise out of
> > it - find why my "suggestion" is totally broken...
>
> or at least "totally broken" when taken literally, i.e. holding the
> spinlock over the entire syscall. But there is nothing wrong with,
> e.g. copying the pointer somewhere safe and private, unlocking the
> spinlock and calling it. If, understood in this sense, it seems ok.
Sounds like you are having an argument with yourself :)
I'm not sure what is the point of taking the lock for reading. If
somebody is updating the pointer while we are in the call instruction
we should either get the old value or the new value, both of which
should be valid. Different writers can use a normal spinlock to
protect each other.
Borislav
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:17 EST