hello...
Thanks for your reply. Regarding your suspects -
1. I am actually calling the register_timer_interrupt routine to register the hook only once by running the userspace program once that registers the hook. So there should not be any lock contention I think unless the lock is global in the kernel!!!
I didn't talk about the registration. I talked about do_timer() that
calls your hook (whether it's NULL or pointing to valid function). About
the lock, how do you know the lock isn't global? Even though (assume)
it's not global, but if many code paths use this lock, you still suffer
contention.
And please, no need for 3 exclamation marks. I can understand technical
objection without them, don't worry.
2. I can't think about why it would overflow kernel stack because do_timer() calls many other functions too and my registered hook is like any function call which is currently empty. So it should not take any time to execute it.
That was pure guess. And that's why I suggest to try enlarging your
stack size in case you use 4K stack. And using inline version of your
hook management function could probably help. If none of them helps,
then we can be fairly sure it's not stack problem
3. After I load the module, I run the userspace program which registers the hook and terminates. The system runs fine for about 5-10 secs after that before freezing.
hm wait2x, you said "userspace program registers the hook?" So where's
this hook function live? user space? kernel space? I am not clear about it.
BTW, about xchg(). Are you sure you need that? what if you just use
spinlock and/or disabling interrupt?
regards,
Mulyadi.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
