From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: PATastic fun Date: Fri, 22 Feb 2013 14:54:16 +0100 Message-ID: <51277888.50908@canonical.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8724829359746806098==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Cc: Colin Ian King List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============8724829359746806098== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig7522780D77765EAEDB8A3A8D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7522780D77765EAEDB8A3A8D Content-Type: multipart/mixed; boundary="------------030502040503010602030802" This is a multi-part message in MIME format. --------------030502040503010602030802 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Konrad, here is another one from the hm-what? department: 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 trigg= ers the following weird messages: [ 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:77= 4 untrack_pfn+0xb8/0xd0() =2E.. [ 6824.453920] Pid: 3481, comm: mmap-example Tainted: GF 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] [] do_fork+0x91/0x350 [ 6824.454048] [] sys_clone+0x16/0x20 [ 6824.454060] [] stub_clone+0x69/0x90 [ 6824.454069] [] ? system_call_fastpath+0x1a/0x1f [ 6824.454076] ---[ end trace 4918cdd0a4c9fea4 ]--- 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 fo= rk fails when duplicating the VMAs (dup_mm calls mmput on failure). So maybe= the 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 sup= ported mask by the patch, so somehow I would think nothing should be able to set= it... But apparently not so. Not sure it is a big deal since I never saw this in normal operation and = it seems to be ok when unapping before doing the fork. It is just plain odd.= -Stefan --------------030502040503010602030802 Content-Type: text/x-csrc; name="mmap-example.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mmap-example.c" #include #include #include #include #include #include #include #include #include #include #include int main(int argc, char **argv) { uint8_t *data; int fd; unsigned long long offset; pid_t pid; int status; int opt; bool opt_fork =3D false; while ((opt =3D getopt(argc, argv, "f")) !=3D -1) { switch (opt) { case 'f': opt_fork =3D true; break; } } if (argc <=3D optind) { fprintf(stderr, "%s: [-f] address\n", argv[0]); fprintf(stderr, "\t-f specifices if we should fork with the mmap\n"); exit(EXIT_FAILURE); } if (sscanf(argv[optind], "%lli", &offset) !=3D 1) { fprintf(stderr, "Cannot determine mmap address from %s\n", argv[optind]= ); exit(EXIT_FAILURE); } if ((fd =3D open("/dev/mem", O_RDONLY)) < 0) { fprintf(stderr, "Cannot open /dev/mem\n"); exit(EXIT_FAILURE); } printf("mmap: 0x%llx..0x%llx\n", offset, offset + 4095); if ((data =3D mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd, (off_t)offset= )) =3D=3D MAP_FAILED) { fprintf(stderr, "Cannot mmap 0x%llx\n", offset); exit(EXIT_FAILURE); } close(fd); if (opt_fork) { pid =3D fork(); if (pid =3D=3D 0) { /* child */ _exit(0); } else { /* parent */ waitpid(pid, &status, 0); } } if (munmap(data, 4096) < 0) { fprintf(stderr, "Cannot munmap %p\n", data); exit(EXIT_FAILURE); } exit(EXIT_SUCCESS); } --------------030502040503010602030802-- --------------enig7522780D77765EAEDB8A3A8D 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/ iQIcBAEBCgAGBQJRJ3iJAAoJEOhnXe7L7s6jPw4QAOetxY2qfwACXWGpfDaErHiG NHUJ1/IL0eNJ6mOd23bNHUKvWYIosiDM3Ujasz3mA82qCrrUqYM/WGPvGUjTDPMI 4zsK5Kasr8auwZiJALWLhB33nemJN5y/IFqHHiDRPLD2kZNMgXP0oztWUL1yMFMN BPfCYeMC5mT4z7PjcOu9bBQbTkgzqJJGtJRP805IJ2AdQB0G/o4NJPaTr8RrHtSj 9TPSr1oKwQABvUnRIjTLMyGVaD7lh58eQ/UVtzY17LYnhtydqypsgOnn7+TpvYIn arGUffVICP3OeyJilwVeFKL4ZnqKJ0dPI/cVNDv0kmWqRcE2O4H1knEOMG3t75AN b+BQP/Z8qSZBPF+Z3DF3mwh8pcQnbiSKxgSTB36ozXn3G2yqMzPs8gzfuBiNZMXg BtVz00fw+ZTy30ymZ6T3zKa9hMPc3r6Rhwmung5qfQuHOx3JrajZrKi+12f8P0dT BPBIcLtnRjjkyPnd2F7CidhiIGi1NC87TBwPbyTxA+lzPV3A709eOr7yegfFizD0 HI+omSTCtjEYRsJ+UW60gxfFH/eUd31TIHT2LbL4tbDFuU6+5+7k0ae1D1CgwFxw Mn+x+x7s4ub3NhJOyZvWwuc640Yi3ive4i/S75ETtsPTjeB2ozOclH4tmGEPIxo4 HYknnUhNEmL+b7HBCTbA =IIIv -----END PGP SIGNATURE----- --------------enig7522780D77765EAEDB8A3A8D-- --===============8724829359746806098== 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 --===============8724829359746806098==--