Sergei Shtylyov wrote: > Hello. > > Wessel, Jason wrote: >> Sergei, >> >> kgdb_unset_may_fault() is responsible for restoring the preempt count. >> And if it is not in the return path from a set_longjmp, then there is no >> way to restore the preempt count. >> It may seem counter intuitive to have the mayfault setup before >> settingup up the stack for a possible return from a long jump, but that >> is the way it works right now. > > But... do we need to restore preempt_count on a "normal" exit path > from the functions making use of kgdb_fault_setjmp()? I guess not...
It is true that on the normal exit path you would not need to restore the context. That would mean a bit more restructuring and cleanup in order to implement it that that way. At least at the current time the preempt counting is no longer an issue with the may fault path. > >> Another possibility would be to split the functions to explicitly save >> the preempt count separately if you realy want to move the may_fault >> sets and unsets around. > > Yeah, wrapping kgdb_fault_setjmp() into the code saving/restoreing > preempt count seems a way to go... A new macro could be added to do the setjump+save+exit+restor, but if you have another exit point, you still have to have a 2nd cleanup handler which can also do exit+restore because exiting kgdb with may_fault set would definitely kill off the kernel in some bizarre way. Jason. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
