linux-kernel - Re: [PATCH] arm64: smp call when task currently running on other cpu

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]

Message-ID: <20200612132943.GA71861@C02TD0UTHF1T.local>
Date:   Fri, 12 Jun 2020 14:29:43 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Wang Qing <wangqing@...o.com>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        James Morse <james.morse@....com>,
        Dave Martin <Dave.Martin@....com>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        jinho lim <jordan.lim@...sung.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        opensource.kernel@...o.com
Subject: Re: [PATCH] arm64: smp call when task currently running on other cpu

On Fri, Jun 12, 2020 at 03:41:46PM +0800, Wang Qing wrote:
> We cannot get FP and PC when the task is running on another CPU,
> task->thread.cpu_context is the last time the task was switched out,
> we can use smp call to print backtrace itself.
> 
> Signed-off-by: Wang Qing <wangqing@...o.com>

Sorry, but NAK to this as-is. This is not a legitimate use of
dump_backtrace(), and even if we wanted to dump a backtrace of a
remotely running task, the patch is:

* Insufficient, since a remotely running task can become blocked after
  task_curr() is sampled.

* Insufficient and incorrect, since the task can be rescheduled after
  task->cpu is sampled. This patch could cause *another* task to dump a
  stacktrace.

* Unsafe, since tsk->cpu is accessed racily. In practice we'd likely get
  away with that, but it's not something we should rely on.

* Unsafe, since if this were ever called in IRQ context it could result
  in a deadlock.

Taking a step back, please explain *why* you think you need this?

What code in mainline is calling dumop_backtrace() on a remotely running
task?

Thanks,
Mark.

> ---
>  arch/arm64/kernel/traps.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>  mode change 100644 => 100755 arch/arm64/kernel/traps.c
> 
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 50cc30a..17a07b9
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -83,6 +83,11 @@ static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
>  	printk("%sCode: %s\n", lvl, str);
>  }
>  
> +static void dump_backtrace_smp_fun(struct task_struct *tsk)
> +{
> +	dump_backtrace(NULL, tsk, KERN_DEFAULT);
> +}
> +
>  void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
>  		    const char *loglvl)
>  {
> @@ -107,6 +112,12 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
>  		start_backtrace(&frame,
>  				(unsigned long)__builtin_frame_address(0),
>  				(unsigned long)dump_backtrace);
> +	} else if (task_curr(tsk)) {
> +		/*
> +		 * The task is currently running on other cpu
> +		 */
> +		smp_call_function_single(tsk->cpu, dump_backtrace_fun, tsk, 0);
> +		return;
>  	} else {
>  		/*
>  		 * task blocked in __switch_to
> -- 
> 2.7.4
>