linux-kernel - Re: latest -git: WARNING: at arch/x86/kernel/ipi.c:123 send_IPI_mask

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:	Sun, 24 Aug 2008 11:20:52 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"H. Peter Anvin" <hpa@...nel.org>
Cc:	"Dave Jones" <davej@...hat.com>,
	"Andi Kleen" <andi@...stfloor.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Rusty Russell" <rusty@...tcorp.com.au>
Subject: Re: latest -git: WARNING: at arch/x86/kernel/ipi.c:123 send_IPI_mask_bitmask+0xc3/0xe0()

On Fri, Aug 22, 2008 at 4:13 AM, H. Peter Anvin <hpa@...nel.org> wrote:
> It seems to be that doing it in smp_call_function_single() would be more
> correct as it's already protected by get_cpu()..put_cpu() and a cpu_online()
> test in there should not be expensive in comparison to the whole rest of the
> code.
>
> You may want to see if this patch fixes the problem; it does *NOT* have the
> correct error behaviour (some of the intervening layers don't propagate
> errors), but it should make the fault go away.

Hm.

Kernel fails to detect cpu1 at all.

I am currently unsure of whether it's your patch or not. But it's the
same config that I've been booting for ages (and I copy it over for
each new kernel version I check out).

Processor #0 (Bootup-CPU)
I/O APIC #2 Version 32 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 1
SMP: Allowing 1 CPUs, 0 hotplug CPUs
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Allocating PCI resources starting at 50000000 (gap: 40000000:bee00000)
PERCPU: Allocating 1221764 bytes of per cpu data
NR_CPUS: 7, nr_cpu_ids: 1, nr_node_ids 1

I really don't get it. Is this something that can be caused by your
patch _at all_ ?

Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
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/