linux-kernel - Re: [PATCH 1/2] tracing/ftrace: don't trace on early stage of secondary cpu boot

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]

Message-ID: <alpine.DEB.1.10.0812232201110.20511@gandalf.stny.rr.com>
Date:	Tue, 23 Dec 2008 22:09:53 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Frédéric Weisbecker <fweisbec@...il.com>
cc:	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] tracing/ftrace: don't trace on early stage of
 secondary cpu boot


On Wed, 24 Dec 2008, Fr?d?ric Weisbecker wrote:
> >>       /*
> >> @@ -1233,7 +1233,7 @@ int trace_graph_entry(struct ftrace_graph_ent *trace)
> >>       int cpu;
> >>       int pc;
> >>
> >> -     if (!ftrace_trace_task(current))
> >> +     if (!ftrace_trace_task(current) || ftrace_in_early_cpuinit())
> >>               return 0;
> >
> > Actually, didn't you say current is not available either? We are testing
> > current first.
> 
> Oops. Strange, my tests didn't give me any problem.
> I will fix it.

Are you sure 'current' is dangerous? Perhaps we do not need to worry here, 
since we are testing current against something else, and if the CPU
is just coming on line, it will not be the task we want.

> 
> 
> > I still wonder if there's a better way to find out if it is safe to run.
> > Perhaps the arch code can test the %gs register to see if it is actually
> > something valid?
> >
> > -- Steve
> 
> I could test if MSR_GS_BASE references cpu_pda(cpu) but that remains
> as much heavy...

Perhaps just reading the %gs register and see if it faults would be good 
enough?

	long dummy;
	int faulted=0;

	    asm(
		"1:	movq %%gs:0, %0\n"
		"2:
		".section .fixup \"ax\"\n"
		"3:	movl $1, %1\n"
		"	jmp 2b\n"
		".previous"
		_ASM_EXTABLE(1b, 3b)
		: "=r"(dummy), "=r"(faulted)
		: "1"(faulted));


Would this work?  On the good cases, all we do is a read of the %gs 
section, which is the same as doing a smp_process_id(). On the bad case, 
we fault, but we also catch that fact. We are more interested in the good 
case being fast. but I'm not sure how well the start up code could take a 
fault, even when it is expected.

-- Steve

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