From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751624AbdFHLyo (ORCPT <rfc822;w@1wt.eu>);
        Thu, 8 Jun 2017 07:54:44 -0400
Received: from mx1.redhat.com ([209.132.183.28]:40292 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751597AbdFHLym (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 8 Jun 2017 07:54:42 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9273F61B8F
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jolsa@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9273F61B8F
Date: Thu, 8 Jun 2017 13:54:38 +0200
From: Jiri Olsa <jolsa@redhat.com>
To: David Carrillo-Cisneros <davidcc@google.com>
Cc: linux-kernel@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Andi Kleen <ak@linux.intel.com>, Simon Que <sque@chromium.org>,
        Wang Nan <wangnan0@huawei.com>, Jiri Olsa <jolsa@kernel.org>,
        He Kuang <hekuang@huawei.com>, Masami Hiramatsu <mhiramat@kernel.org>,
        Stephane Eranian <eranian@google.com>, Paul Turner <pjt@google.com>
Subject: Re: [PATCH v3 08/15] perf header: use struct feat_fd to process
 header records
Message-ID: <20170608115438.GC29151@krava>
References: <20170606070722.35213-1-davidcc@google.com>
 <20170606070722.35213-9-davidcc@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170606070722.35213-9-davidcc@google.com>
User-Agent: Mutt/1.8.0 (2017-02-23)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 08 Jun 2017 11:54:41 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jun 06, 2017 at 12:07:15AM -0700, David Carrillo-Cisneros wrote:

SNIP

> +static int process_cpu_topology(struct feat_fd *ff, void *data __maybe_unused)
>  {
>  	u32 nr, i;
>  	char *str;
>  	struct strbuf sb;
> -	int cpu_nr = ph->env.nr_cpus_avail;
> +	int cpu_nr = ff->ph->env.nr_cpus_avail;
>  	u64 size = 0;
> +	struct perf_header *ph = ff->ph;
> +	u64 start_offset = ff->offset;
>  
>  	ph->env.cpu = calloc(cpu_nr, sizeof(*ph->env.cpu));
>  	if (!ph->env.cpu)
>  		return -1;
>  
> -	if (do_read_u32(fd, ph, &nr))
> +	if (do_read_u32(ff->fd, ff->ph, &nr))
>  		goto free_cpu;
>  
>  	ph->env.nr_sibling_cores = nr;
> @@ -1764,7 +1753,7 @@ static int process_cpu_topology(struct perf_file_section *section,
>  		goto free_cpu;
>  
>  	for (i = 0; i < nr; i++) {
> -		str = do_read_string(fd, ph);
> +		str = do_read_string(ff->fd, ff->ph);
>  		if (!str)
>  			goto error;
>  
> @@ -1776,14 +1765,14 @@ static int process_cpu_topology(struct perf_file_section *section,
>  	}
>  	ph->env.sibling_cores = strbuf_detach(&sb, NULL);
>  
> -	if (do_read_u32(fd, ph, &nr))
> +	if (do_read_u32(ff->fd, ff->ph, &nr))
>  		return -1;
>  
>  	ph->env.nr_sibling_threads = nr;
>  	size += sizeof(u32);
>  
>  	for (i = 0; i < nr; i++) {
> -		str = do_read_string(fd, ph);
> +		str = do_read_string(ff->fd, ff->ph);
>  		if (!str)
>  			goto error;
>  
> @@ -1799,18 +1788,18 @@ static int process_cpu_topology(struct perf_file_section *section,
>  	 * The header may be from old perf,
>  	 * which doesn't include core id and socket id information.
>  	 */
> -	if (section->size <= size) {
> +	if (ff->size <= ff->offset - start_offset) {

I'm lost here? how is ff->offset incremented? what's 'size' good for now?

thanks,
jirka