All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>, jinsong.liu@intel.com
Cc: Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: PATastic fun
Date: Fri, 22 Feb 2013 09:53:16 -0500	[thread overview]
Message-ID: <20130222145316.GB8017@phenom.dumpdata.com> (raw)
In-Reply-To: <51277888.50908@canonical.com>

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:
> 
> [ 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
> 3.8.0-6-generic #13-Ubuntu
> [ 6824.453926] Call Trace:
> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
> [ 6824.454027]  [<ffffffff81056d9f>] copy_process.part.22+0xa5f/0x1510
> [ 6824.454038]  [<ffffffff81057931>] do_fork+0x91/0x350
> [ 6824.454048]  [<ffffffff81057c76>] sys_clone+0x16/0x20
> [ 6824.454060]  [<ffffffff816ccbf9>] stub_clone+0x69/0x90
> [ 6824.454069]  [<ffffffff816cc89d>] ? 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 <konrad.wilk@oracle.com>
> 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
> 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 supported
> 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.

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?

> 
> -Stefan

> #include <stdio.h>
> #include <stdlib.h>
> #include <stdint.h>
> #include <stdbool.h>
> #include <unistd.h>
> #include <sys/mman.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <fcntl.h>
> 
> 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 = false;
> 
> 	while ((opt = getopt(argc, argv, "f")) != -1) {
> 		switch (opt) {
> 		case 'f':
> 			opt_fork = true;
> 			break;
> 		}
> 	}
> 
> 	if (argc <= 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) != 1) {
> 		fprintf(stderr, "Cannot determine mmap address from %s\n", argv[optind]);
> 		exit(EXIT_FAILURE);
> 	}
> 
> 	if ((fd = 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 = mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd, (off_t)offset)) == MAP_FAILED) {
> 		fprintf(stderr, "Cannot mmap 0x%llx\n", offset);
> 		exit(EXIT_FAILURE);
> 	}
> 
> 	close(fd);
> 
> 	if (opt_fork) {
> 		pid = fork();
> 		if (pid == 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);
> }
> 




> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

  reply	other threads:[~2013-02-22 14:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-22 13:54 PATastic fun Stefan Bader
2013-02-22 14:53 ` Konrad Rzeszutek Wilk [this message]
2013-02-25  3:15   ` Liu, Jinsong
2013-02-25  9:10     ` Stefan Bader
2013-02-26 15:32       ` Stefan Bader
2013-02-26 17:03         ` Konrad Rzeszutek Wilk
2013-02-26 17:11           ` Stefan Bader
2013-02-26 17:43             ` Konrad Rzeszutek Wilk
2013-02-26 17:53               ` Konrad Rzeszutek Wilk
2013-02-26 17:56                 ` Stefan Bader

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130222145316.GB8017@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=colin.king@canonical.com \
    --cc=jinsong.liu@intel.com \
    --cc=stefan.bader@canonical.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.