Date: Mon, 14 Dec 1998 03:26:43 -0800 From: Mike Smith <mike@smith.net.au> To: Reinier Bezuidenhout <Reinier.Bezuidenhout@KryptoKom.DE> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: kernel and ioctl call to kernel function Message-ID: <199812141126.DAA00554@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 08 Dec 1998 11:40:01 %2B0100." <199812081040.LAA08899@borg.kryptokom.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> We have implemented a funtion in the kernel that does some > operations on data given to the function. This function > can be called from within the kernel AND from user level > via a ioctl call. Can it be called at interrupt time? > What will happen if the kernel calls this function after > the user level process also called this function via > the ioctl or vice versa. Does the one wait for the > other before the function is entered ??? There is only one thread of execution inside the kernel (at the moment; if/when the SMP kernel locks are pushed down this may change), so unless you call this function from an interrupt context it will never be reentered. > I see some strange behaviour where the user level process > never seems to hang (no characters are echo'd to the screen > anymore, I can still swap vertual screens, but to character > input and the num-lock still worlks :) ). This is consistent with a corruption of the interrupt mask, usually caused by a bug in interrupt-masking code, or kernel code in eg. a system call that is spinning without completing and returning to user mode. > How is this "simultanious" call to the same function handled ?? The kernel is just a big program, and interrupts are like signal handlers; you are required to call interrupt-safe functions from inside interrupt handlers, and to perform interrupt-related locking when you want to manipulate data in an atomic fashion. Just what you need to do here isn't possible to determine, as you haven't provided enough information, but my guess is that your function is either not reentrant but is being reentered (probably called from an interrupt handler as well as the ioctl), or you are manipulating one or more datastructures in an unsafe fashion. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199812141126.DAA00554>