PATastic fun

[Stefan Bader <stefan.bader@canonical.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2352 bytes --]

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 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.

-Stefan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: mmap-example.c --]
[-- Type: text/x-csrc; name="mmap-example.c", Size: 1517 bytes --]

#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);
}


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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