[Xen-devel] PATastic fun

[Stefan Bader <stefan.bader@xxxxxxxxxxxxx>]

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

-Stefan

Attachment: mmap-example.c
Description: Text Data

Attachment: signature.asc
Description: OpenPGP digital signature

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