Of all the gin joints in all the towns in all the world, Mark Tinguely had to walk into mine and say: > We are chasing a different panic (kern/88725) where dynamic callout > are freed but the callout could be still pending. The freed memory > can be re-allocated, modified and then cause errors when the timer > wheel is checked. > > After finding this one occurance, I did a complete search of callouts, > and I see a potential simular error in the ntoskrnl_libfini() routine > in the file /sys/compat/ndis/subr_ntoskrnl.c and a few other places > (7 total). I wanted to make verify each of these 7 occurances before > issuing a patch. > > I suspect a simple test loop could verify that this is a simular error > as kern/88725. > > --Mark Tinguely Hm. Unfortunately, the ntoskrnl_libfini() won't be called until the ndis.ko module is unloaded, and that's not happening here. That isn't to say that there isn't a callout bug in there somewhere. Note that Project Evil has its own callwheel because struct callout doesn't fit inside the Windows struct KTIMER (and in Windows, drivers allocate KTIMERs themselves from the heap and can free them without calling any routine to deallocate them first). The assumption is that by the time MiniportHalt() has completed, the underlying driver has stopped/cancelled all the timers it started. Originally I used the timeout()/untimeout() API, but I found that in some cases I would find myself trying to cancel a timer that had already fired. This problem doesn't occur with the built-in callwheel that's there now. Also, using timeout()/untimeout() causes timer callouts to be run with Giant held, which I didn't want. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul_at_windriver.com | Wind River Systems ============================================================================= "Ignorance may be bliss, but delusion is ecstasy!" -Perki =============================================================================Received on Thu Nov 10 2005 - 18:59:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:47 UTC