[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160920084312.GF30248@linaro.org>
Date: Tue, 20 Sep 2016 17:43:14 +0900
From: AKASHI Takahiro <takahiro.akashi@...aro.org>
To: Jason Wessel <jason.wessel@...driver.com>
Cc: catalin.marinas@....com, will.deacon@....com, broonie@...nel.org,
yong.zhao@....com, Vijaya.Kumar@...iumnetworks.com,
kgdb-bugreport@...ts.sourceforge.net,
linux-arm-kernel@...ts.infradead.org,
linaro-kernel@...ts.linaro.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH] arm64: kgdb: fix single stepping
Jason,
On Mon, Sep 19, 2016 at 05:29:36PM -0500, Jason Wessel wrote:
> On 09/15/2016 11:32 PM, AKASHI Takahiro wrote:
> >@@ -176,18 +183,14 @@ int kgdb_arch_handle_exception(int exception_vector, int signo,
> >>> * over and over again.
> >>> */
> >>> kgdb_arch_update_addr(linux_regs, remcom_in_buffer);
> >>>- atomic_set(&kgdb_cpu_doing_single_step, -1);
> >>>- kgdb_single_step = 0;
> >>
> >>This is a subtle change, but I assume it is what you intended? All the CPUs will get released into the run state when exiting the kgdb exception handler.
> >You are talking about "- kgdb_single_step = 0." Right?
>
>
> Correct.
>
> >Do you think that there is any (negative) side effect of this change?
>
>
> Not at all. The kernel debugger always skids to a stop, and it is more reliable from a locking perspective if the other CPU threads are released while a single CPU is asked to single step until the next "skid" for all the other CPUs.
>
> When you do not release the other CPUs you can end up single stepping a CPU which dead locks or never exits a lock elsewhere due to what ever it was blocking on never getting freed from another CPU.
Thank you for the explanation. This convinces me very much.
-Takahiro AKASHI
> Cheers,
> Jason.
Powered by blists - more mailing lists