linux-kernel - Re: [pre-2.6.23 REGRESSION] 2.6.23-rc3-git1 crash/stuck on VIA CN700 system

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:	Wed, 05 Sep 2007 22:24:07 +0300
From:	Stefan Becker <Stefan.Becker@...ia.com>
To:	ext Andi Kleen <andi@...stfloor.org>
CC:	ext Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [pre-2.6.23 REGRESSION] 2.6.23-rc3-git1 crash/stuck on VIA CN700
 system

Hi,

ext Andi Kleen wrote:
>> flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge cmov pat 
>> clflush acpi mmx fxsr sse sse2 tm up pni est tm2 rng rng_en ace ace_en 
> 
> Hmm, I can't really see anything wrong. This means the original
> version of the patch you found had a few problems, but they
> were all fixed later and only applied with CONFIG_PARAVIRT enabled anyways.
> 
> As a stab in the dark since the CPU has clflush can you please 
> comment out the  
> 
>   if (cpu_has_clflush)
>                 asm("clflush (%0) " :: "r" (addr) : "memory");
> 
> statement in arch/i386/kernel/alternative.c and see if it makes a difference?
> Perhaps your CPU doesn't like that (it seems to have clflush) 
> 
> If that doesn't help it might be needed to revert the patch
> hunk by hunk to see which text_poke() invocation caused it.

OK, I reset my working area to the master branch (i.e. 2.6.23-rc5-gitX) 
and then changed text_poke() to read

void __kprobes text_poke(void *addr, unsigned char *opcode, int len)
{
	memcpy(addr, opcode, len);
	sync_core();
	/* Not strictly needed, but can speed CPU recovery up. Ignore cross 
cacheline
	   case. */
#if 0
	if (cpu_has_clflush)
		asm("clflush (%0) " :: "r" (addr) : "memory");
#endif
}

This kernel boots up OK. Looking at the preprocessed C code the 
following code in alternative_instructions() is compiled in:

#ifdef CONFIG_SMP
	if (smp_alt_once) {
		if (1 == num_possible_cpus()) {
			printk(KERN_INFO "SMP alternatives: switching to UP code\n");
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This I still see at bootup

			set_bit(X86_FEATURE_UP, boot_cpu_data.x86_capability);
			set_bit(X86_FEATURE_UP, cpu_data[0].x86_capability);
			alternatives_smp_unlock(__smp_locks, __smp_locks_end,
						_text, _etext);

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this function uses text_poke()
---> BOOM
		}
		free_init_pages("SMP alternatives",
				(unsigned long)__smp_locks,
				(unsigned long)__smp_locks_end);

So what can we do about the clflush on this CPU?

Regards,

	Stefan

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