linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Subject: Re: [PATCH] trace-cmd: Fix segmentation fault in tracecmd_read_at() in specific use case
Date: Mon, 14 Oct 2019 10:07:06 -0400	[thread overview]
Message-ID: <20191014100706.3c8d0cef@gandalf.local.home> (raw)
In-Reply-To: <20191011113353.11652-1-tz.stoyanov@gmail.com>

On Fri, 11 Oct 2019 14:33:53 +0300
"Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com> wrote:

> There is a segmentation fault in update_page_info() when the requested page
> is not loaded, handle->cpu_data[cpu].page is NULL. The problematic flow starts
> from tracecmd_read_at() API, when reading offset in the first page (less than 4K),
> and this page is still not loaded yet. The problem can be observed randomly -
> there is a sporadic KernelShark crash when loading a file, browsing and
> zooming events.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=205165
> Signed-off-by: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
> ---
>  lib/trace-cmd/trace-input.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/trace-cmd/trace-input.c b/lib/trace-cmd/trace-input.c
> index 6102eb3..da77418 100644
> --- a/lib/trace-cmd/trace-input.c
> +++ b/lib/trace-cmd/trace-input.c
> @@ -1278,7 +1278,8 @@ tracecmd_read_at(struct tracecmd_input *handle, unsigned long long offset,
>  	/* check to see if we have this page already */
>  	for (cpu = 0; cpu < handle->cpus; cpu++) {
>  		if (handle->cpu_data[cpu].offset == page_offset &&
> -		    handle->cpu_data[cpu].file_size)
> +		    handle->cpu_data[cpu].file_size &&
> +		    handle->cpu_data[cpu].page)
>  			break;
>  	}
>  

This does indeed look like a legit bug. But instead of checking here
for page not existing, since it's not part of the criteria for finding
the page (if the offset matches, we still want to break), lets do the
check below:

	if (cpu < handle->cpus && handle->cpu_data[cpu].page) {
		if (pcpu)
			*pcpu = cpu;
		return read_event(handle, offset, cpu);
	} else
		return find_and_read_event(handle, offset, pcpu);

-- Steve

      reply	other threads:[~2019-10-14 14:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11 11:33 [PATCH] trace-cmd: Fix segmentation fault in tracecmd_read_at() in specific use case Tzvetomir Stoyanov (VMware)
2019-10-14 14:07 ` Steven Rostedt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191014100706.3c8d0cef@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=tz.stoyanov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).