| 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
| ||
|
Message-ID: <930d61db-6e44-8501-983d-09cd3759d153@arm.com>
Date: Fri, 9 Nov 2018 16:06:29 +0000
From: Marc Zyngier <marc.zyngier@....com>
To: Qian Cai <cai@....us>
Cc: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Jason Cooper <jason@...edaemon.net>
Subject: Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On 09/11/18 15:52, Qian Cai wrote:
>
>
>> On Nov 9, 2018, at 10:38 AM, Marc Zyngier <marc.zyngier@....com> wrote:
>>
>> On 09/11/18 15:28, Qian Cai wrote:
>>>
>>>
>>>> On Nov 9, 2018, at 8:50 AM, Marc Zyngier <marc.zyngier@....com> wrote:
>>>>
>>>> On 09/11/18 12:28, Qian Cai wrote:
>>>>>
>>>>> On 11/9/18 at 7:08 AM, Marc Zyngier wrote:
>>>>>
>>>>>> [+Ard]
>>>>>>
>>>>>> On 08/11/18 20:59, Qian Cai wrote:
>>>>>>> Just booting up the latest git master (b00d209) on an aarch64 server and saw
>>>>>>> this. Not sure about the third warning (at kernel/cpu.c:315
>>>>>>> lockdep_assert_cpus_held+0x50/0x60) relates to irqchip or not, but appended it
>>>>>>> to here anyway just in case.
>>>>>>>
>>>>>>> [ 0.000000] WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c:1696
>>>>>>> its_init+0x588/0xb54
>>>>>>
>>>>>> It looks like EFI cannot manage to reserve the memory for your GIC
>>>>>> redistributors. Pretty annoying. At the same time, you have reported
>>>>>> other issues with the EFI reservation mechanism, such as:
>>>>>>
>>>>>> https://lore.kernel.org/patchwork/patch/1008413/
>>>>>>
>>>>>> for which you have given a "Tested-by:". Is that related?
>>>>> No, I don’t think so. Those warnings are still there even after applied the patch above.
>>>>
>>>> Do you also have this series[1] applied? I'd otherwise need your
>>>> configuration to try and reproduce it, as I can't manage to trigger it
>>>> on my own setup.
>>>>
>>>> Thanks,
>>>>
>>>> M.
>>>>
>>>> [1] https://www.spinics.net/lists/arm-kernel/msg685751.html
>>> After applied the above series on the top of the mainline (b00d209), the only
>>> warning exist is,
>>
>> OK, so the EFI/GICv3 stuff is sorted.
>>
>>>
>>> [ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/cpu.c:315
>>> lockdep_assert_cpus_held+0x50/0x60
>>> [ 0.000000] Modules linked in:
>>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G T 4.20.0-rc1+ #9
>>> [ 0.000000] pstate: 20000085 (nzCv daIf -PAN -UAO)
>>> [ 0.000000] pc : lockdep_assert_cpus_held+0x50/0x60
>>> [ 0.000000] lr : lockdep_assert_cpus_held+0x4c/0x60
>>> [ 0.000000] sp : ffff200009c97b10
>>> [ 0.000000] x29: ffff200009c97b10 x28: ffff200009e39000
>>> [ 0.000000] x27: ffff200009cd1000 x26: ffff200009cd2000
>>> [ 0.000000] x25: ffff200009125000 x24: ffff200009cc9868
>>> [ 0.000000] x23: ffff200009c7c040 x22: 0000000000001000
>>> [ 0.000000] x21: 0000000000000012 x20: ffff200009cc9000
>>> [ 0.000000] x19: ffff200009cd5000 x18: 000000000000003f
>>> [ 0.000000] x17: 0000000000000000 x16: 0000000000000000
>>> [ 0.000000] x15: 0000000000000007 x14: ffff200009461cd4
>>> [ 0.000000] x13: ffff2000094695ac x12: ffff2000095149a4
>>> [ 0.000000] x11: ffff2000094e4478 x10: ffff2000094e0a50
>>> [ 0.000000] x9 : ffff200009516aa8 x8 : ffff0ffbffcc4004
>>> [ 0.000000] x7 : 1fffeffbffcc4003 x6 : ffff0ffbffcc4003
>>> [ 0.000000] x5 : ffff7fdffe62001b x4 : ffff0ffbffcc4004
>>> [ 0.000000] x3 : ffff0ffbffcc4004 x2 : dfff200000000000
>>> [ 0.000000] x1 : 0000000000000000 x0 : 0000000000000000
>>> [ 0.000000] Call trace:
>>> [ 0.000000] lockdep_assert_cpus_held+0x50/0x60
>>> [ 0.000000] static_key_enable_cpuslocked+0x30/0xe8
>>> [ 0.000000] arch_timer_check_ool_workaround+0x128/0x2d0
>>> [ 0.000000] arch_timer_acpi_init+0x274/0x6ac
>>> [ 0.000000] acpi_table_parse+0x1ac/0x218
>>> [ 0.000000] __acpi_probe_device_table+0x164/0x1ec
>>> [ 0.000000] timer_probe+0x1bc/0x254
>>> [ 0.000000] time_init+0x44/0x98
>>> [ 0.000000] start_kernel+0x4ec/0x7d4
>>> [ 0.000000] irq event stamp: 0
>>> [ 0.000000] hardirqs last enabled at (0): [<0000000000000000>] (null)
>>> [ 0.000000] hardirqs last disabled at (0): [<0000000000000000>] (null)
>>> [ 0.000000] softirqs last enabled at (0): [<0000000000000000>] (null)
>>> [ 0.000000] softirqs last disabled at (0): [<0000000000000000>] (null)
>>> [ 0.000000] ---[ end trace 1dc5085680256ac1 ]—
>>
>> Now this one: what machine is this? What is the workaround that gets
>> applied?
>
> # dmidecode
> # dmidecode 3.1
> Getting SMBIOS data from sysfs.
> SMBIOS 3.0.0 present.
> Table at 0x397D0000.
>
> Handle 0x0000, DMI type 0, 24 bytes
> BIOS Information
> Vendor: Huawei
> Version: 1.50
> Release Date: 06/01/2018
> Address: 0xA4800
> Runtime Size: 366 kB
> ROM Size: 8192 kB
> Characteristics:
> PCI is supported
> BIOS is upgradeable
> BIOS shadowing is allowed
> Boot from CD is supported
> Selectable boot is supported
> EDD is supported
> Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
> Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
> 5.25"/360 kB floppy services are supported (int 13h)
> 5.25"/1.2 MB floppy services are supported (int 13h)
> 3.5"/720 kB floppy services are supported (int 13h)
> 3.5"/2.88 MB floppy services are supported (int 13h)
> 8042 keyboard services are supported (int 9h)
> CGA/mono video services are supported (int 10h)
> ACPI is supported
> USB legacy is supported
> BIOS boot specification is supported
> Targeted content distribution is supported
> UEFI is supported
> BIOS Revision: 0.0
>
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> Manufacturer: Huawei
> Product Name: TaiShan 2280
> Version: V100R001C00
> Serial Number: 2102311TBJ10H7000017
> UUID: 8d9f1d7e-639a-11e7-9a0a-a08cf8625acc
> Wake-up Type: Power Switch
> SKU Number: To be filled by O.E.M.
> Family: To be filled by O.E.M.
Great stuff. This is what I know as a D05. I used to have one, but it
dropped of the network and I need to find someone to locate it in the
server room.
>
> I am not sure if I understand your second question, but there is no workaround
> to make this warning disappear that I am aware of.
it is not about having a workaround to disable the warning, but a
workaround that the kernel is applying because the HW is busted:
>>> [ 0.000000] arch_timer_check_ool_workaround+0x128/0x2d0
See bb42ca474010 and d003d029cea8 for details.
Now, activating this workaround leads to lockdep being really angry,
most likely because the cpus_read_lock is not taken, which is a change
in behaviour...
I'm trying to dig into this now.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists