Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 May 1998 03:35:50 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        stevek@tis.com (Steve Kiernan)
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Restoring syscall for blocked procs in mod unload
Message-ID:  <199805200335.UAA27910@usr04.primenet.com>
In-Reply-To: <Pine.BSF.3.96.980519170800.198A-100000@mufasa.va.tis.com> from "Steve Kiernan" at May 19, 98 05:18:09 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> I'm working on a project which uses an LKM that intercepts the syscalls
> for specific processes.  The problem I'm trying to solve is that if there
> is a process which is blocked in a syscall which is intercepted by the LKM
> and you unload the LKM, when the syscall unblocks and the stack frame is
> popped, the EIP can be pointing to an invalid address and the kernel will
> panic.

A module can veto the unload if it is in use; you must reference count.

Increment a volatile variable on the way in, and decrement on the way out.

If the volatile variable is non-zero at unload request time, deny the
unload.


I initially had some code that would schedule a wakeup at intervals,
and do the unload on your behalf (the unload was sheculed to happen
rather than invoked at call time).  This code was removed on release,
and kernel timer architecture has changed so drastically away from the
ability to even implement the services I relied upon for this (a
reschedulable timer oneshot outcall) that it would be hard to do it
without a kernel process that runs (say every 15 or 30 seconds).

In that architecture, you would have to make the process code static,
since you couldn't ever unload it, so you would have to implement it
as a service (which is what the timer outcall did, only it didn't
have the cruddy 7.5-15 second average latency a "sync" type kernel
process would have).

Once you have that, you veto with a "pending" status code, and return
to the caller after enqueueing the unload.

You should set another volatile variable to indicate that subsequent
entries should be refused with ENOSYS; effectively, this variable is
just a flag that indicates that you have restored the syscall entry
vector.


Pretty trivial, if you steal your examples from the updated/syncd, etc.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805200335.UAA27910>