From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: PATastic fun Date: Mon, 25 Feb 2013 10:10:20 +0100 Message-ID: <512B2A7C.1050906@canonical.com> References: <51277888.50908@canonical.com> <20130222145316.GB8017@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5205586490444852222==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Liu, Jinsong" Cc: Colin Ian King , "xen-devel@lists.xensource.com" , Sander Eikelenboom , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============5205586490444852222== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig97FCB6AB750103D9194CF12B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig97FCB6AB750103D9194CF12B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 25.02.2013 04:15, Liu, Jinsong wrote: > Konrad Rzeszutek Wilk wrote: >> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote: >>> Hi Konrad, >> >> Hey Stefan, >>> >>> here is another one from the hm-what? department: >> >> Heh - the really good-bug-hunting one. Lets also include Jinsong as >> he has been tracking a similar one with mcelog. >>> >>> Colin discovered that running the attached program with the fork >>> active (e.g. "./mmap-example -f 0x10000", the address can be that or >>> iomem) this triggers the following weird messages:=20 >>> >>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type >>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus >>> [ 6824.453776] ------------[ cut here ]------------ >>> [ 6824.453796] WARNING: at >>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774 >>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm: >>> mmap-example Tainted: GF=20 >>> 3.8.0-6-generic #13-Ubuntu >>> [ 6824.453926] Call Trace: >>> [ 6824.453944] [] warn_slowpath_common+0x7f/0xc0 >>> [ 6824.453954] [] warn_slowpath_null+0x1a/0x20 >>> [ 6824.453963] [] untrack_pfn+0xb8/0xd0 >>> [ 6824.453975] [] unmap_single_vma+0xac/0x100 >>> [ 6824.453985] [] unmap_vmas+0x49/0x90 >>> [ 6824.453995] [] exit_mmap+0x98/0x170 >>> [ 6824.454007] [] mmput+0x64/0x100 >>> [ 6824.454017] [] dup_mm+0x445/0x660 >>> [ 6824.454027] [] >>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038]=20 >>> [] do_fork+0x91/0x350 [ 6824.454048]=20 >>> [] sys_clone+0x16/0x20 [ 6824.454060]=20 >>> [] stub_clone+0x69/0x90 [ 6824.454069]=20 >>> [] ? system_call_fastpath+0x1a/0x1f [ 6824.454076] >>> ---[ end trace 4918cdd0a4c9fea4 ]---=20 >>> >>> I found that this is related to your bandaid patch >>> >>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1 >>> Author: Konrad Rzeszutek Wilk >>> Date: Fri Feb 10 09:16:27 2012 -0500 >>> >>> xen/pat: Disable PAT support for now. >>> >>> I just do not understand how this happens. From the trace it seems >>> the fork=20 >>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So >>> maybe the=20 >>> warning is just related to this. So primarily the question is how on >>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are >>> cleared from the supported=20 >>> mask by the patch, so somehow I would think nothing should be able >>> to set it...=20 >>> But apparently not so. >>> Not sure it is a big deal since I never saw this in normal operation >>> and it=20 >>> seems to be ok when unapping before doing the fork. It is just plain >>> odd.=20 >> >> Jinsong mentioned that there is some oddity with the MTRR. Somehow the= >> ranges are swapped or not correct. Jinsong, could you shed some light >> on what you have found so far? >> >=20 > Yes, Sander once also reported a similar weird warning when start mcelo= g daemon, as attached. >=20 > Basically, it occurs when mcelog user daemon start,=20 > do_fork > --> copy_process > --> dup_mm > --> dup_mmap > --> copy_page_range > --> track_pfn_copy > --> reserve_pfn_range > --> line 624: flags !=3D want_flags > It comes from different memory types of page table (_PAGE_CACHE_WB) and= mtrr (_PAGE_CACHE_UC_MINUS). >=20 > However, why it get different memory types from page table and mtrr is = still unclear, reproducing the bug is difficult and unstable. >=20 > Thanks, Ok, so this seems to take the same code paths. As for the test program, i= t fails on duplicating some mmap on a fork. The test program does this all the ti= me (except the backtrace warning which is warn_once). So you say, the UC- comes from the MTRR side... Hm, have to look at that.= Thanks, Stefan --------------enig97FCB6AB750103D9194CF12B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCgAGBQJRKyp8AAoJEOhnXe7L7s6jxLwP/3AefCujtswFgxqD4C2HG1ww dkp2oIJBe+Cu40HzIGRD2XJgBQ/BRXBp5JnJ5uBQr3YnbywHj/5nYzGM5SJBeqxf 2xqhASFz9Kkbe/ZGQf/7Yasj+8Q1x4/JS0CzswG0Ad0AFMubG37a4bGyFBNzz1Xn n2UPGGDxrhEwSisDbJ6gXl448lkkdrkvhfmrbGmJM41G9VYpVb4jaDpf1SiY8/h5 KefjUSX7bfsDSixs6Be7G5clUufCSOCXCAL/cOkAj9Ww/KpSjZmOqljKITeEi9Jv xnCJn+c6qFsKGx2nwnF4NoHhqYw0nvKTPrJOQmu3CZpaX69H/37foIpawcS1hNta uzGJh8iUyS8IxMpYAg2pQ/dtqNbf2gK9gfe1mlPgYR64ix5XjkVukjQ0HuHUQX27 PFjOZfoRUvELIbk0wcwrObk9pylhGTYzdPWNAZj/FIK1gGYEGQ3nqyMZoLeCyssa umqoGvHPrLi9kwsdS5bHLqbOxN5N8RsrzNjpxuYBc2G7kdrS2g+wySOE1dPT3Cck kX+JkmFI7zHIpFh4S+gxoj9RrOL/8jX+9QOTWPU6bUQ7d01NbJXXUGQO0Qr9aWms /lTMdLRBfDmCyBEiQZ4E6EwbL+VP/7+gcs0YEUG5oiHa9N4KxA3e76H95f83i+OY ED0WY48/5DlVaMv05qdT =FKX3 -----END PGP SIGNATURE----- --------------enig97FCB6AB750103D9194CF12B-- --===============5205586490444852222== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5205586490444852222==--