linux-kernel - Re: [PATCH][RFC] Add default CPU topology information

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, 18 Apr 2008 00:32:17 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Ben Hutchings <bhutchings@...arflare.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH][RFC] Add default CPU topology information

On Fri, 18 Apr 2008 00:10:24 -0700 Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Mon, 31 Mar 2008 12:44:13 +0100 Ben Hutchings <bhutchings@...arflare.com> wrote:
> 
> > Not all architectures and configurations define CPU topology information.
> > This can result in an empty topology directory in sysfs, and requires
> > in-kernel users to protect all uses with #ifdef - see
> > <http://marc.info/?l=linux-netdev&m=120639033904472&w=2>.
> > 
> > The documentation of CPU topology specifies what the defaults should be
> > if only partial information is available from the hardware.  So we can
> > provide these defaults as a fallback.
> > 
> > This patch:
> > 
> > - Adds default definitions of the 4 topology macros to
> >   include/asm-generic/topology.h.
> > - Changes include/asm-*/topology.h to include <asm-generic/topology.h>
> >   unconditionally.
> > - Changes drivers/base/topology.c to use the topology macros unconditionally
> >   and to cope with definitions that aren't lvalues.
> > - Updates documentation accordingly.
> 
> I get a huuuuuuuge crash early in boot on the t61p dual x86_64 laptop. 
> Before netconsole has started and it has no serial port, so all I have is a
> partially-scrolled-off jpg, sorry.
> 
> I'll drop the patch.
> 
> http://userweb.kernel.org/~akpm/p4175278.jpg
> http://userweb.kernel.org/~akpm/config-t61p.txt
> http://userweb.kernel.org/~akpm/dmesg-t61p.txt
> 
> 
> If I didn't have all that wrong crap on the stack we'd have a full
> trace here.  I have CONFIG_FRAME_POINTER=y, but that doesn't seem to
> have helped.
> 

ooh, I just discovered kstack=.  That should be hoisted up to core kernel
then pushed out to other architectures, not hidden in x86_64 code.

But first I guess it should be make to work - it fails miserably, because
only one of our seventy fix stack-dumping functions actually looks at it.


This:

--- a/arch/x86/kernel/traps_64.c~a
+++ a/arch/x86/kernel/traps_64.c
@@ -426,7 +426,7 @@ _show_stack(struct task_struct *tsk, str
 		printk(" %016lx", *stack++);
 		touch_nmi_watchdog();
 	}
-	show_trace(tsk, regs, sp, bp);
+//	show_trace(tsk, regs, sp, bp);
 }
 
 void show_stack(struct task_struct *tsk, unsigned long * sp)


works heaps better.

Here's the rest of your oops: http://userweb.kernel.org/~akpm/p4175279.jpg

I'd be suspecting startup ordering problems - maybe the page allocator
isn't ready yet.

otoh, it _should_ be ready by the time we run init_sched_domains().

--
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/