[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PATastic fun



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@xxxxxxxxxx>
> 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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.