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, 4 May 2018 14:56:01 +0200
From:   Ralf Baechle <ralf@...ux-mips.org>
To:     Robert Richter <rric@...nel.org>
Cc:     Matt Redfearn <matt.redfearn@...s.com>,
        James Hogan <jhogan@...nel.org>, linux-mips@...ux-mips.org,
        Huacai Chen <chenhc@...ote.com>, linux-kernel@...r.kernel.org,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        oprofile-list@...ts.sf.net
Subject: Re: [RFC PATCH] MIPS: Oprofile: Drop support

On Fri, May 04, 2018 at 02:27:51PM +0200, Robert Richter wrote:

> On 04.05.18 12:03:12, Matt Redfearn wrote:
> > >As said, oprofile version 0.9.x is still available for cpus that do
> > >not support perf. What is the breakage?
> > 
> > The breakage I originally set out to fix was the MT support in perf.
> > https://www.linux-mips.org/archives/linux-mips/2018-04/msg00259.html
> > 
> > Since the perf code shares so much copied code from oprofile, those same
> > issues exist in oprofile and ought to be addressed. But as newer oprofile
> > userspace does not use the (MIPS) kernel oprofile code, then we could,
> > perhaps, just remove it (as per the RFC). That would break legacy tools
> > (0.9.x) though...
> 
> Those support perf:
> 
>  (CPU_MIPS32 || CPU_MIPS64 || CPU_R10000 || CPU_SB1 || CPU_CAVIUM_OCTEON || CPU_XLP || CPU_LOONGSON3)
> 
> Here is the total list of CPU_*:
> 
>  $ git grep -h config.CPU_ arch/mips/ | sort -u | wc -l
>  79
> 
> The comparisation might not be accurate, but at least gives a hint
> that there are many cpus not supporting perf. You would drop profiling
> support at al to them.

The grep results are a bit missleading.  We have many symbols such as
CPU_MIPS32_R1 which describe a particular architecture revision supported
by a CPU.  Others CPU_* symbols are describing particular features or
options so in reality there are far fewer CPU to be supported.  Also
many of the older processors or embedded cores don't have performance
counters at all; for yet other cores presence, number and a few other
details can be configured when synthesizing the RTL so relying on the
CONFIG_* alone won't help.

> If it is too hard to also fix the oprofile code (code duplication
> seems the main issue here), then it would be also ok to blacklist
> newer cpus to enable oprofile kernel code (where it is broken).

  Ralf

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ