On Friday 30 March 2007 02:34, Sergei Shtylyov wrote:
> Hello.
>
> komal wrote:
> > As the discussion was going on about the effects of trapping the
> > netpoll queue during KGDBoE debugging, I tried avoiding it. So in
> > eth_pre_exception_handler() I did not set net_poll_trap to 1 and did not
> > reset it back to 0 in eth_post_exception_handler()
> >
> > file drivers/net/kgdboe.c
> >
> > static void eth_pre_exception_handler(void)
> > {
> > /* Increment the module count when the debugger is active */
> > if (!kgdb_connected)
> > try_module_get(THIS_MODULE);
> > // netpoll_set_trap(1);
> > }
> >
> > static void eth_post_exception_handler(void)
> > {
> > /* decrement the module count when the debugger detaches */
> > if (!kgdb_connected)
> > module_put(THIS_MODULE);
> > // netpoll_set_trap(0);
> > }
>
> BTW, I've looked into kgdb_handle_exception() and I think I've spotted
> couple of issues with calling these methods:
>
> - the pre_exception() method may be called several times in a row because
> of acquirelock label preceding its call -- the code will go back to this
> label under some circumstances and therefore netpoll's 'trapping' variable
> will be incremented more than once but will only be decremented once upon
> exit;
This can occur on SMP systems.
> - if KGDB hits a disabled breakpoint (can only happen on x86), the code
> will jump to the kgdb_restore label bypassing a call to the
> post_exception() method.
True. Again on i386 SMP systems this can happen.
> Obviously, this may render device queue frozen even after KGDB leaves
> the exception (because of CONFOG_NETPOLL_TRAP). What about moving the
> post_exception() call under kgdb_restore label (that is, after all the CPUs
> have quit from KGDB -- which would seem symmetrical to post_exception()
> call that is made before all CPUs are stopped) and moving the
> post_exception() call before acauirelock label?
We can't move pre_exception before acquirelock label since multiple CPUs may
execute that before attempting to acquire kgdb lock. pre_exception should be
moved past the call to kgdb_skipexception as that is the point where we
decide that current CPU is the master. There is no backtracking after that
point.
With this change keeping post_exception at current place is fine.
Thanks for this analysis!
-Amit
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
