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]
Date:	Fri, 27 Jun 2014 15:14:58 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>
Cc:	Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	linux-kernel@...r.kernel.org, yrl.pp-manager.tt@...achi.com
Subject: Re: [PATCH 1/2] trace-cmd: [BUGFIX] Initialize handle->options list
 in tracecmd_attach_cpu_data_fd()

On Tue, 24 Jun 2014 02:23:43 +0000
Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com> wrote:

> This patch initializes handle->options list in tracecmd_attach_cpu_data_fd().
> 
> When recorder sends trace data via network, server recording process is
> killed by SIGSEGV from the patch 71484a0854f7. This is because add_options()
> uses handle->options list from the patch, but tracecmd_attach_cpu_data_fd()
> calling add_options() does not initialize the list in spite of allocation of
> new handle. As the result, the server recording process will be killed because
> handle->options is cleared to zero in tracecmd_attach_cpu_data_fd().
> 
> <How to test>
> 1. Execute network(listen) server
>  # trace-cmd listen -p 12345
> 
> 2. Execute network client
>  # trace-cmd record -e sched* -N <server IP>:12345
> 
> 3. Stop the record on client
>  ^C
> 
>  Here, network server should output a line "CPUX data recorded at offset=XXXX",
>  but current network server aborts silently.
> 
>  Moreover the client's per-cpu files are separated. (Normally those files
>  are merged into one trace file.)
> 
> 4. Confirm error on network server
>  #  dmesg | tail -1
> [18551.537113] trace-cmd[23073]: segfault at ffffffffffffffe8 ip 0000000000432fd1 sp 00007fffffa4caa0 error 5 in trace-cmd[400000+47000]
> 
>  After we would introduce this patch, the server will be fully able to output
>  the client's tracing data and we will not get this error.
> 
> Signed-off-by: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>
> Cc: Steven Rostedt <rostedt@...dmis.org>

Applied thanks! I also added a test to my trace-cmd test suite to check
trace-cmd listen.

-- Steve


> ---
>  trace-output.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/trace-output.c b/trace-output.c
> index ed81466..b033baa 100644
> --- a/trace-output.c
> +++ b/trace-output.c
> @@ -1202,6 +1202,7 @@ int tracecmd_attach_cpu_data_fd(int fd, int cpus, char * const *cpu_data_files)
>  	handle->pevent = tracecmd_get_pevent(ihandle);
>  	pevent_ref(pevent);
>  	handle->page_size = tracecmd_page_size(ihandle);
> +	list_head_init(&handle->options);
>  
>  	if (tracecmd_append_cpu_data(handle, cpus, cpu_data_files) >= 0)
>  		ret = 0;

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ