|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] PATastic fun
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:
>>
>> [ 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?
>
Yes, Sander once also reported a similar weird warning when start mcelog
daemon, as attached.
Basically, it occurs when mcelog user daemon start,
do_fork
--> copy_process
--> dup_mm
--> dup_mmap
--> copy_page_range
--> track_pfn_copy
--> reserve_pfn_range
--> line 624: flags != want_flags
It comes from different memory types of page table (_PAGE_CACHE_WB) and mtrr
(_PAGE_CACHE_UC_MINUS).
However, why it get different memory types from page table and mtrr is still
unclear, reproducing the bug is difficult and unstable.
Thanks,
Jinsong
>>
>> -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
--- Begin Message --- _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |