linux-kernel - Re: linux-next: Crash in arm_pmu_device_probe() due to 'drivers/perf: arm

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]

Date:	Mon, 21 Mar 2016 08:02:43 +0100
From:	Dirk Behme <dirk.behme@...bosch.com>
To:	Guenter Roeck <private@...ck-us.net>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	Will Deacon <will.deacon@....com>
Subject: Re: linux-next: Crash in arm_pmu_device_probe() due to 'drivers/perf:
 arm_pmu: make info messages more verbose'

On 18.03.2016 14:30, Guenter Roeck wrote:
> Hi Dirk,
>
> On 03/18/2016 02:18 AM, Dirk Behme wrote:
>> Hi Guenter,
>>
>> On 18.03.2016 07:44, Guenter Roeck wrote:
>>> Hi,
>>>
>>> I am seeing the attached crash when running a realview-pb-a8 image with
>>> realview_defconfig in qemu.
>>> bisect wasn't successful, but a commit analysis identified commit
>>> 'drivers/perf: arm_pmu: make info
>>> messages more verbose' as the culprit. Reverting this commit fixes the
>>> problem.
>>>
>>> The code roughly looks as follows.
>>>
>>> int arm_pmu_device_probe()
>>> {
>>>      ...
>>>      if (node && ..) {
>>>      } else {
>>>      }
>>>
>>>      if (ret) {
>>>                  pr_info("%s: failed to probe PMU! Error %i\n",
>>>                          node->full_name, ret);
>>>                  goto out_free;
>>>      }
>>>      ....
>>> out_free:
>>>      pr_info("%s: failed to register PMU devices! Error %i\n",
>>>                  node->full_name, ret);
>>>      ....
>>> }
>>>
>>> Note that 'node' is dereferenced even though it was previously checked
>>> if it is NULL.
>>> The configuration I am testing does not use devicetree.
>>>
>>> Can you use dev_info() instead ?
>>
>>
>> Does anything like below [1] does work for you?
>>
>> If so, could you please share the output? I.e. what it prints in your
>> non-devicetree non-pmu case?
>>
> This is what I get:
>
> hw perfevents: probing PMU on CPU 0
> armv7-pmu armv7-pmu: failed to probe PMU! Error -6
> armv7-pmu armv7-pmu: failed to register PMU devices! Error -6
>
> Another option might be to use of_node_full_name() (or even better
> both dev_info() and of_node_full_name()).
>
> Not sure though what you are looking for. '/soc/pmu_a53' doesn't
> tell (me) much either, and I am not sure I understand the context
> of the bug description. Why would the kernel try to initialize PMU
> for a CPU which isn't online ?


I have a device tree based ARMv8 Cortex A57 / Cortex A53 based system. 
The Cortex A57 are always starting fine, but based on some firmware 
issues the Cortex A53 are sometimes online, sometimes not. But enabling 
the PMUs is always in the device tree, which fails some times then, too.

With the initial non-verbose PMU error messages I needed some time to 
find out that the error messages were due to the Cortex A53 not being 
online. And I thought it would help to debug similar cases to make this 
more verbose.

Best regards

Dirk