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:   Wed, 11 Oct 2017 14:26:27 +0530
From:   Anju T Sudhakar <anju@...ux.vnet.ibm.com>
To:     Stewart Smith <stewart@...ux.vnet.ibm.com>,
        Michael Ellerman <mpe@...erman.id.au>
Cc:     linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        maddy@...ux.vnet.ibm.com, hemant@...ux.vnet.ibm.com
Subject: Re: [PATCH] powerpc/powernv: Add kernel cmdline parameter to disable
 imc

Hi mpe, stewart,


On Wednesday 11 October 2017 01:55 AM, Stewart Smith wrote:
> Michael Ellerman <mpe@...erman.id.au> writes:
>> Anju T Sudhakar <anju@...ux.vnet.ibm.com> writes:
>>
>>> Add a kernel command line parameter option to disable In-Memory Collection
>>> (IMC) counters and add documentation. This helps in debug.
>> I'd really rather we didn't. Do we *really* need this?
>>
>> We don't have command line parameters to disable any of the other ~20
>> PMUs, why is this one special?

This one is really helpful in debugging, incase if we want to proceed 
without nest counters  OR
core counters . But if we have the facility to do the same from 
petitboot, its fine.

> You could also do the same thing by editing the device tree before
> booting your kernel, we do have the facility to do that in petitboot.
>
> A recent firmware patch: https://patchwork.ozlabs.org/patch/823249/
> would fix the firmware implementation where the counters were already
> running before the INIT/START calls, which are likely the cause of the
> problems that this patch is trying to work around.
>
> I propose we have the firmware do the right thing and nothing special in
> kernel. i.e. not to merge this.
>

Agreed.



Thanks,
Anju

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ