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: <20100323113551.GA3862@dhcp-lab-161.englab.brq.redhat.com>
Date:	Tue, 23 Mar 2010 12:35:52 +0100
From:	Stanislaw Gruszka <sgruszka@...hat.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	Dave Airlie <airlied@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>
Subject: Re: Can not boot with CONFIG_NO_BOOTMEM=y on i686

On Sat, Mar 20, 2010 at 11:26:06AM -0700, Yinghai Lu wrote:
> > After update to 2.6.34-rc1, I was experimented by strange oopses during
> > boot, what looked like memory corruption. Bisection shows that first bad
> > commit is 59be5a8e8ce765cf739ec7f07176219972de7481 ("x86: Make 32bit
> > support NO_BOOTMEM"). When I disable CONFIG_NO_BOOTMEM I'm able to start
> > system. Not sure what info is need to track down this issue, so please
> > let me know.
> 
> can you check patch
> 
> https://patchwork.kernel.org/patch/87081/

Patch helps somehow. Instead of many random oopses, now I have one and
the same oops, here is photo:
http://people.redhat.com/sgruszka/20100322_001.jpg

Oops is in pcpu_alloc+0x1aa, in code this is 

(gdb) l *(pcpu_alloc +0x1aa)
0xc04c2272 is in prefetch (/mnt/rhel5/usr/src/kernels/linux-2.6-debuginfo/arch/x86/include/asm/processor.h:886).
881	 * It's not worth to care about 3dnow prefetches for the K6
882	 * because they are microcoded there and very slow.
883	 */
884	static inline void prefetch(const void *x)
885	{
886		alternative_input(BASE_PREFETCH,
887				  "prefetchnta (%1)",
888				  X86_FEATURE_XMM,
889				  "r" (x));
890	}
(gdb) l *(pcpu_alloc +0x1a0)
0xc04c2268 is in pcpu_alloc (mm/percpu.c:1137).
1132					 */
1133					goto restart;
1134				}
1135	
1136				off = pcpu_alloc_area(chunk, size, align);
1137				if (off >= 0)
1138					goto area_found;
1139			}
1140		}
1141	
(gdb) l *(pcpu_alloc +0x1b0)
0xc04c2278 is in pcpu_alloc (mm/percpu.c:1116).
1111		}
1112	
1113	restart:
1114		/* search through normal chunks */
1115		for (slot = pcpu_size_to_slot(size); slot < pcpu_nr_slots; slot++) {
1116			list_for_each_entry(chunk, &pcpu_slot[slot], list) {
1117				if (size > chunk->contig_hint)
1118					continue;
1119	
1120				new_alloc = pcpu_need_to_extend(chunk);

So seems pcpu_slot[slot] is somehow corrupted. Looking further give
pcpu_slot is allocated by:

pcpu_slot = alloc_bootmem(pcpu_nr_slots * sizeof(pcpu_slot[0]));

So still we have some problem with CONFIG_NO_BOOTMEM on 32 bits.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ