linux-kernel - Re: [GIT PULL tip/x86/mm] xen/x86 fixes

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:	Thu, 17 Mar 2011 10:25:10 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Ingo Molnar <mingo@...e.hu>
CC:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: [GIT PULL tip/x86/mm] xen/x86 fixes

On 03/17/2011 05:44 AM, Stefano Stabellini wrote:
> On Wed, 16 Mar 2011, Stefano Stabellini wrote:
>> On Fri, 11 Mar 2011, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Mar 11, 2011 at 01:17:23PM +0000, Stefano Stabellini wrote:
>>>> Hello,
>>>> recently we had a couple of long discussions with Yinghai about boot
>>>> crashes on xen, related to pagetable initialization.
>>>> As a result we came up with three patches, two of them fix the first [1]
>>>> boot crash and provide a nice cleanup on native:
>>>
>>> I don't know why this is happening now, but it could be very well
>>> related to the build config. Smaller builds don't seem to encounter this, while
>>> this is a distro type build. If I use:
>>>
>>>> Stefano Stabellini (1):
>>>>        xen: set max_pfn_mapped to the last pfn mapped
>>>
>>> it hangs during bootup. The machine hangs during the box (no keyboard interaction)
>>> and I can see this in the bootup.
>>
>> Konrad sent me few other logs offline: log1 is the log of the hang and
>> log2 is a successful boot (reverting the problematic patch).
>> It looks like the SP5100 TCO WatchDog Timer Driver is using ioremap on
>> an address (0xb8fe00) that belongs to the memory range used for the
>> pagetable (0x9fc000-0xf43fff).
>> In the succesful case max_pfn_mapped is higher so the pagetable is
>> located at an higher address (0x16dfb000-0x17342fff) so the problem
>> doesn't occur.
>>
>> I still have few unaswered questions on this issue: if we assume that
>> the ioremap address is the same in the two cases (0xb8fe00), how is it
>> possible that in the first case it is ram (page_is_ram returns true)
>> while in the second case it is not (otherwise we would still get a
>> warning from ioremap): page_is_ram shouldn't be affected by the position
>> of the kernel pagetable, and the e820 is still the same.
>> In any case if 0xb8fe00 is really an MMIO address memblock_find_in_range
>> shouldn't have returned the range (0x9fc000-0xf43fff) in
>> find_early_table_space.
>>
>
> The issue is due to a bug in the TCO driver and has been fixed thanks
> to Yinghai.
>
>
> Peter, can I add your ack to "Cleanup highmap after brk is concluded" by
> Yinghai?
>
> Should I send another git pull request for tip even though the two
> patches on linux-tip that this series was depending on have gone
> upstream?
>
> x86-64: Move out cleanup higmap [_brk_end, _end) out of init_memory_mapping()
> x86-64, mm: Put early page table high
>
> Should I send the git pull request to Linus instead?

can you please resend the pull request to Ingo and HPA?

better to make those patches go through tip and pass Ingo's test matrix.

Thanks

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