From owner-freebsd-hackers Tue May 19 20:36:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA00333 for freebsd-hackers-outgoing; Tue, 19 May 1998 20:36:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA00290 for ; Tue, 19 May 1998 20:36:05 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id UAA02748; Tue, 19 May 1998 20:36:00 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp01.primenet.com, id smtpd002706; Tue May 19 20:35:52 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id UAA27910; Tue, 19 May 1998 20:35:50 -0700 (MST) From: Terry Lambert Message-Id: <199805200335.UAA27910@usr04.primenet.com> Subject: Re: Restoring syscall for blocked procs in mod unload To: stevek@tis.com (Steve Kiernan) Date: Wed, 20 May 1998 03:35:50 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Steve Kiernan" at May 19, 98 05:18:09 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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