linux-kernel - RE: perf test topo broken?

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: <37D7C6CF3E00A74B8858931C1DB2F077019A36D3@SHSMSX103.ccr.corp.intel.com>
Date:	Wed, 25 Nov 2015 15:16:35 +0000
From:	"Liang, Kan" <kan.liang@...el.com>
To:	Jiri Olsa <jolsa@...hat.com>,
	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
CC:	"acme@...hat.com" <acme@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: perf test topo broken?

> 
> On Thu, Nov 19, 2015 at 02:13:53PM -0800, Sukadev Bhattiprolu wrote:
> 
> SNIP
> 
> > Commenting out following code seems to cause the test to pass, but are
> > core_ids in general related to number of cpus online?
> >
> > Sukadev
> >
> > ---
> > diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c index
> > 4383800..d5104da 100644
> > --- a/tools/perf/util/header.c
> > +++ b/tools/perf/util/header.c
> > @@ -1652,11 +1652,14 @@ static int process_cpu_topology(struct
> perf_file_section *section,
> >                 if (ph->needs_swap)
> >                         nr = bswap_32(nr);
> >
> > +#if 0
> >                 if (nr > (u32)cpu_nr) {
> > -                       pr_debug("core_id number is too big."
> > -                                "You may need to upgrade the perf tool.\n");
> > +                       pr_debug("core_id number is too big.  nr %d, cpu_nr %d. "
> > +                                "You may need to upgrade the perf tool.\n",
> > +                                nr, cpu_nr);
> >                         goto free_cpu;
> >                 }
> > +#endif
> >                 ph->env.cpu[i].core_id = nr;
> 
> looks like we can safely remove this check,
> 
> I don't see any place we use core_id as array index or any other place
> assuming core_id < cpu_nr
> 
> Kan Liang?

I assumed that the core_id should be less than max_cpu_number.
But in your case it looks the assumption doesn't work.

I think we can safely remove the check as Jirka suggested.


Thanks,
Kan

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