lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ