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 12:44:45 +0000
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Stefano Stabellini <Stefano.Stabellini@...citrix.com>
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>,
	Yinghai Lu <yinghai@...nel.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: [GIT PULL tip/x86/mm] xen/x86 fixes

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