linux-kernel - Re: [PATCH 2/2] tracing: Fix for non-continuous cpu ids

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150602102610.2772a2e6@gandalf.local.home>
Date:	Tue, 2 Jun 2015 10:26:10 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Gil Fruchter <gilf@...hip.com>
Cc:	<mingo@...hat.com>, <linux-kernel@...r.kernel.org>,
	<giladb@...hip.com>, <cmetcalf@...hip.com>, <noamc@...hip.com>
Subject: Re: [PATCH 2/2] tracing: Fix for non-continuous cpu ids

On Tue, 2 Jun 2015 16:26:29 +0300
Gil Fruchter <gilf@...hip.com> wrote:

> Currently exception occures due to access beyond buffer_iter
> range while using index of cpu bigger than num_possible_cpus().
> Below there is an example for such exception when we use
> cpus 0,1,16,17.

I'm curious, what broken boxes have non-continuous cpu ids?

> 
> In order to fix buffer allocation size for non-continuous cpu ids
> we allocate according to the max cpu id and not according to the
> amount of possible cpus.
> 
> Example:
>   $ cat /sys/kernel/debug/tracing/per_cpu/cpu1/trace
>   Path: /bin/busybox
>   CPU: 0 PID: 82 Comm: cat Not tainted 4.0.0 #29
>   task: 80734c80 ti: 80012000 task.ti: 80012000
> 
>   [ECR   ]: 0x00220100 => Invalid Read @ 0x00000000 by insn @ 0x800abafc
>   [EFA   ]: 0x00000000
>   [BLINK ]: ring_buffer_read_finish+0x24/0x64
>   [ERET  ]: rb_check_pages+0x20/0x188
>   [STAT32]: 0x00001a00 :
>   BTA: 0x800abafc  SP: 0x80013f0c  FP: 0x57719cf8
>   LPS: 0x200036b4 LPE: 0x200036b8 LPC: 0x00000000
>   r00: 0x8002aca0 r01: 0x00001606 r02: 0x00000000
>   r03: 0x00000001 r04: 0x00000000 r05: 0x804b4954
>   r06: 0x00030003 r07: 0x8002a260 r08: 0x00000286
>   r09: 0x00080002 r10: 0x00001006 r11: 0x807351a4
>   r12: 0x00000001
> 
>   Stack Trace:
>     rb_check_pages+0x20/0x188
>     ring_buffer_read_finish+0x24/0x64
>     tracing_release+0x4e/0x170
>     __fput+0x62/0x158
>     task_work_run+0xa2/0xd4
>     do_notify_resume+0x52/0x7c
>     resume_user_mode_begin+0xdc/0xe0

How common is this? Is this something that should be marked for stable?

-- Steve


> 
> Signed-off-by: Noam Camus <noamc@...hip.com>
> Signed-off-by: Gil Fruchter <gilf@...hip.com>
> ---
>  kernel/trace/trace.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 57ffc4a..8c5b382 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -3034,7 +3034,7 @@ __tracing_open(struct inode *inode, struct file *file, bool snapshot)
>  	if (!iter)
>  		return ERR_PTR(-ENOMEM);
>  
> -	iter->buffer_iter = kcalloc(num_possible_cpus(), sizeof(*iter->buffer_iter),
> +	iter->buffer_iter = kcalloc(nr_cpu_ids, sizeof(*iter->buffer_iter),
>  				    GFP_KERNEL);
>  	if (!iter->buffer_iter)
>  		goto release;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/