Hello.
Amit S. Kale 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.
Yeah, I figured this out myself later (but it was 1:30 am already :-)...
> With this change keeping post_exception at current place is fine.
> Thanks for this analysis!
Well, the good analysys should be followed by the patch -- which I'm
preparing... :-)
> -Amit
WBR, Sergei
-------------------------------------------------------------------------
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
