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] [day] [month] [year] [list]
Date:	Mon, 21 Jan 2008 11:00:34 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Andi Kleen <andi@...stfloor.org>
CC:	mingo@...e.hu, tglx@...utronix.de, linux-kernel@...r.kernel.org,
	venkatesh.pallipadi@...el.com
Subject: Re: [PATCH] Fix early_ioremap on x86-64 II

Andi Kleen wrote:
>> This patch changes all flushes in init_64.c to be __flush_tlb_all()
>> and fixes the problem here.
>>     
>
> Hmm, I see new early crashes with that patch here in some cases unfortunately:
>
> PANIC: early exception 06 rip 10:ffffffff8082df2d error 0 cr2 0
> Pid: 0, comm: swapper Not tainted 2.6.24-rc8-g7ada4254 #39
>
> Call Trace:
>  [<ffffffff8082df2d>] free_bootmem_core+0x1a/0x6b
>  [<ffffffff8082f143>] free_bootmem_with_active_regions+0x51/0x67
>  [<ffffffff8082a0f3>] setup_node_bootmem+0x16b/0x1b3
>  [<ffffffff8082b3a4>] acpi_scan_nodes+0x136/0x230
>  [<ffffffff8082a6bb>] numa_initmem_init+0x331/0x459
>  [<ffffffff80234ef6>] release_console_sem+0x1b4/0x1cd
>  [<ffffffff80234ef6>] release_console_sem+0x1b4/0x1cd
>  [<ffffffff80355726>] number+0x10e/0x1f9
>  [<ffffffff802354d8>] printk+0x4e/0x56
>  [<ffffffff80355726>] number+0x10e/0x1f9
>  [<ffffffff803563f8>] vsnprintf+0x53f/0x583
>  [<ffffffff80355726>] number+0x10e/0x1f9
>  [<ffffffff80234ef6>] release_console_sem+0x1b4/0x1cd
>  [<ffffffff803563f8>] vsnprintf+0x53f/0x583
>  [<ffffffff8022468a>] early_serial_write+0x22/0x32
>
> Not sure what's going wrong. I think the patch is correct, but there
> are probably more bugs around triggered by some change. Perhaps it is 
> better to just revert Jeremy's patch (789bad4ca2b604f2f21ae7e3d64b67325ec8f9bb) for now.
>   

It's a purely "make things prettier" patch, so I have no problem with 
that.   If the non-global flags used in early 64-bit pagetables is very 
deeply ingrained, I wonder if its worth making a separate set of 
explicitly non-global _PAGE_KERNEL flags for its use, so that at least 
_PAGE_KERNEL* is consistent between 32 and 64 bits.  Otherwise its going 
to be the sort of difference which gets increasingly awkward as things 
get unified (I guess its mitigated by the fact that 32-bit code can 
never assume that global mappings are available and present).

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