* [linux-linus bisection] complete test-arm64-arm64-xl-xsm @ 2019-03-11 23:52 osstest service owner 2019-03-12 15:59 ` Julien Grall 0 siblings, 1 reply; 38+ messages in thread From: osstest service owner @ 2019-03-11 23:52 UTC (permalink / raw) To: xen-devel, osstest-admin branch xen-unstable xenbranch xen-unstable job test-arm64-arm64-xl-xsm testid guest-start Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: 0ee930e6cafa048c1925893d0ca89918b2814f2c Bug not present: 2d432cb7091e99881af803cdd67a31969b863005 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/133723/ commit 0ee930e6cafa048c1925893d0ca89918b2814f2c Author: Matthew Wilcox <willy@infradead.org> Date: Tue Mar 5 15:46:06 2019 -0800 mm/memory.c: prevent mapping typed pages to userspace Pages which use page_type must never be mapped to userspace as it would destroy their page type. Add an explicit check for this instead of assuming that kernel drivers always get this right. Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org Signed-off-by: Matthew Wilcox <willy@infradead.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-arm64-arm64-xl-xsm.guest-start.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-arm64-arm64-xl-xsm.guest-start --summary-out=tmp/133723.bisection-summary --basis-template=133580 --blessings=real,real-bisect linux-linus test-arm64-arm64-xl-xsm guest-start Searching for failure / basis pass: 133673 fail [host=laxton0] / 133605 [host=laxton1] 133580 ok. Failure / basis pass flights: 133673 / 133580 Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 38e7571c07be01f9f19b355a9306a4e3d5cb0f5b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 Basis pass 736706bee3298208343a76096370e4f6a5c55915 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 f393b82fe5ba3ed9cfe2b306ffa53368e55b75af Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#736706bee3298208343a76096370e4f6a5c55915-38e7571c07be01f9f19b355a9306a4e3d5cb0f5b git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#f393b82fe5ba3ed9c\ fe2b306ffa53368e55b75af-eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 Loaded 149180 nodes in revision graph Searching for test results: 133581 blocked irrelevant 133585 blocked irrelevant 133605 [host=laxton1] 133580 pass 736706bee3298208343a76096370e4f6a5c55915 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 f393b82fe5ba3ed9cfe2b306ffa53368e55b75af 133679 fail irrelevant 133689 pass irrelevant 133674 pass 736706bee3298208343a76096370e4f6a5c55915 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 f393b82fe5ba3ed9cfe2b306ffa53368e55b75af 133631 fail irrelevant 133686 fail irrelevant 133678 fail irrelevant 133681 pass irrelevant 133683 pass irrelevant 133685 pass irrelevant 133687 fail irrelevant 133688 fail irrelevant 133673 fail 38e7571c07be01f9f19b355a9306a4e3d5cb0f5b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133690 fail irrelevant 133720 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133691 fail irrelevant 133692 fail irrelevant 133694 fail 38e7571c07be01f9f19b355a9306a4e3d5cb0f5b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133721 pass 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133723 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133697 fail e5eed351fd5eb73eecc1407cf00309e868379253 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133700 fail f900482da560941f978b0d36660e96f48ea78752 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133701 pass c52e75935f8ded2bd4a75eb08e914bd96802725b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133702 fail 8bb4e7a2ee26c05a94ae6cb0aec2f82a3523cf35 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133704 pass 9bebefd59084af7c75b66eeee241bf0777f39b88 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133705 pass dc50537bdd1a0804fa2cbc990565ee9a944e66fa c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133709 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133710 pass 677dc9731b54dccaaadbdcea18f8eecc95cee832 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133711 pass afd07389d3f4933c7f7817a92fb5e053d59a3182 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133713 pass 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133715 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133718 blocked 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 133719 pass 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 Searching for interesting versions Result found: flight 133580 (pass), for basis pass Result found: flight 133673 (fail), for basis failure Repro found: flight 133674 (pass), for basis pass Repro found: flight 133694 (fail), for basis failure 0 revisions at 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 No revisions left to test, checking graph state. Result found: flight 133713 (pass), for last pass Result found: flight 133715 (fail), for first failure Repro found: flight 133719 (pass), for last pass Repro found: flight 133720 (fail), for first failure Repro found: flight 133721 (pass), for last pass Repro found: flight 133723 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: 0ee930e6cafa048c1925893d0ca89918b2814f2c Bug not present: 2d432cb7091e99881af803cdd67a31969b863005 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/133723/ commit 0ee930e6cafa048c1925893d0ca89918b2814f2c Author: Matthew Wilcox <willy@infradead.org> Date: Tue Mar 5 15:46:06 2019 -0800 mm/memory.c: prevent mapping typed pages to userspace Pages which use page_type must never be mapped to userspace as it would destroy their page type. Add an explicit check for this instead of assuming that kernel drivers always get this right. Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org Signed-off-by: Matthew Wilcox <willy@infradead.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> pnmtopng: 189 colors found Revision graph left in /home/logs/results/bisect/linux-linus/test-arm64-arm64-xl-xsm.guest-start.{dot,ps,png,html,svg}. ---------------------------------------- 133723: tolerable ALL FAIL flight 133723 linux-linus real-bisect [real] http://logs.test-lab.xenproject.org/osstest/logs/133723/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-arm64-arm64-xl-xsm 12 guest-start fail baseline untested jobs: test-arm64-arm64-xl-xsm fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm 2019-03-11 23:52 [linux-linus bisection] complete test-arm64-arm64-xl-xsm osstest service owner @ 2019-03-12 15:59 ` Julien Grall 2019-03-12 17:05 ` xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) Julien Grall ` (2 more replies) 0 siblings, 3 replies; 38+ messages in thread From: Julien Grall @ 2019-03-12 15:59 UTC (permalink / raw) To: osstest service owner, xen-devel, Juergen Gross, Konrad Rzeszutek Wilk, Boris Ostrovsky, Stefano Stabellini Hi all, It looks like all the arm test for linus [1] and next [2] tree are now failing. x86 seems to be mostly ok. The bisector fingered the following commit: commit 0ee930e6cafa048c1925893d0ca89918b2814f2c Author: Matthew Wilcox <willy@infradead.org> Date: Tue Mar 5 15:46:06 2019 -0800 mm/memory.c: prevent mapping typed pages to userspace Pages which use page_type must never be mapped to userspace as it would destroy their page type. Add an explicit check for this instead of assuming that kernel drivers always get this right. Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org Signed-off-by: Matthew Wilcox <willy@infradead.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> I have tried the latest linus mater as Dom0 and see some issue to get the console guest: 42sh> sudo xl create -c ~/works/guest/guest.cfg Parsing config from /home/julien/works/guest/guest.cfg xenconsole: Could not read tty from store: Success I have added a print in the error path added by the commit above to see what and where it happens: [ 182.366372] PageAnon 0 PageSlab 0 page_has_type 1 [ 182.371076] WARNING: CPU: 2 PID: 2210 at mm/memory.c:1459 vm_insert_page+0x3e 0/0x430 [ 182.378837] Modules linked in: [ 182.381974] CPU: 2 PID: 2210 Comm: xenstored Not tainted 5.0.0-10742-gea29548 1b6e3-dirty #1310 [ 182.390672] Hardware name: ARM Juno development board (r2) (DT) [ 182.396678] pstate: 40000005 (nZcv daif -PAN -UAO) [ 182.401553] pc : vm_insert_page+0x3e0/0x430 [ 182.405816] lr : vm_insert_page+0x3e0/0x430 [ 182.410077] sp : ffff000012773bc0 [ 182.413471] x29: ffff000012773bc0 x28: 0000ffff8d3fa000 [ 182.418866] x27: 0000000000000008 x26: 0000000000000001 [ 182.424261] x25: 0000000000000008 x24: 0000ffff8d3fa000 [ 182.429656] x23: 0068000000000f53 x22: ffff8008ab520a00 [ 182.435052] x21: ffff000011644a88 x20: 0000000000000000 [ 182.440454] x19: ffff7e00229b0e80 x18: 0000000000000000 [ 182.445841] x17: 0000000000000000 x16: 0000000000000000 [ 182.451245] x15: 00000000fffffff0 x14: 0000000000000000 [ 182.456631] x13: ffff000012339ff0 x12: 0000000000000006 [ 182.462027] x11: ffff000010ec4980 x10: ffff0000107d01f8 [ 182.467422] x9 : 00000000fffb9fff x8 : ffff8008ab55a0a0 [ 182.472817] x7 : 0000000000000001 x6 : ffff8008bb02a220 [ 182.478212] x5 : ffff8008bb02a220 x4 : 0000000000000000 [ 182.483607] x3 : ffff8008bb032708 x2 : b98ad6a7b7eb2900 [ 182.489002] x1 : 0000000000000000 x0 : 0000000000000025 [ 182.494397] Call trace: [ 182.496924] vm_insert_page+0x3e0/0x430 [ 182.500853] gntdev_mmap+0x188/0x288 [ 182.504495] mmap_region+0x3dc/0x578 [ 182.508149] do_mmap+0x2d4/0x478 [ 182.511457] vm_mmap_pgoff+0xe0/0x108 [ 182.515198] ksys_mmap_pgoff+0xac/0x308 [ 182.519116] __arm64_sys_mmap+0x28/0x38 [ 182.523029] el0_svc_handler+0x88/0x100 [ 182.526943] el0_svc+0x8/0xc [ 182.529901] ---[ end trace cf738ac71bfed946 ]--- Does it ring any bell? Cheers, [1] http://logs.test-lab.xenproject.org/osstest/logs/133695/ [2] http://logs.test-lab.xenproject.org/osstest/logs/133655/ On 3/11/19 11:52 PM, osstest service owner wrote: > branch xen-unstable > xenbranch xen-unstable > job test-arm64-arm64-xl-xsm > testid guest-start > > Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git > Tree: qemuu git://xenbits.xen.org/qemu-xen.git > Tree: xen git://xenbits.xen.org/xen.git > > *** Found and reproduced problem changeset *** > > Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > Bug introduced: 0ee930e6cafa048c1925893d0ca89918b2814f2c > Bug not present: 2d432cb7091e99881af803cdd67a31969b863005 > Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/133723/ > > > commit > Author: Matthew Wilcox <willy@infradead.org> > Date: Tue Mar 5 15:46:06 2019 -0800 > > mm/memory.c: prevent mapping typed pages to userspace > > Pages which use page_type must never be mapped to userspace as it would > destroy their page type. Add an explicit check for this instead of > assuming that kernel drivers always get this right. > > Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org > Signed-off-by: Matthew Wilcox <willy@infradead.org> > Reviewed-by: Kees Cook <keescook@chromium.org> > Reviewed-by: David Hildenbrand <david@redhat.com> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: Will Deacon <will.deacon@arm.com> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> > > > For bisection revision-tuple graph see: > http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-arm64-arm64-xl-xsm.guest-start.html > Revision IDs in each graph node refer, respectively, to the Trees above. > > ---------------------------------------- > Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-arm64-arm64-xl-xsm.guest-start --summary-out=tmp/133723.bisection-summary --basis-template=133580 --blessings=real,real-bisect linux-linus test-arm64-arm64-xl-xsm guest-start > Searching for failure / basis pass: > 133673 fail [host=laxton0] / 133605 [host=laxton1] 133580 ok. > Failure / basis pass flights: 133673 / 133580 > Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git > Tree: qemuu git://xenbits.xen.org/qemu-xen.git > Tree: xen git://xenbits.xen.org/xen.git > Latest 38e7571c07be01f9f19b355a9306a4e3d5cb0f5b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > Basis pass 736706bee3298208343a76096370e4f6a5c55915 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 f393b82fe5ba3ed9cfe2b306ffa53368e55b75af > Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#736706bee3298208343a76096370e4f6a5c55915-38e7571c07be01f9f19b355a9306a4e3d5cb0f5b git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#f393b82fe5ba3ed9c\ > fe2b306ffa53368e55b75af-eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > Loaded 149180 nodes in revision graph > Searching for test results: > 133581 blocked irrelevant > 133585 blocked irrelevant > 133605 [host=laxton1] > 133580 pass 736706bee3298208343a76096370e4f6a5c55915 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 f393b82fe5ba3ed9cfe2b306ffa53368e55b75af > 133679 fail irrelevant > 133689 pass irrelevant > 133674 pass 736706bee3298208343a76096370e4f6a5c55915 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 f393b82fe5ba3ed9cfe2b306ffa53368e55b75af > 133631 fail irrelevant > 133686 fail irrelevant > 133678 fail irrelevant > 133681 pass irrelevant > 133683 pass irrelevant > 133685 pass irrelevant > 133687 fail irrelevant > 133688 fail irrelevant > 133673 fail 38e7571c07be01f9f19b355a9306a4e3d5cb0f5b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133690 fail irrelevant > 133720 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133691 fail irrelevant > 133692 fail irrelevant > 133694 fail 38e7571c07be01f9f19b355a9306a4e3d5cb0f5b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133721 pass 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133723 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133697 fail e5eed351fd5eb73eecc1407cf00309e868379253 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133700 fail f900482da560941f978b0d36660e96f48ea78752 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133701 pass c52e75935f8ded2bd4a75eb08e914bd96802725b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133702 fail 8bb4e7a2ee26c05a94ae6cb0aec2f82a3523cf35 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133704 pass 9bebefd59084af7c75b66eeee241bf0777f39b88 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133705 pass dc50537bdd1a0804fa2cbc990565ee9a944e66fa c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133709 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133710 pass 677dc9731b54dccaaadbdcea18f8eecc95cee832 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133711 pass afd07389d3f4933c7f7817a92fb5e053d59a3182 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133713 pass 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133715 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133718 blocked 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > 133719 pass 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > Searching for interesting versions > Result found: flight 133580 (pass), for basis pass > Result found: flight 133673 (fail), for basis failure > Repro found: flight 133674 (pass), for basis pass > Repro found: flight 133694 (fail), for basis failure > 0 revisions at 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 > No revisions left to test, checking graph state. > Result found: flight 133713 (pass), for last pass > Result found: flight 133715 (fail), for first failure > Repro found: flight 133719 (pass), for last pass > Repro found: flight 133720 (fail), for first failure > Repro found: flight 133721 (pass), for last pass > Repro found: flight 133723 (fail), for first failure > > *** Found and reproduced problem changeset *** > > Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > Bug introduced: 0ee930e6cafa048c1925893d0ca89918b2814f2c > Bug not present: 2d432cb7091e99881af803cdd67a31969b863005 > Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/133723/ > > > commit 0ee930e6cafa048c1925893d0ca89918b2814f2c > Author: Matthew Wilcox <willy@infradead.org> > Date: Tue Mar 5 15:46:06 2019 -0800 > > mm/memory.c: prevent mapping typed pages to userspace > > Pages which use page_type must never be mapped to userspace as it would > destroy their page type. Add an explicit check for this instead of > assuming that kernel drivers always get this right. > > Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org > Signed-off-by: Matthew Wilcox <willy@infradead.org> > Reviewed-by: Kees Cook <keescook@chromium.org> > Reviewed-by: David Hildenbrand <david@redhat.com> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: Will Deacon <will.deacon@arm.com> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> > > pnmtopng: 189 colors found > Revision graph left in /home/logs/results/bisect/linux-linus/test-arm64-arm64-xl-xsm.guest-start.{dot,ps,png,html,svg}. > ---------------------------------------- > 133723: tolerable ALL FAIL > > flight 133723 linux-linus real-bisect [real] > http://logs.test-lab.xenproject.org/osstest/logs/133723/ > > Failures :-/ but no regressions. > > Tests which did not succeed, > including tests which could not be run: > test-arm64-arm64-xl-xsm 12 guest-start fail baseline untested > > > jobs: > test-arm64-arm64-xl-xsm fail > > > ------------------------------------------------------------ > sg-report-flight on osstest.test-lab.xenproject.org > logs: /home/logs/logs > images: /home/logs/images > > Logs, config files, etc. are available at > http://logs.test-lab.xenproject.org/osstest/logs > > Explanation of these reports, and of osstest in general, is at > http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master > http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master > > Test harness code can be found at > http://xenbits.xen.org/gitweb?p=osstest.git;a=summary > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel > -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 15:59 ` Julien Grall @ 2019-03-12 17:05 ` Julien Grall 2019-03-12 17:05 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " Julien Grall 2019-03-12 17:27 ` [linux-linus bisection] complete test-arm64-arm64-xl-xsm Roger Pau Monné 2 siblings, 0 replies; 38+ messages in thread From: Julien Grall @ 2019-03-12 17:05 UTC (permalink / raw) To: osstest service owner, xen-devel, Juergen Gross, Konrad Rzeszutek Wilk, Boris Ostrovsky, Stefano Stabellini, linux-kernel, willy, Kees Cook, david (Adding more people in the thread) Hi, On 3/12/19 3:59 PM, Julien Grall wrote: > Hi all, > > It looks like all the arm test for linus [1] and next [2] tree > are now failing. x86 seems to be mostly ok. > > The bisector fingered the following commit: > > commit 0ee930e6cafa048c1925893d0ca89918b2814f2c > Author: Matthew Wilcox <willy@infradead.org> > Date: Tue Mar 5 15:46:06 2019 -0800 > > mm/memory.c: prevent mapping typed pages to userspace > > Pages which use page_type must never be mapped to userspace as it would > destroy their page type. Add an explicit check for this instead of > assuming that kernel drivers always get this right. > > Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org > Signed-off-by: Matthew Wilcox <willy@infradead.org> > Reviewed-by: Kees Cook <keescook@chromium.org> > Reviewed-by: David Hildenbrand <david@redhat.com> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: Will Deacon <will.deacon@arm.com> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> > > I have tried the latest linus mater as Dom0 and see some issue to get the > console guest: > > 42sh> sudo xl create -c ~/works/guest/guest.cfg > Parsing config from /home/julien/works/guest/guest.cfg > xenconsole: Could not read tty from store: Success > > I have added a print in the error path added by the commit above to see > what and where it happens: > > [ 182.366372] PageAnon 0 PageSlab 0 page_has_type 1 > [ 182.371076] WARNING: CPU: 2 PID: 2210 at mm/memory.c:1459 vm_insert_page+0x3e > 0/0x430 > [ 182.378837] Modules linked in: > [ 182.381974] CPU: 2 PID: 2210 Comm: xenstored Not tainted 5.0.0-10742-gea29548 > 1b6e3-dirty #1310 > [ 182.390672] Hardware name: ARM Juno development board (r2) (DT) > [ 182.396678] pstate: 40000005 (nZcv daif -PAN -UAO) > [ 182.401553] pc : vm_insert_page+0x3e0/0x430 > [ 182.405816] lr : vm_insert_page+0x3e0/0x430 > [ 182.410077] sp : ffff000012773bc0 > [ 182.413471] x29: ffff000012773bc0 x28: 0000ffff8d3fa000 > [ 182.418866] x27: 0000000000000008 x26: 0000000000000001 > [ 182.424261] x25: 0000000000000008 x24: 0000ffff8d3fa000 > [ 182.429656] x23: 0068000000000f53 x22: ffff8008ab520a00 > [ 182.435052] x21: ffff000011644a88 x20: 0000000000000000 > [ 182.440454] x19: ffff7e00229b0e80 x18: 0000000000000000 > [ 182.445841] x17: 0000000000000000 x16: 0000000000000000 > [ 182.451245] x15: 00000000fffffff0 x14: 0000000000000000 > [ 182.456631] x13: ffff000012339ff0 x12: 0000000000000006 > [ 182.462027] x11: ffff000010ec4980 x10: ffff0000107d01f8 > [ 182.467422] x9 : 00000000fffb9fff x8 : ffff8008ab55a0a0 > [ 182.472817] x7 : 0000000000000001 x6 : ffff8008bb02a220 > [ 182.478212] x5 : ffff8008bb02a220 x4 : 0000000000000000 > [ 182.483607] x3 : ffff8008bb032708 x2 : b98ad6a7b7eb2900 > [ 182.489002] x1 : 0000000000000000 x0 : 0000000000000025 > [ 182.494397] Call trace: > [ 182.496924] vm_insert_page+0x3e0/0x430 > [ 182.500853] gntdev_mmap+0x188/0x288 > [ 182.504495] mmap_region+0x3dc/0x578 > [ 182.508149] do_mmap+0x2d4/0x478 > [ 182.511457] vm_mmap_pgoff+0xe0/0x108 > [ 182.515198] ksys_mmap_pgoff+0xac/0x308 > [ 182.519116] __arm64_sys_mmap+0x28/0x38 > [ 182.523029] el0_svc_handler+0x88/0x100 > [ 182.526943] el0_svc+0x8/0xc > [ 182.529901] ---[ end trace cf738ac71bfed946 ]--- > > Does it ring any bell? It turns out the problem is because the balloon driver will call __SetPageOffline() on allocated page. Therefore the page has a type and vm_insert_pages will deny the insertion. My knowledge is quite limited in this area. So I am not sure how we can solve the problem. I would appreciate if someone could provide input of to fix the mapping. Cheers, > > Cheers, > > [1] http://logs.test-lab.xenproject.org/osstest/logs/133695/ > [2] http://logs.test-lab.xenproject.org/osstest/logs/133655/ > > On 3/11/19 11:52 PM, osstest service owner wrote: >> branch xen-unstable >> xenbranch xen-unstable >> job test-arm64-arm64-xl-xsm >> testid guest-start >> >> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git >> Tree: qemuu git://xenbits.xen.org/qemu-xen.git >> Tree: xen git://xenbits.xen.org/xen.git >> >> *** Found and reproduced problem changeset *** >> >> Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> Bug introduced: 0ee930e6cafa048c1925893d0ca89918b2814f2c >> Bug not present: 2d432cb7091e99881af803cdd67a31969b863005 >> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/133723/ >> >> >> commit > > >> Author: Matthew Wilcox <willy@infradead.org> >> Date: Tue Mar 5 15:46:06 2019 -0800 >> >> mm/memory.c: prevent mapping typed pages to userspace >> >> Pages which use page_type must never be mapped to userspace as it would >> destroy their page type. Add an explicit check for this instead of >> assuming that kernel drivers always get this right. >> >> Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org >> Signed-off-by: Matthew Wilcox <willy@infradead.org> >> Reviewed-by: Kees Cook <keescook@chromium.org> >> Reviewed-by: David Hildenbrand <david@redhat.com> >> Cc: Michael Ellerman <mpe@ellerman.id.au> >> Cc: Will Deacon <will.deacon@arm.com> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> >> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> >> >> >> For bisection revision-tuple graph see: >> http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-arm64-arm64-xl-xsm.guest-start.html >> Revision IDs in each graph node refer, respectively, to the Trees above. >> >> ---------------------------------------- >> Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-arm64-arm64-xl-xsm.guest-start --summary-out=tmp/133723.bisection-summary --basis-template=133580 --blessings=real,real-bisect linux-linus test-arm64-arm64-xl-xsm guest-start >> Searching for failure / basis pass: >> 133673 fail [host=laxton0] / 133605 [host=laxton1] 133580 ok. >> Failure / basis pass flights: 133673 / 133580 >> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git >> Tree: qemuu git://xenbits.xen.org/qemu-xen.git >> Tree: xen git://xenbits.xen.org/xen.git >> Latest 38e7571c07be01f9f19b355a9306a4e3d5cb0f5b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> Basis pass 736706bee3298208343a76096370e4f6a5c55915 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 f393b82fe5ba3ed9cfe2b306ffa53368e55b75af >> Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#736706bee3298208343a76096370e4f6a5c55915-38e7571c07be01f9f19b355a9306a4e3d5cb0f5b git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#f393b82fe5ba3ed9c\ >> fe2b306ffa53368e55b75af-eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> Loaded 149180 nodes in revision graph >> Searching for test results: >> 133581 blocked irrelevant >> 133585 blocked irrelevant >> 133605 [host=laxton1] >> 133580 pass 736706bee3298208343a76096370e4f6a5c55915 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 f393b82fe5ba3ed9cfe2b306ffa53368e55b75af >> 133679 fail irrelevant >> 133689 pass irrelevant >> 133674 pass 736706bee3298208343a76096370e4f6a5c55915 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 f393b82fe5ba3ed9cfe2b306ffa53368e55b75af >> 133631 fail irrelevant >> 133686 fail irrelevant >> 133678 fail irrelevant >> 133681 pass irrelevant >> 133683 pass irrelevant >> 133685 pass irrelevant >> 133687 fail irrelevant >> 133688 fail irrelevant >> 133673 fail 38e7571c07be01f9f19b355a9306a4e3d5cb0f5b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133690 fail irrelevant >> 133720 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133691 fail irrelevant >> 133692 fail irrelevant >> 133694 fail 38e7571c07be01f9f19b355a9306a4e3d5cb0f5b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133721 pass 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133723 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133697 fail e5eed351fd5eb73eecc1407cf00309e868379253 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133700 fail f900482da560941f978b0d36660e96f48ea78752 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133701 pass c52e75935f8ded2bd4a75eb08e914bd96802725b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133702 fail 8bb4e7a2ee26c05a94ae6cb0aec2f82a3523cf35 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133704 pass 9bebefd59084af7c75b66eeee241bf0777f39b88 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133705 pass dc50537bdd1a0804fa2cbc990565ee9a944e66fa c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133709 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133710 pass 677dc9731b54dccaaadbdcea18f8eecc95cee832 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133711 pass afd07389d3f4933c7f7817a92fb5e053d59a3182 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133713 pass 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133715 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133718 blocked 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133719 pass 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> Searching for interesting versions >> Result found: flight 133580 (pass), for basis pass >> Result found: flight 133673 (fail), for basis failure >> Repro found: flight 133674 (pass), for basis pass >> Repro found: flight 133694 (fail), for basis failure >> 0 revisions at 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> No revisions left to test, checking graph state. >> Result found: flight 133713 (pass), for last pass >> Result found: flight 133715 (fail), for first failure >> Repro found: flight 133719 (pass), for last pass >> Repro found: flight 133720 (fail), for first failure >> Repro found: flight 133721 (pass), for last pass >> Repro found: flight 133723 (fail), for first failure >> >> *** Found and reproduced problem changeset *** >> >> Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> Bug introduced: 0ee930e6cafa048c1925893d0ca89918b2814f2c >> Bug not present: 2d432cb7091e99881af803cdd67a31969b863005 >> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/133723/ >> >> >> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >> Author: Matthew Wilcox <willy@infradead.org> >> Date: Tue Mar 5 15:46:06 2019 -0800 >> >> mm/memory.c: prevent mapping typed pages to userspace >> >> Pages which use page_type must never be mapped to userspace as it would >> destroy their page type. Add an explicit check for this instead of >> assuming that kernel drivers always get this right. >> >> Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org >> Signed-off-by: Matthew Wilcox <willy@infradead.org> >> Reviewed-by: Kees Cook <keescook@chromium.org> >> Reviewed-by: David Hildenbrand <david@redhat.com> >> Cc: Michael Ellerman <mpe@ellerman.id.au> >> Cc: Will Deacon <will.deacon@arm.com> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> >> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> >> >> pnmtopng: 189 colors found >> Revision graph left in /home/logs/results/bisect/linux-linus/test-arm64-arm64-xl-xsm.guest-start.{dot,ps,png,html,svg}. >> ---------------------------------------- >> 133723: tolerable ALL FAIL >> >> flight 133723 linux-linus real-bisect [real] >> http://logs.test-lab.xenproject.org/osstest/logs/133723/ >> >> Failures :-/ but no regressions. >> >> Tests which did not succeed, >> including tests which could not be run: >> test-arm64-arm64-xl-xsm 12 guest-start fail baseline untested >> >> >> jobs: >> test-arm64-arm64-xl-xsm fail >> >> >> ------------------------------------------------------------ >> sg-report-flight on osstest.test-lab.xenproject.org >> logs: /home/logs/logs >> images: /home/logs/images >> >> Logs, config files, etc. are available at >> http://logs.test-lab.xenproject.org/osstest/logs >> >> Explanation of these reports, and of osstest in general, is at >> http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master >> http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master >> >> Test harness code can be found at >> http://xenbits.xen.org/gitweb?p=osstest.git;a=summary >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xenproject.org >> https://lists.xenproject.org/mailman/listinfo/xen-devel >> > -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 15:59 ` Julien Grall 2019-03-12 17:05 ` xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) Julien Grall @ 2019-03-12 17:05 ` Julien Grall 2019-03-12 17:14 ` xen: Can't insert balloon page into VM userspace (WAS " Matthew Wilcox 2019-03-12 17:27 ` [linux-linus bisection] complete test-arm64-arm64-xl-xsm Roger Pau Monné 2 siblings, 1 reply; 38+ messages in thread From: Julien Grall @ 2019-03-12 17:05 UTC (permalink / raw) To: osstest service owner, xen-devel, Juergen Gross, Konrad Rzeszutek Wilk, Boris Ostrovsky, Stefano Stabellini, linux-kernel, willy, Kees Cook, david (Adding more people in the thread) Hi, On 3/12/19 3:59 PM, Julien Grall wrote: > Hi all, > > It looks like all the arm test for linus [1] and next [2] tree > are now failing. x86 seems to be mostly ok. > > The bisector fingered the following commit: > > commit 0ee930e6cafa048c1925893d0ca89918b2814f2c > Author: Matthew Wilcox <willy@infradead.org> > Date: Tue Mar 5 15:46:06 2019 -0800 > > mm/memory.c: prevent mapping typed pages to userspace > > Pages which use page_type must never be mapped to userspace as it would > destroy their page type. Add an explicit check for this instead of > assuming that kernel drivers always get this right. > > Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org > Signed-off-by: Matthew Wilcox <willy@infradead.org> > Reviewed-by: Kees Cook <keescook@chromium.org> > Reviewed-by: David Hildenbrand <david@redhat.com> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: Will Deacon <will.deacon@arm.com> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> > > I have tried the latest linus mater as Dom0 and see some issue to get the > console guest: > > 42sh> sudo xl create -c ~/works/guest/guest.cfg > Parsing config from /home/julien/works/guest/guest.cfg > xenconsole: Could not read tty from store: Success > > I have added a print in the error path added by the commit above to see > what and where it happens: > > [ 182.366372] PageAnon 0 PageSlab 0 page_has_type 1 > [ 182.371076] WARNING: CPU: 2 PID: 2210 at mm/memory.c:1459 vm_insert_page+0x3e > 0/0x430 > [ 182.378837] Modules linked in: > [ 182.381974] CPU: 2 PID: 2210 Comm: xenstored Not tainted 5.0.0-10742-gea29548 > 1b6e3-dirty #1310 > [ 182.390672] Hardware name: ARM Juno development board (r2) (DT) > [ 182.396678] pstate: 40000005 (nZcv daif -PAN -UAO) > [ 182.401553] pc : vm_insert_page+0x3e0/0x430 > [ 182.405816] lr : vm_insert_page+0x3e0/0x430 > [ 182.410077] sp : ffff000012773bc0 > [ 182.413471] x29: ffff000012773bc0 x28: 0000ffff8d3fa000 > [ 182.418866] x27: 0000000000000008 x26: 0000000000000001 > [ 182.424261] x25: 0000000000000008 x24: 0000ffff8d3fa000 > [ 182.429656] x23: 0068000000000f53 x22: ffff8008ab520a00 > [ 182.435052] x21: ffff000011644a88 x20: 0000000000000000 > [ 182.440454] x19: ffff7e00229b0e80 x18: 0000000000000000 > [ 182.445841] x17: 0000000000000000 x16: 0000000000000000 > [ 182.451245] x15: 00000000fffffff0 x14: 0000000000000000 > [ 182.456631] x13: ffff000012339ff0 x12: 0000000000000006 > [ 182.462027] x11: ffff000010ec4980 x10: ffff0000107d01f8 > [ 182.467422] x9 : 00000000fffb9fff x8 : ffff8008ab55a0a0 > [ 182.472817] x7 : 0000000000000001 x6 : ffff8008bb02a220 > [ 182.478212] x5 : ffff8008bb02a220 x4 : 0000000000000000 > [ 182.483607] x3 : ffff8008bb032708 x2 : b98ad6a7b7eb2900 > [ 182.489002] x1 : 0000000000000000 x0 : 0000000000000025 > [ 182.494397] Call trace: > [ 182.496924] vm_insert_page+0x3e0/0x430 > [ 182.500853] gntdev_mmap+0x188/0x288 > [ 182.504495] mmap_region+0x3dc/0x578 > [ 182.508149] do_mmap+0x2d4/0x478 > [ 182.511457] vm_mmap_pgoff+0xe0/0x108 > [ 182.515198] ksys_mmap_pgoff+0xac/0x308 > [ 182.519116] __arm64_sys_mmap+0x28/0x38 > [ 182.523029] el0_svc_handler+0x88/0x100 > [ 182.526943] el0_svc+0x8/0xc > [ 182.529901] ---[ end trace cf738ac71bfed946 ]--- > > Does it ring any bell? It turns out the problem is because the balloon driver will call __SetPageOffline() on allocated page. Therefore the page has a type and vm_insert_pages will deny the insertion. My knowledge is quite limited in this area. So I am not sure how we can solve the problem. I would appreciate if someone could provide input of to fix the mapping. Cheers, > > Cheers, > > [1] http://logs.test-lab.xenproject.org/osstest/logs/133695/ > [2] http://logs.test-lab.xenproject.org/osstest/logs/133655/ > > On 3/11/19 11:52 PM, osstest service owner wrote: >> branch xen-unstable >> xenbranch xen-unstable >> job test-arm64-arm64-xl-xsm >> testid guest-start >> >> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git >> Tree: qemuu git://xenbits.xen.org/qemu-xen.git >> Tree: xen git://xenbits.xen.org/xen.git >> >> *** Found and reproduced problem changeset *** >> >> Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> Bug introduced: 0ee930e6cafa048c1925893d0ca89918b2814f2c >> Bug not present: 2d432cb7091e99881af803cdd67a31969b863005 >> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/133723/ >> >> >> commit > > >> Author: Matthew Wilcox <willy@infradead.org> >> Date: Tue Mar 5 15:46:06 2019 -0800 >> >> mm/memory.c: prevent mapping typed pages to userspace >> >> Pages which use page_type must never be mapped to userspace as it would >> destroy their page type. Add an explicit check for this instead of >> assuming that kernel drivers always get this right. >> >> Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org >> Signed-off-by: Matthew Wilcox <willy@infradead.org> >> Reviewed-by: Kees Cook <keescook@chromium.org> >> Reviewed-by: David Hildenbrand <david@redhat.com> >> Cc: Michael Ellerman <mpe@ellerman.id.au> >> Cc: Will Deacon <will.deacon@arm.com> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> >> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> >> >> >> For bisection revision-tuple graph see: >> http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-arm64-arm64-xl-xsm.guest-start.html >> Revision IDs in each graph node refer, respectively, to the Trees above. >> >> ---------------------------------------- >> Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-arm64-arm64-xl-xsm.guest-start --summary-out=tmp/133723.bisection-summary --basis-template=133580 --blessings=real,real-bisect linux-linus test-arm64-arm64-xl-xsm guest-start >> Searching for failure / basis pass: >> 133673 fail [host=laxton0] / 133605 [host=laxton1] 133580 ok. >> Failure / basis pass flights: 133673 / 133580 >> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git >> Tree: qemuu git://xenbits.xen.org/qemu-xen.git >> Tree: xen git://xenbits.xen.org/xen.git >> Latest 38e7571c07be01f9f19b355a9306a4e3d5cb0f5b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> Basis pass 736706bee3298208343a76096370e4f6a5c55915 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 f393b82fe5ba3ed9cfe2b306ffa53368e55b75af >> Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#736706bee3298208343a76096370e4f6a5c55915-38e7571c07be01f9f19b355a9306a4e3d5cb0f5b git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#f393b82fe5ba3ed9c\ >> fe2b306ffa53368e55b75af-eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> Loaded 149180 nodes in revision graph >> Searching for test results: >> 133581 blocked irrelevant >> 133585 blocked irrelevant >> 133605 [host=laxton1] >> 133580 pass 736706bee3298208343a76096370e4f6a5c55915 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 f393b82fe5ba3ed9cfe2b306ffa53368e55b75af >> 133679 fail irrelevant >> 133689 pass irrelevant >> 133674 pass 736706bee3298208343a76096370e4f6a5c55915 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 f393b82fe5ba3ed9cfe2b306ffa53368e55b75af >> 133631 fail irrelevant >> 133686 fail irrelevant >> 133678 fail irrelevant >> 133681 pass irrelevant >> 133683 pass irrelevant >> 133685 pass irrelevant >> 133687 fail irrelevant >> 133688 fail irrelevant >> 133673 fail 38e7571c07be01f9f19b355a9306a4e3d5cb0f5b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133690 fail irrelevant >> 133720 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133691 fail irrelevant >> 133692 fail irrelevant >> 133694 fail 38e7571c07be01f9f19b355a9306a4e3d5cb0f5b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133721 pass 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133723 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133697 fail e5eed351fd5eb73eecc1407cf00309e868379253 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133700 fail f900482da560941f978b0d36660e96f48ea78752 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133701 pass c52e75935f8ded2bd4a75eb08e914bd96802725b c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133702 fail 8bb4e7a2ee26c05a94ae6cb0aec2f82a3523cf35 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133704 pass 9bebefd59084af7c75b66eeee241bf0777f39b88 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133705 pass dc50537bdd1a0804fa2cbc990565ee9a944e66fa c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133709 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133710 pass 677dc9731b54dccaaadbdcea18f8eecc95cee832 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133711 pass afd07389d3f4933c7f7817a92fb5e053d59a3182 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133713 pass 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133715 fail 0ee930e6cafa048c1925893d0ca89918b2814f2c c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133718 blocked 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> 133719 pass 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> Searching for interesting versions >> Result found: flight 133580 (pass), for basis pass >> Result found: flight 133673 (fail), for basis failure >> Repro found: flight 133674 (pass), for basis pass >> Repro found: flight 133694 (fail), for basis failure >> 0 revisions at 2d432cb7091e99881af803cdd67a31969b863005 c530a75c1e6a472b0eb9558310b518f0dfcd8860 de5b678ca4dcdfa83e322491d478d66df56c1986 eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3 >> No revisions left to test, checking graph state. >> Result found: flight 133713 (pass), for last pass >> Result found: flight 133715 (fail), for first failure >> Repro found: flight 133719 (pass), for last pass >> Repro found: flight 133720 (fail), for first failure >> Repro found: flight 133721 (pass), for last pass >> Repro found: flight 133723 (fail), for first failure >> >> *** Found and reproduced problem changeset *** >> >> Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> Bug introduced: 0ee930e6cafa048c1925893d0ca89918b2814f2c >> Bug not present: 2d432cb7091e99881af803cdd67a31969b863005 >> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/133723/ >> >> >> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >> Author: Matthew Wilcox <willy@infradead.org> >> Date: Tue Mar 5 15:46:06 2019 -0800 >> >> mm/memory.c: prevent mapping typed pages to userspace >> >> Pages which use page_type must never be mapped to userspace as it would >> destroy their page type. Add an explicit check for this instead of >> assuming that kernel drivers always get this right. >> >> Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org >> Signed-off-by: Matthew Wilcox <willy@infradead.org> >> Reviewed-by: Kees Cook <keescook@chromium.org> >> Reviewed-by: David Hildenbrand <david@redhat.com> >> Cc: Michael Ellerman <mpe@ellerman.id.au> >> Cc: Will Deacon <will.deacon@arm.com> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> >> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> >> >> pnmtopng: 189 colors found >> Revision graph left in /home/logs/results/bisect/linux-linus/test-arm64-arm64-xl-xsm.guest-start.{dot,ps,png,html,svg}. >> ---------------------------------------- >> 133723: tolerable ALL FAIL >> >> flight 133723 linux-linus real-bisect [real] >> http://logs.test-lab.xenproject.org/osstest/logs/133723/ >> >> Failures :-/ but no regressions. >> >> Tests which did not succeed, >> including tests which could not be run: >> test-arm64-arm64-xl-xsm 12 guest-start fail baseline untested >> >> >> jobs: >> test-arm64-arm64-xl-xsm fail >> >> >> ------------------------------------------------------------ >> sg-report-flight on osstest.test-lab.xenproject.org >> logs: /home/logs/logs >> images: /home/logs/images >> >> Logs, config files, etc. are available at >> http://logs.test-lab.xenproject.org/osstest/logs >> >> Explanation of these reports, and of osstest in general, is at >> http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master >> http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master >> >> Test harness code can be found at >> http://xenbits.xen.org/gitweb?p=osstest.git;a=summary >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xenproject.org >> https://lists.xenproject.org/mailman/listinfo/xen-devel >> > -- Julien Grall ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:05 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " Julien Grall @ 2019-03-12 17:14 ` Matthew Wilcox 0 siblings, 0 replies; 38+ messages in thread From: Matthew Wilcox @ 2019-03-12 17:14 UTC (permalink / raw) To: Julien Grall Cc: osstest service owner, xen-devel, Juergen Gross, Konrad Rzeszutek Wilk, Boris Ostrovsky, Stefano Stabellini, linux-kernel, Kees Cook, david, k.khlebnikov, Julien Freche, Nadav Amit, VMware, Inc., linux-mm On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: > On 3/12/19 3:59 PM, Julien Grall wrote: > > It looks like all the arm test for linus [1] and next [2] tree > > are now failing. x86 seems to be mostly ok. > > > > The bisector fingered the following commit: > > > > commit 0ee930e6cafa048c1925893d0ca89918b2814f2c > > Author: Matthew Wilcox <willy@infradead.org> > > Date: Tue Mar 5 15:46:06 2019 -0800 > > > > mm/memory.c: prevent mapping typed pages to userspace > > Pages which use page_type must never be mapped to userspace as it would > > destroy their page type. Add an explicit check for this instead of > > assuming that kernel drivers always get this right. Oh good, it found a real problem. > It turns out the problem is because the balloon driver will call > __SetPageOffline() on allocated page. Therefore the page has a type and > vm_insert_pages will deny the insertion. > > My knowledge is quite limited in this area. So I am not sure how we can > solve the problem. > > I would appreciate if someone could provide input of to fix the mapping. I don't know the balloon driver, so I don't know why it was doing this, but what it was doing was Wrong and has been since 2014 with: commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> Date: Thu Oct 9 15:29:27 2014 -0700 mm/balloon_compaction: redesign ballooned pages management If ballooned pages are supposed to be mapped into userspace, you can't mark them as ballooned pages using the mapcount field. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) @ 2019-03-12 17:14 ` Matthew Wilcox 0 siblings, 0 replies; 38+ messages in thread From: Matthew Wilcox @ 2019-03-12 17:14 UTC (permalink / raw) To: Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., david, osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel, Boris Ostrovsky On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: > On 3/12/19 3:59 PM, Julien Grall wrote: > > It looks like all the arm test for linus [1] and next [2] tree > > are now failing. x86 seems to be mostly ok. > > > > The bisector fingered the following commit: > > > > commit 0ee930e6cafa048c1925893d0ca89918b2814f2c > > Author: Matthew Wilcox <willy@infradead.org> > > Date: Tue Mar 5 15:46:06 2019 -0800 > > > > mm/memory.c: prevent mapping typed pages to userspace > > Pages which use page_type must never be mapped to userspace as it would > > destroy their page type. Add an explicit check for this instead of > > assuming that kernel drivers always get this right. Oh good, it found a real problem. > It turns out the problem is because the balloon driver will call > __SetPageOffline() on allocated page. Therefore the page has a type and > vm_insert_pages will deny the insertion. > > My knowledge is quite limited in this area. So I am not sure how we can > solve the problem. > > I would appreciate if someone could provide input of to fix the mapping. I don't know the balloon driver, so I don't know why it was doing this, but what it was doing was Wrong and has been since 2014 with: commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> Date: Thu Oct 9 15:29:27 2014 -0700 mm/balloon_compaction: redesign ballooned pages management If ballooned pages are supposed to be mapped into userspace, you can't mark them as ballooned pages using the mapcount field. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:14 ` xen: Can't insert balloon page into VM userspace (WAS " Matthew Wilcox @ 2019-03-12 17:18 ` David Hildenbrand -1 siblings, 0 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-12 17:18 UTC (permalink / raw) To: Matthew Wilcox, Julien Grall Cc: osstest service owner, xen-devel, Juergen Gross, Konrad Rzeszutek Wilk, Boris Ostrovsky, Stefano Stabellini, linux-kernel, Kees Cook, k.khlebnikov, Julien Freche, Nadav Amit, VMware, Inc., linux-mm On 12.03.19 18:14, Matthew Wilcox wrote: > On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >> On 3/12/19 3:59 PM, Julien Grall wrote: >>> It looks like all the arm test for linus [1] and next [2] tree >>> are now failing. x86 seems to be mostly ok. >>> >>> The bisector fingered the following commit: >>> >>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>> Author: Matthew Wilcox <willy@infradead.org> >>> Date: Tue Mar 5 15:46:06 2019 -0800 >>> >>> mm/memory.c: prevent mapping typed pages to userspace >>> Pages which use page_type must never be mapped to userspace as it would >>> destroy their page type. Add an explicit check for this instead of >>> assuming that kernel drivers always get this right. > > Oh good, it found a real problem. > >> It turns out the problem is because the balloon driver will call >> __SetPageOffline() on allocated page. Therefore the page has a type and >> vm_insert_pages will deny the insertion. >> >> My knowledge is quite limited in this area. So I am not sure how we can >> solve the problem. >> >> I would appreciate if someone could provide input of to fix the mapping. > > I don't know the balloon driver, so I don't know why it was doing this, > but what it was doing was Wrong and has been since 2014 with: > > commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 > Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> > Date: Thu Oct 9 15:29:27 2014 -0700 > > mm/balloon_compaction: redesign ballooned pages management > > If ballooned pages are supposed to be mapped into userspace, you can't mark > them as ballooned pages using the mapcount field. > Asking myself why anybody would want to map balloon inflated pages into user space (this just sounds plain wrong but my understanding to what XEN balloon driver does might be limited), but I assume the easy fix would be to revert commit 2f085ff37d08ecbc7849d5abb9424bd7927dda1d Author: David Hildenbrand <david@redhat.com> Date: Wed Mar 6 11:42:24 2019 +1100 xen/balloon: mark inflated pages PG_offline Mark inflated and never onlined pages PG_offline, to tell the world that the content is stale and should not be dumped. -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) @ 2019-03-12 17:18 ` David Hildenbrand 0 siblings, 0 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-12 17:18 UTC (permalink / raw) To: Matthew Wilcox, Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel, Boris Ostrovsky On 12.03.19 18:14, Matthew Wilcox wrote: > On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >> On 3/12/19 3:59 PM, Julien Grall wrote: >>> It looks like all the arm test for linus [1] and next [2] tree >>> are now failing. x86 seems to be mostly ok. >>> >>> The bisector fingered the following commit: >>> >>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>> Author: Matthew Wilcox <willy@infradead.org> >>> Date: Tue Mar 5 15:46:06 2019 -0800 >>> >>> mm/memory.c: prevent mapping typed pages to userspace >>> Pages which use page_type must never be mapped to userspace as it would >>> destroy their page type. Add an explicit check for this instead of >>> assuming that kernel drivers always get this right. > > Oh good, it found a real problem. > >> It turns out the problem is because the balloon driver will call >> __SetPageOffline() on allocated page. Therefore the page has a type and >> vm_insert_pages will deny the insertion. >> >> My knowledge is quite limited in this area. So I am not sure how we can >> solve the problem. >> >> I would appreciate if someone could provide input of to fix the mapping. > > I don't know the balloon driver, so I don't know why it was doing this, > but what it was doing was Wrong and has been since 2014 with: > > commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 > Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> > Date: Thu Oct 9 15:29:27 2014 -0700 > > mm/balloon_compaction: redesign ballooned pages management > > If ballooned pages are supposed to be mapped into userspace, you can't mark > them as ballooned pages using the mapcount field. > Asking myself why anybody would want to map balloon inflated pages into user space (this just sounds plain wrong but my understanding to what XEN balloon driver does might be limited), but I assume the easy fix would be to revert commit 2f085ff37d08ecbc7849d5abb9424bd7927dda1d Author: David Hildenbrand <david@redhat.com> Date: Wed Mar 6 11:42:24 2019 +1100 xen/balloon: mark inflated pages PG_offline Mark inflated and never onlined pages PG_offline, to tell the world that the content is stale and should not be dumped. -- Thanks, David / dhildenb _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:18 ` xen: Can't insert balloon page into VM userspace (WAS " David Hildenbrand (?) @ 2019-03-12 17:24 ` Andrew Cooper -1 siblings, 0 replies; 38+ messages in thread From: Andrew Cooper @ 2019-03-12 17:24 UTC (permalink / raw) To: David Hildenbrand, Matthew Wilcox, Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel, Boris Ostrovsky On 12/03/2019 17:18, David Hildenbrand wrote: > On 12.03.19 18:14, Matthew Wilcox wrote: >> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>> It looks like all the arm test for linus [1] and next [2] tree >>>> are now failing. x86 seems to be mostly ok. >>>> >>>> The bisector fingered the following commit: >>>> >>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>> Author: Matthew Wilcox <willy@infradead.org> >>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>> >>>> mm/memory.c: prevent mapping typed pages to userspace >>>> Pages which use page_type must never be mapped to userspace as it would >>>> destroy their page type. Add an explicit check for this instead of >>>> assuming that kernel drivers always get this right. >> Oh good, it found a real problem. >> >>> It turns out the problem is because the balloon driver will call >>> __SetPageOffline() on allocated page. Therefore the page has a type and >>> vm_insert_pages will deny the insertion. >>> >>> My knowledge is quite limited in this area. So I am not sure how we can >>> solve the problem. >>> >>> I would appreciate if someone could provide input of to fix the mapping. >> I don't know the balloon driver, so I don't know why it was doing this, >> but what it was doing was Wrong and has been since 2014 with: >> >> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >> Date: Thu Oct 9 15:29:27 2014 -0700 >> >> mm/balloon_compaction: redesign ballooned pages management >> >> If ballooned pages are supposed to be mapped into userspace, you can't mark >> them as ballooned pages using the mapcount field. >> > Asking myself why anybody would want to map balloon inflated pages into > user space (this just sounds plain wrong but my understanding to what > XEN balloon driver does might be limited), but I assume the easy fix > would be to revert I suspect the bug here is that the balloon driver is (ab)used for a second purpose - to create a hole in pfn space to map some other bits of shared memory into. I think at the end of the day, what is needed is a struct page_info which looks like normal RAM, but the backing for which can be altered by hypercall to map other things. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Xen-devel] xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:18 ` xen: Can't insert balloon page into VM userspace (WAS " David Hildenbrand (?) (?) @ 2019-03-12 17:24 ` Andrew Cooper 2019-03-12 18:02 ` Boris Ostrovsky 2019-03-12 18:02 ` [Xen-devel] " Boris Ostrovsky -1 siblings, 2 replies; 38+ messages in thread From: Andrew Cooper @ 2019-03-12 17:24 UTC (permalink / raw) To: David Hildenbrand, Matthew Wilcox, Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel, Boris Ostrovsky On 12/03/2019 17:18, David Hildenbrand wrote: > On 12.03.19 18:14, Matthew Wilcox wrote: >> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>> It looks like all the arm test for linus [1] and next [2] tree >>>> are now failing. x86 seems to be mostly ok. >>>> >>>> The bisector fingered the following commit: >>>> >>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>> Author: Matthew Wilcox <willy@infradead.org> >>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>> >>>> mm/memory.c: prevent mapping typed pages to userspace >>>> Pages which use page_type must never be mapped to userspace as it would >>>> destroy their page type. Add an explicit check for this instead of >>>> assuming that kernel drivers always get this right. >> Oh good, it found a real problem. >> >>> It turns out the problem is because the balloon driver will call >>> __SetPageOffline() on allocated page. Therefore the page has a type and >>> vm_insert_pages will deny the insertion. >>> >>> My knowledge is quite limited in this area. So I am not sure how we can >>> solve the problem. >>> >>> I would appreciate if someone could provide input of to fix the mapping. >> I don't know the balloon driver, so I don't know why it was doing this, >> but what it was doing was Wrong and has been since 2014 with: >> >> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >> Date: Thu Oct 9 15:29:27 2014 -0700 >> >> mm/balloon_compaction: redesign ballooned pages management >> >> If ballooned pages are supposed to be mapped into userspace, you can't mark >> them as ballooned pages using the mapcount field. >> > Asking myself why anybody would want to map balloon inflated pages into > user space (this just sounds plain wrong but my understanding to what > XEN balloon driver does might be limited), but I assume the easy fix > would be to revert I suspect the bug here is that the balloon driver is (ab)used for a second purpose - to create a hole in pfn space to map some other bits of shared memory into. I think at the end of the day, what is needed is a struct page_info which looks like normal RAM, but the backing for which can be altered by hypercall to map other things. ~Andrew ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:24 ` [Xen-devel] " Andrew Cooper @ 2019-03-12 18:02 ` Boris Ostrovsky 2019-03-12 18:02 ` [Xen-devel] " Boris Ostrovsky 1 sibling, 0 replies; 38+ messages in thread From: Boris Ostrovsky @ 2019-03-12 18:02 UTC (permalink / raw) To: Andrew Cooper, David Hildenbrand, Matthew Wilcox, Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 3/12/19 1:24 PM, Andrew Cooper wrote: > On 12/03/2019 17:18, David Hildenbrand wrote: >> On 12.03.19 18:14, Matthew Wilcox wrote: >>> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>>> It looks like all the arm test for linus [1] and next [2] tree >>>>> are now failing. x86 seems to be mostly ok. >>>>> >>>>> The bisector fingered the following commit: >>>>> >>>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>>> Author: Matthew Wilcox <willy@infradead.org> >>>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>>> >>>>> mm/memory.c: prevent mapping typed pages to userspace >>>>> Pages which use page_type must never be mapped to userspace as it would >>>>> destroy their page type. Add an explicit check for this instead of >>>>> assuming that kernel drivers always get this right. >>> Oh good, it found a real problem. >>> >>>> It turns out the problem is because the balloon driver will call >>>> __SetPageOffline() on allocated page. Therefore the page has a type and >>>> vm_insert_pages will deny the insertion. >>>> >>>> My knowledge is quite limited in this area. So I am not sure how we can >>>> solve the problem. >>>> >>>> I would appreciate if someone could provide input of to fix the mapping. >>> I don't know the balloon driver, so I don't know why it was doing this, >>> but what it was doing was Wrong and has been since 2014 with: >>> >>> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >>> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >>> Date: Thu Oct 9 15:29:27 2014 -0700 >>> >>> mm/balloon_compaction: redesign ballooned pages management >>> >>> If ballooned pages are supposed to be mapped into userspace, you can't mark >>> them as ballooned pages using the mapcount field. >>> >> Asking myself why anybody would want to map balloon inflated pages into >> user space (this just sounds plain wrong but my understanding to what >> XEN balloon driver does might be limited), but I assume the easy fix >> would be to revert > I suspect the bug here is that the balloon driver is (ab)used for a > second purpose Yes. And its name is alloc_xenballooned_pages(). -boris > - to create a hole in pfn space to map some other bits of > shared memory into. > > I think at the end of the day, what is needed is a struct page_info > which looks like normal RAM, but the backing for which can be altered by > hypercall to map other things. > > ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Xen-devel] xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:24 ` [Xen-devel] " Andrew Cooper 2019-03-12 18:02 ` Boris Ostrovsky @ 2019-03-12 18:02 ` Boris Ostrovsky 2019-03-12 18:11 ` Andrew Cooper ` (3 more replies) 1 sibling, 4 replies; 38+ messages in thread From: Boris Ostrovsky @ 2019-03-12 18:02 UTC (permalink / raw) To: Andrew Cooper, David Hildenbrand, Matthew Wilcox, Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 3/12/19 1:24 PM, Andrew Cooper wrote: > On 12/03/2019 17:18, David Hildenbrand wrote: >> On 12.03.19 18:14, Matthew Wilcox wrote: >>> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>>> It looks like all the arm test for linus [1] and next [2] tree >>>>> are now failing. x86 seems to be mostly ok. >>>>> >>>>> The bisector fingered the following commit: >>>>> >>>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>>> Author: Matthew Wilcox <willy@infradead.org> >>>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>>> >>>>> mm/memory.c: prevent mapping typed pages to userspace >>>>> Pages which use page_type must never be mapped to userspace as it would >>>>> destroy their page type. Add an explicit check for this instead of >>>>> assuming that kernel drivers always get this right. >>> Oh good, it found a real problem. >>> >>>> It turns out the problem is because the balloon driver will call >>>> __SetPageOffline() on allocated page. Therefore the page has a type and >>>> vm_insert_pages will deny the insertion. >>>> >>>> My knowledge is quite limited in this area. So I am not sure how we can >>>> solve the problem. >>>> >>>> I would appreciate if someone could provide input of to fix the mapping. >>> I don't know the balloon driver, so I don't know why it was doing this, >>> but what it was doing was Wrong and has been since 2014 with: >>> >>> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >>> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >>> Date: Thu Oct 9 15:29:27 2014 -0700 >>> >>> mm/balloon_compaction: redesign ballooned pages management >>> >>> If ballooned pages are supposed to be mapped into userspace, you can't mark >>> them as ballooned pages using the mapcount field. >>> >> Asking myself why anybody would want to map balloon inflated pages into >> user space (this just sounds plain wrong but my understanding to what >> XEN balloon driver does might be limited), but I assume the easy fix >> would be to revert > I suspect the bug here is that the balloon driver is (ab)used for a > second purpose Yes. And its name is alloc_xenballooned_pages(). -boris > - to create a hole in pfn space to map some other bits of > shared memory into. > > I think at the end of the day, what is needed is a struct page_info > which looks like normal RAM, but the backing for which can be altered by > hypercall to map other things. > > ~Andrew ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 18:02 ` [Xen-devel] " Boris Ostrovsky @ 2019-03-12 18:11 ` Andrew Cooper 2019-03-12 18:11 ` [Xen-devel] " Andrew Cooper ` (2 subsequent siblings) 3 siblings, 0 replies; 38+ messages in thread From: Andrew Cooper @ 2019-03-12 18:11 UTC (permalink / raw) To: Boris Ostrovsky, David Hildenbrand, Matthew Wilcox, Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 12/03/2019 18:02, Boris Ostrovsky wrote: > On 3/12/19 1:24 PM, Andrew Cooper wrote: >> On 12/03/2019 17:18, David Hildenbrand wrote: >>> On 12.03.19 18:14, Matthew Wilcox wrote: >>>> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>>>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>>>> It looks like all the arm test for linus [1] and next [2] tree >>>>>> are now failing. x86 seems to be mostly ok. >>>>>> >>>>>> The bisector fingered the following commit: >>>>>> >>>>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>>>> Author: Matthew Wilcox <willy@infradead.org> >>>>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>>>> >>>>>> mm/memory.c: prevent mapping typed pages to userspace >>>>>> Pages which use page_type must never be mapped to userspace as it would >>>>>> destroy their page type. Add an explicit check for this instead of >>>>>> assuming that kernel drivers always get this right. >>>> Oh good, it found a real problem. >>>> >>>>> It turns out the problem is because the balloon driver will call >>>>> __SetPageOffline() on allocated page. Therefore the page has a type and >>>>> vm_insert_pages will deny the insertion. >>>>> >>>>> My knowledge is quite limited in this area. So I am not sure how we can >>>>> solve the problem. >>>>> >>>>> I would appreciate if someone could provide input of to fix the mapping. >>>> I don't know the balloon driver, so I don't know why it was doing this, >>>> but what it was doing was Wrong and has been since 2014 with: >>>> >>>> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >>>> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >>>> Date: Thu Oct 9 15:29:27 2014 -0700 >>>> >>>> mm/balloon_compaction: redesign ballooned pages management >>>> >>>> If ballooned pages are supposed to be mapped into userspace, you can't mark >>>> them as ballooned pages using the mapcount field. >>>> >>> Asking myself why anybody would want to map balloon inflated pages into >>> user space (this just sounds plain wrong but my understanding to what >>> XEN balloon driver does might be limited), but I assume the easy fix >>> would be to revert >> I suspect the bug here is that the balloon driver is (ab)used for a >> second purpose > Yes. And its name is alloc_xenballooned_pages(). FWIW, I did express my views that this was a BadIdea(tm) when that logic was first introduced. But yes - now is clearly the time to fix this properly. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Xen-devel] xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 18:02 ` [Xen-devel] " Boris Ostrovsky 2019-03-12 18:11 ` Andrew Cooper @ 2019-03-12 18:11 ` Andrew Cooper 2019-03-12 18:23 ` David Hildenbrand 2019-03-12 18:23 ` [Xen-devel] " David Hildenbrand 3 siblings, 0 replies; 38+ messages in thread From: Andrew Cooper @ 2019-03-12 18:11 UTC (permalink / raw) To: Boris Ostrovsky, David Hildenbrand, Matthew Wilcox, Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 12/03/2019 18:02, Boris Ostrovsky wrote: > On 3/12/19 1:24 PM, Andrew Cooper wrote: >> On 12/03/2019 17:18, David Hildenbrand wrote: >>> On 12.03.19 18:14, Matthew Wilcox wrote: >>>> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>>>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>>>> It looks like all the arm test for linus [1] and next [2] tree >>>>>> are now failing. x86 seems to be mostly ok. >>>>>> >>>>>> The bisector fingered the following commit: >>>>>> >>>>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>>>> Author: Matthew Wilcox <willy@infradead.org> >>>>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>>>> >>>>>> mm/memory.c: prevent mapping typed pages to userspace >>>>>> Pages which use page_type must never be mapped to userspace as it would >>>>>> destroy their page type. Add an explicit check for this instead of >>>>>> assuming that kernel drivers always get this right. >>>> Oh good, it found a real problem. >>>> >>>>> It turns out the problem is because the balloon driver will call >>>>> __SetPageOffline() on allocated page. Therefore the page has a type and >>>>> vm_insert_pages will deny the insertion. >>>>> >>>>> My knowledge is quite limited in this area. So I am not sure how we can >>>>> solve the problem. >>>>> >>>>> I would appreciate if someone could provide input of to fix the mapping. >>>> I don't know the balloon driver, so I don't know why it was doing this, >>>> but what it was doing was Wrong and has been since 2014 with: >>>> >>>> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >>>> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >>>> Date: Thu Oct 9 15:29:27 2014 -0700 >>>> >>>> mm/balloon_compaction: redesign ballooned pages management >>>> >>>> If ballooned pages are supposed to be mapped into userspace, you can't mark >>>> them as ballooned pages using the mapcount field. >>>> >>> Asking myself why anybody would want to map balloon inflated pages into >>> user space (this just sounds plain wrong but my understanding to what >>> XEN balloon driver does might be limited), but I assume the easy fix >>> would be to revert >> I suspect the bug here is that the balloon driver is (ab)used for a >> second purpose > Yes. And its name is alloc_xenballooned_pages(). FWIW, I did express my views that this was a BadIdea(tm) when that logic was first introduced. But yes - now is clearly the time to fix this properly. ~Andrew ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 18:02 ` [Xen-devel] " Boris Ostrovsky 2019-03-12 18:11 ` Andrew Cooper 2019-03-12 18:11 ` [Xen-devel] " Andrew Cooper @ 2019-03-12 18:23 ` David Hildenbrand 2019-03-12 18:23 ` [Xen-devel] " David Hildenbrand 3 siblings, 0 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-12 18:23 UTC (permalink / raw) To: Boris Ostrovsky, Andrew Cooper, Matthew Wilcox, Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 12.03.19 19:02, Boris Ostrovsky wrote: > On 3/12/19 1:24 PM, Andrew Cooper wrote: >> On 12/03/2019 17:18, David Hildenbrand wrote: >>> On 12.03.19 18:14, Matthew Wilcox wrote: >>>> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>>>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>>>> It looks like all the arm test for linus [1] and next [2] tree >>>>>> are now failing. x86 seems to be mostly ok. >>>>>> >>>>>> The bisector fingered the following commit: >>>>>> >>>>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>>>> Author: Matthew Wilcox <willy@infradead.org> >>>>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>>>> >>>>>> mm/memory.c: prevent mapping typed pages to userspace >>>>>> Pages which use page_type must never be mapped to userspace as it would >>>>>> destroy their page type. Add an explicit check for this instead of >>>>>> assuming that kernel drivers always get this right. >>>> Oh good, it found a real problem. >>>> >>>>> It turns out the problem is because the balloon driver will call >>>>> __SetPageOffline() on allocated page. Therefore the page has a type and >>>>> vm_insert_pages will deny the insertion. >>>>> >>>>> My knowledge is quite limited in this area. So I am not sure how we can >>>>> solve the problem. >>>>> >>>>> I would appreciate if someone could provide input of to fix the mapping. >>>> I don't know the balloon driver, so I don't know why it was doing this, >>>> but what it was doing was Wrong and has been since 2014 with: >>>> >>>> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >>>> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >>>> Date: Thu Oct 9 15:29:27 2014 -0700 >>>> >>>> mm/balloon_compaction: redesign ballooned pages management >>>> >>>> If ballooned pages are supposed to be mapped into userspace, you can't mark >>>> them as ballooned pages using the mapcount field. >>>> >>> Asking myself why anybody would want to map balloon inflated pages into >>> user space (this just sounds plain wrong but my understanding to what >>> XEN balloon driver does might be limited), but I assume the easy fix >>> would be to revert >> I suspect the bug here is that the balloon driver is (ab)used for a >> second purpose > > Yes. And its name is alloc_xenballooned_pages(). > Haven't had a look at the code yet, but would another temporary fix be to clear/set PG_offline when allocating/freeing a ballooned page? (assuming here that only such pages will be mapped to user space) -- Thanks, David / dhildenb _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Xen-devel] xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 18:02 ` [Xen-devel] " Boris Ostrovsky ` (2 preceding siblings ...) 2019-03-12 18:23 ` David Hildenbrand @ 2019-03-12 18:23 ` David Hildenbrand 2019-03-12 19:46 ` David Hildenbrand 2019-03-12 19:46 ` David Hildenbrand 3 siblings, 2 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-12 18:23 UTC (permalink / raw) To: Boris Ostrovsky, Andrew Cooper, Matthew Wilcox, Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 12.03.19 19:02, Boris Ostrovsky wrote: > On 3/12/19 1:24 PM, Andrew Cooper wrote: >> On 12/03/2019 17:18, David Hildenbrand wrote: >>> On 12.03.19 18:14, Matthew Wilcox wrote: >>>> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>>>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>>>> It looks like all the arm test for linus [1] and next [2] tree >>>>>> are now failing. x86 seems to be mostly ok. >>>>>> >>>>>> The bisector fingered the following commit: >>>>>> >>>>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>>>> Author: Matthew Wilcox <willy@infradead.org> >>>>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>>>> >>>>>> mm/memory.c: prevent mapping typed pages to userspace >>>>>> Pages which use page_type must never be mapped to userspace as it would >>>>>> destroy their page type. Add an explicit check for this instead of >>>>>> assuming that kernel drivers always get this right. >>>> Oh good, it found a real problem. >>>> >>>>> It turns out the problem is because the balloon driver will call >>>>> __SetPageOffline() on allocated page. Therefore the page has a type and >>>>> vm_insert_pages will deny the insertion. >>>>> >>>>> My knowledge is quite limited in this area. So I am not sure how we can >>>>> solve the problem. >>>>> >>>>> I would appreciate if someone could provide input of to fix the mapping. >>>> I don't know the balloon driver, so I don't know why it was doing this, >>>> but what it was doing was Wrong and has been since 2014 with: >>>> >>>> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >>>> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >>>> Date: Thu Oct 9 15:29:27 2014 -0700 >>>> >>>> mm/balloon_compaction: redesign ballooned pages management >>>> >>>> If ballooned pages are supposed to be mapped into userspace, you can't mark >>>> them as ballooned pages using the mapcount field. >>>> >>> Asking myself why anybody would want to map balloon inflated pages into >>> user space (this just sounds plain wrong but my understanding to what >>> XEN balloon driver does might be limited), but I assume the easy fix >>> would be to revert >> I suspect the bug here is that the balloon driver is (ab)used for a >> second purpose > > Yes. And its name is alloc_xenballooned_pages(). > Haven't had a look at the code yet, but would another temporary fix be to clear/set PG_offline when allocating/freeing a ballooned page? (assuming here that only such pages will be mapped to user space) -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Xen-devel] xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 18:23 ` [Xen-devel] " David Hildenbrand @ 2019-03-12 19:46 ` David Hildenbrand 2019-03-14 8:37 ` Juergen Gross 2019-03-14 8:37 ` Juergen Gross 2019-03-12 19:46 ` David Hildenbrand 1 sibling, 2 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-12 19:46 UTC (permalink / raw) To: Boris Ostrovsky, Andrew Cooper, Matthew Wilcox, Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 12.03.19 19:23, David Hildenbrand wrote: > On 12.03.19 19:02, Boris Ostrovsky wrote: >> On 3/12/19 1:24 PM, Andrew Cooper wrote: >>> On 12/03/2019 17:18, David Hildenbrand wrote: >>>> On 12.03.19 18:14, Matthew Wilcox wrote: >>>>> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>>>>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>>>>> It looks like all the arm test for linus [1] and next [2] tree >>>>>>> are now failing. x86 seems to be mostly ok. >>>>>>> >>>>>>> The bisector fingered the following commit: >>>>>>> >>>>>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>>>>> Author: Matthew Wilcox <willy@infradead.org> >>>>>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>>>>> >>>>>>> mm/memory.c: prevent mapping typed pages to userspace >>>>>>> Pages which use page_type must never be mapped to userspace as it would >>>>>>> destroy their page type. Add an explicit check for this instead of >>>>>>> assuming that kernel drivers always get this right. >>>>> Oh good, it found a real problem. >>>>> >>>>>> It turns out the problem is because the balloon driver will call >>>>>> __SetPageOffline() on allocated page. Therefore the page has a type and >>>>>> vm_insert_pages will deny the insertion. >>>>>> >>>>>> My knowledge is quite limited in this area. So I am not sure how we can >>>>>> solve the problem. >>>>>> >>>>>> I would appreciate if someone could provide input of to fix the mapping. >>>>> I don't know the balloon driver, so I don't know why it was doing this, >>>>> but what it was doing was Wrong and has been since 2014 with: >>>>> >>>>> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >>>>> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >>>>> Date: Thu Oct 9 15:29:27 2014 -0700 >>>>> >>>>> mm/balloon_compaction: redesign ballooned pages management >>>>> >>>>> If ballooned pages are supposed to be mapped into userspace, you can't mark >>>>> them as ballooned pages using the mapcount field. >>>>> >>>> Asking myself why anybody would want to map balloon inflated pages into >>>> user space (this just sounds plain wrong but my understanding to what >>>> XEN balloon driver does might be limited), but I assume the easy fix >>>> would be to revert >>> I suspect the bug here is that the balloon driver is (ab)used for a >>> second purpose >> >> Yes. And its name is alloc_xenballooned_pages(). >> > > Haven't had a look at the code yet, but would another temporary fix be > to clear/set PG_offline when allocating/freeing a ballooned page? > (assuming here that only such pages will be mapped to user space) > I guess something like this could do the trick if I understood it correctly: diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 39b229f9e256..d37dd5bb7a8f 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -604,6 +604,7 @@ int alloc_xenballooned_pages(int nr_pages, struct page **pages) while (pgno < nr_pages) { page = balloon_retrieve(true); if (page) { + __ClearPageOffline(page); pages[pgno++] = page; #ifdef CONFIG_XEN_HAVE_PVMMU /* @@ -645,8 +646,10 @@ void free_xenballooned_pages(int nr_pages, struct page **pages) mutex_lock(&balloon_mutex); for (i = 0; i < nr_pages; i++) { - if (pages[i]) + if (pages[i]) { + __SetPageOffline(pages[i]); balloon_append(pages[i]); + } } balloon_stats.target_unpopulated -= nr_pages; At least this way, the pages allocated (and thus eventually mapped to user space) would not be marked, but the other ones would remain marked and could be excluded by makedumptool. -- Thanks, David / dhildenb ^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [Xen-devel] xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 19:46 ` David Hildenbrand @ 2019-03-14 8:37 ` Juergen Gross 2019-03-14 14:12 ` Julien Grall 2019-03-14 14:12 ` [Xen-devel] " Julien Grall 2019-03-14 8:37 ` Juergen Gross 1 sibling, 2 replies; 38+ messages in thread From: Juergen Gross @ 2019-03-14 8:37 UTC (permalink / raw) To: David Hildenbrand, Boris Ostrovsky, Andrew Cooper, Matthew Wilcox, Julien Grall Cc: k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 12/03/2019 20:46, David Hildenbrand wrote: > On 12.03.19 19:23, David Hildenbrand wrote: >> On 12.03.19 19:02, Boris Ostrovsky wrote: >>> On 3/12/19 1:24 PM, Andrew Cooper wrote: >>>> On 12/03/2019 17:18, David Hildenbrand wrote: >>>>> On 12.03.19 18:14, Matthew Wilcox wrote: >>>>>> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>>>>>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>>>>>> It looks like all the arm test for linus [1] and next [2] tree >>>>>>>> are now failing. x86 seems to be mostly ok. >>>>>>>> >>>>>>>> The bisector fingered the following commit: >>>>>>>> >>>>>>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>>>>>> Author: Matthew Wilcox <willy@infradead.org> >>>>>>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>>>>>> >>>>>>>> mm/memory.c: prevent mapping typed pages to userspace >>>>>>>> Pages which use page_type must never be mapped to userspace as it would >>>>>>>> destroy their page type. Add an explicit check for this instead of >>>>>>>> assuming that kernel drivers always get this right. >>>>>> Oh good, it found a real problem. >>>>>> >>>>>>> It turns out the problem is because the balloon driver will call >>>>>>> __SetPageOffline() on allocated page. Therefore the page has a type and >>>>>>> vm_insert_pages will deny the insertion. >>>>>>> >>>>>>> My knowledge is quite limited in this area. So I am not sure how we can >>>>>>> solve the problem. >>>>>>> >>>>>>> I would appreciate if someone could provide input of to fix the mapping. >>>>>> I don't know the balloon driver, so I don't know why it was doing this, >>>>>> but what it was doing was Wrong and has been since 2014 with: >>>>>> >>>>>> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >>>>>> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >>>>>> Date: Thu Oct 9 15:29:27 2014 -0700 >>>>>> >>>>>> mm/balloon_compaction: redesign ballooned pages management >>>>>> >>>>>> If ballooned pages are supposed to be mapped into userspace, you can't mark >>>>>> them as ballooned pages using the mapcount field. >>>>>> >>>>> Asking myself why anybody would want to map balloon inflated pages into >>>>> user space (this just sounds plain wrong but my understanding to what >>>>> XEN balloon driver does might be limited), but I assume the easy fix >>>>> would be to revert >>>> I suspect the bug here is that the balloon driver is (ab)used for a >>>> second purpose >>> >>> Yes. And its name is alloc_xenballooned_pages(). >>> >> >> Haven't had a look at the code yet, but would another temporary fix be >> to clear/set PG_offline when allocating/freeing a ballooned page? >> (assuming here that only such pages will be mapped to user space) >> > > I guess something like this could do the trick if I understood it correctly: > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 39b229f9e256..d37dd5bb7a8f 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -604,6 +604,7 @@ int alloc_xenballooned_pages(int nr_pages, struct > page **pages) > while (pgno < nr_pages) { > page = balloon_retrieve(true); > if (page) { > + __ClearPageOffline(page); > pages[pgno++] = page; > #ifdef CONFIG_XEN_HAVE_PVMMU > /* > @@ -645,8 +646,10 @@ void free_xenballooned_pages(int nr_pages, struct > page **pages) > mutex_lock(&balloon_mutex); > > for (i = 0; i < nr_pages; i++) { > - if (pages[i]) > + if (pages[i]) { > + __SetPageOffline(pages[i]); > balloon_append(pages[i]); > + } > } > > balloon_stats.target_unpopulated -= nr_pages; > > > At least this way, the pages allocated (and thus eventually mapped to > user space) would not be marked, but the other ones would remain marked > and could be excluded by makedumptool. > I think this patch should do the trick. Julien, could you give it a try? On x86 I can't reproduce your problem easily as dom0 is PV with plenty of unpopulated pages for grant memory not suffering from missing "offline" bit. Juergen ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-14 8:37 ` Juergen Gross @ 2019-03-14 14:12 ` Julien Grall 2019-03-14 14:12 ` [Xen-devel] " Julien Grall 1 sibling, 0 replies; 38+ messages in thread From: Julien Grall @ 2019-03-14 14:12 UTC (permalink / raw) To: Juergen Gross, David Hildenbrand, Boris Ostrovsky, Andrew Cooper, Matthew Wilcox Cc: k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel Hi, On 3/14/19 8:37 AM, Juergen Gross wrote: > On 12/03/2019 20:46, David Hildenbrand wrote: >> On 12.03.19 19:23, David Hildenbrand wrote: >> >> I guess something like this could do the trick if I understood it correctly: >> >> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c >> index 39b229f9e256..d37dd5bb7a8f 100644 >> --- a/drivers/xen/balloon.c >> +++ b/drivers/xen/balloon.c >> @@ -604,6 +604,7 @@ int alloc_xenballooned_pages(int nr_pages, struct >> page **pages) >> while (pgno < nr_pages) { >> page = balloon_retrieve(true); >> if (page) { >> + __ClearPageOffline(page); >> pages[pgno++] = page; >> #ifdef CONFIG_XEN_HAVE_PVMMU >> /* >> @@ -645,8 +646,10 @@ void free_xenballooned_pages(int nr_pages, struct >> page **pages) >> mutex_lock(&balloon_mutex); >> >> for (i = 0; i < nr_pages; i++) { >> - if (pages[i]) >> + if (pages[i]) { >> + __SetPageOffline(pages[i]); >> balloon_append(pages[i]); >> + } >> } >> >> balloon_stats.target_unpopulated -= nr_pages; >> >> >> At least this way, the pages allocated (and thus eventually mapped to >> user space) would not be marked, but the other ones would remain marked >> and could be excluded by makedumptool. >> > > I think this patch should do the trick. Julien, could you give it a > try? On x86 I can't reproduce your problem easily as dom0 is PV with > plenty of unpopulated pages for grant memory not suffering from > missing "offline" bit. Sure. I managed to get the console working with the patch suggested by David. Feel free to add my tested-by if when you resend it as is. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Xen-devel] xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-14 8:37 ` Juergen Gross 2019-03-14 14:12 ` Julien Grall @ 2019-03-14 14:12 ` Julien Grall 2019-03-14 14:14 ` David Hildenbrand ` (3 more replies) 1 sibling, 4 replies; 38+ messages in thread From: Julien Grall @ 2019-03-14 14:12 UTC (permalink / raw) To: Juergen Gross, David Hildenbrand, Boris Ostrovsky, Andrew Cooper, Matthew Wilcox Cc: k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel Hi, On 3/14/19 8:37 AM, Juergen Gross wrote: > On 12/03/2019 20:46, David Hildenbrand wrote: >> On 12.03.19 19:23, David Hildenbrand wrote: >> >> I guess something like this could do the trick if I understood it correctly: >> >> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c >> index 39b229f9e256..d37dd5bb7a8f 100644 >> --- a/drivers/xen/balloon.c >> +++ b/drivers/xen/balloon.c >> @@ -604,6 +604,7 @@ int alloc_xenballooned_pages(int nr_pages, struct >> page **pages) >> while (pgno < nr_pages) { >> page = balloon_retrieve(true); >> if (page) { >> + __ClearPageOffline(page); >> pages[pgno++] = page; >> #ifdef CONFIG_XEN_HAVE_PVMMU >> /* >> @@ -645,8 +646,10 @@ void free_xenballooned_pages(int nr_pages, struct >> page **pages) >> mutex_lock(&balloon_mutex); >> >> for (i = 0; i < nr_pages; i++) { >> - if (pages[i]) >> + if (pages[i]) { >> + __SetPageOffline(pages[i]); >> balloon_append(pages[i]); >> + } >> } >> >> balloon_stats.target_unpopulated -= nr_pages; >> >> >> At least this way, the pages allocated (and thus eventually mapped to >> user space) would not be marked, but the other ones would remain marked >> and could be excluded by makedumptool. >> > > I think this patch should do the trick. Julien, could you give it a > try? On x86 I can't reproduce your problem easily as dom0 is PV with > plenty of unpopulated pages for grant memory not suffering from > missing "offline" bit. Sure. I managed to get the console working with the patch suggested by David. Feel free to add my tested-by if when you resend it as is. Cheers, -- Julien Grall ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-14 14:12 ` [Xen-devel] " Julien Grall @ 2019-03-14 14:14 ` David Hildenbrand 2019-03-14 14:14 ` [Xen-devel] " David Hildenbrand ` (2 subsequent siblings) 3 siblings, 0 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-14 14:14 UTC (permalink / raw) To: Julien Grall, Juergen Gross, Boris Ostrovsky, Andrew Cooper, Matthew Wilcox Cc: k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 14.03.19 15:12, Julien Grall wrote: > Hi, > > On 3/14/19 8:37 AM, Juergen Gross wrote: >> On 12/03/2019 20:46, David Hildenbrand wrote: >>> On 12.03.19 19:23, David Hildenbrand wrote: >>> >>> I guess something like this could do the trick if I understood it correctly: >>> >>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c >>> index 39b229f9e256..d37dd5bb7a8f 100644 >>> --- a/drivers/xen/balloon.c >>> +++ b/drivers/xen/balloon.c >>> @@ -604,6 +604,7 @@ int alloc_xenballooned_pages(int nr_pages, struct >>> page **pages) >>> while (pgno < nr_pages) { >>> page = balloon_retrieve(true); >>> if (page) { >>> + __ClearPageOffline(page); >>> pages[pgno++] = page; >>> #ifdef CONFIG_XEN_HAVE_PVMMU >>> /* >>> @@ -645,8 +646,10 @@ void free_xenballooned_pages(int nr_pages, struct >>> page **pages) >>> mutex_lock(&balloon_mutex); >>> >>> for (i = 0; i < nr_pages; i++) { >>> - if (pages[i]) >>> + if (pages[i]) { >>> + __SetPageOffline(pages[i]); >>> balloon_append(pages[i]); >>> + } >>> } >>> >>> balloon_stats.target_unpopulated -= nr_pages; >>> >>> >>> At least this way, the pages allocated (and thus eventually mapped to >>> user space) would not be marked, but the other ones would remain marked >>> and could be excluded by makedumptool. >>> >> >> I think this patch should do the trick. Julien, could you give it a >> try? On x86 I can't reproduce your problem easily as dom0 is PV with >> plenty of unpopulated pages for grant memory not suffering from >> missing "offline" bit. > > Sure. I managed to get the console working with the patch suggested by > David. Feel free to add my tested-by if when you resend it as is. > Thanks, I will send as proper patch later! Cheers! > Cheers, > -- Thanks, David / dhildenb _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Xen-devel] xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-14 14:12 ` [Xen-devel] " Julien Grall 2019-03-14 14:14 ` David Hildenbrand @ 2019-03-14 14:14 ` David Hildenbrand 2019-03-14 14:15 ` Juergen Gross 2019-03-14 14:15 ` Juergen Gross 3 siblings, 0 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-14 14:14 UTC (permalink / raw) To: Julien Grall, Juergen Gross, Boris Ostrovsky, Andrew Cooper, Matthew Wilcox Cc: k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 14.03.19 15:12, Julien Grall wrote: > Hi, > > On 3/14/19 8:37 AM, Juergen Gross wrote: >> On 12/03/2019 20:46, David Hildenbrand wrote: >>> On 12.03.19 19:23, David Hildenbrand wrote: >>> >>> I guess something like this could do the trick if I understood it correctly: >>> >>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c >>> index 39b229f9e256..d37dd5bb7a8f 100644 >>> --- a/drivers/xen/balloon.c >>> +++ b/drivers/xen/balloon.c >>> @@ -604,6 +604,7 @@ int alloc_xenballooned_pages(int nr_pages, struct >>> page **pages) >>> while (pgno < nr_pages) { >>> page = balloon_retrieve(true); >>> if (page) { >>> + __ClearPageOffline(page); >>> pages[pgno++] = page; >>> #ifdef CONFIG_XEN_HAVE_PVMMU >>> /* >>> @@ -645,8 +646,10 @@ void free_xenballooned_pages(int nr_pages, struct >>> page **pages) >>> mutex_lock(&balloon_mutex); >>> >>> for (i = 0; i < nr_pages; i++) { >>> - if (pages[i]) >>> + if (pages[i]) { >>> + __SetPageOffline(pages[i]); >>> balloon_append(pages[i]); >>> + } >>> } >>> >>> balloon_stats.target_unpopulated -= nr_pages; >>> >>> >>> At least this way, the pages allocated (and thus eventually mapped to >>> user space) would not be marked, but the other ones would remain marked >>> and could be excluded by makedumptool. >>> >> >> I think this patch should do the trick. Julien, could you give it a >> try? On x86 I can't reproduce your problem easily as dom0 is PV with >> plenty of unpopulated pages for grant memory not suffering from >> missing "offline" bit. > > Sure. I managed to get the console working with the patch suggested by > David. Feel free to add my tested-by if when you resend it as is. > Thanks, I will send as proper patch later! Cheers! > Cheers, > -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Xen-devel] xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-14 14:12 ` [Xen-devel] " Julien Grall 2019-03-14 14:14 ` David Hildenbrand 2019-03-14 14:14 ` [Xen-devel] " David Hildenbrand @ 2019-03-14 14:15 ` Juergen Gross 2019-03-14 14:16 ` David Hildenbrand 2019-03-14 14:16 ` [Xen-devel] " David Hildenbrand 2019-03-14 14:15 ` Juergen Gross 3 siblings, 2 replies; 38+ messages in thread From: Juergen Gross @ 2019-03-14 14:15 UTC (permalink / raw) To: Julien Grall, David Hildenbrand, Boris Ostrovsky, Andrew Cooper, Matthew Wilcox Cc: k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 14/03/2019 15:12, Julien Grall wrote: > Hi, > > On 3/14/19 8:37 AM, Juergen Gross wrote: >> On 12/03/2019 20:46, David Hildenbrand wrote: >>> On 12.03.19 19:23, David Hildenbrand wrote: >>> >>> I guess something like this could do the trick if I understood it >>> correctly: >>> >>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c >>> index 39b229f9e256..d37dd5bb7a8f 100644 >>> --- a/drivers/xen/balloon.c >>> +++ b/drivers/xen/balloon.c >>> @@ -604,6 +604,7 @@ int alloc_xenballooned_pages(int nr_pages, struct >>> page **pages) >>> while (pgno < nr_pages) { >>> page = balloon_retrieve(true); >>> if (page) { >>> + __ClearPageOffline(page); >>> pages[pgno++] = page; >>> #ifdef CONFIG_XEN_HAVE_PVMMU >>> /* >>> @@ -645,8 +646,10 @@ void free_xenballooned_pages(int nr_pages, struct >>> page **pages) >>> mutex_lock(&balloon_mutex); >>> >>> for (i = 0; i < nr_pages; i++) { >>> - if (pages[i]) >>> + if (pages[i]) { >>> + __SetPageOffline(pages[i]); >>> balloon_append(pages[i]); >>> + } >>> } >>> >>> balloon_stats.target_unpopulated -= nr_pages; >>> >>> >>> At least this way, the pages allocated (and thus eventually mapped to >>> user space) would not be marked, but the other ones would remain marked >>> and could be excluded by makedumptool. >>> >> >> I think this patch should do the trick. Julien, could you give it a >> try? On x86 I can't reproduce your problem easily as dom0 is PV with >> plenty of unpopulated pages for grant memory not suffering from >> missing "offline" bit. > > Sure. I managed to get the console working with the patch suggested by > David. Feel free to add my tested-by if when you resend it as is. David, could you please send a proper patch with your Sob? Juergen ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-14 14:15 ` Juergen Gross @ 2019-03-14 14:16 ` David Hildenbrand 2019-03-14 14:16 ` [Xen-devel] " David Hildenbrand 1 sibling, 0 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-14 14:16 UTC (permalink / raw) To: Juergen Gross, Julien Grall, Boris Ostrovsky, Andrew Cooper, Matthew Wilcox Cc: k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 14.03.19 15:15, Juergen Gross wrote: > On 14/03/2019 15:12, Julien Grall wrote: >> Hi, >> >> On 3/14/19 8:37 AM, Juergen Gross wrote: >>> On 12/03/2019 20:46, David Hildenbrand wrote: >>>> On 12.03.19 19:23, David Hildenbrand wrote: >>>> >>>> I guess something like this could do the trick if I understood it >>>> correctly: >>>> >>>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c >>>> index 39b229f9e256..d37dd5bb7a8f 100644 >>>> --- a/drivers/xen/balloon.c >>>> +++ b/drivers/xen/balloon.c >>>> @@ -604,6 +604,7 @@ int alloc_xenballooned_pages(int nr_pages, struct >>>> page **pages) >>>> while (pgno < nr_pages) { >>>> page = balloon_retrieve(true); >>>> if (page) { >>>> + __ClearPageOffline(page); >>>> pages[pgno++] = page; >>>> #ifdef CONFIG_XEN_HAVE_PVMMU >>>> /* >>>> @@ -645,8 +646,10 @@ void free_xenballooned_pages(int nr_pages, struct >>>> page **pages) >>>> mutex_lock(&balloon_mutex); >>>> >>>> for (i = 0; i < nr_pages; i++) { >>>> - if (pages[i]) >>>> + if (pages[i]) { >>>> + __SetPageOffline(pages[i]); >>>> balloon_append(pages[i]); >>>> + } >>>> } >>>> >>>> balloon_stats.target_unpopulated -= nr_pages; >>>> >>>> >>>> At least this way, the pages allocated (and thus eventually mapped to >>>> user space) would not be marked, but the other ones would remain marked >>>> and could be excluded by makedumptool. >>>> >>> >>> I think this patch should do the trick. Julien, could you give it a >>> try? On x86 I can't reproduce your problem easily as dom0 is PV with >>> plenty of unpopulated pages for grant memory not suffering from >>> missing "offline" bit. >> >> Sure. I managed to get the console working with the patch suggested by >> David. Feel free to add my tested-by if when you resend it as is. > > David, could you please send a proper patch with your Sob? > Yes, on it :) Cheers! > > Juergen > -- Thanks, David / dhildenb _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Xen-devel] xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-14 14:15 ` Juergen Gross 2019-03-14 14:16 ` David Hildenbrand @ 2019-03-14 14:16 ` David Hildenbrand 1 sibling, 0 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-14 14:16 UTC (permalink / raw) To: Juergen Gross, Julien Grall, Boris Ostrovsky, Andrew Cooper, Matthew Wilcox Cc: k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 14.03.19 15:15, Juergen Gross wrote: > On 14/03/2019 15:12, Julien Grall wrote: >> Hi, >> >> On 3/14/19 8:37 AM, Juergen Gross wrote: >>> On 12/03/2019 20:46, David Hildenbrand wrote: >>>> On 12.03.19 19:23, David Hildenbrand wrote: >>>> >>>> I guess something like this could do the trick if I understood it >>>> correctly: >>>> >>>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c >>>> index 39b229f9e256..d37dd5bb7a8f 100644 >>>> --- a/drivers/xen/balloon.c >>>> +++ b/drivers/xen/balloon.c >>>> @@ -604,6 +604,7 @@ int alloc_xenballooned_pages(int nr_pages, struct >>>> page **pages) >>>> while (pgno < nr_pages) { >>>> page = balloon_retrieve(true); >>>> if (page) { >>>> + __ClearPageOffline(page); >>>> pages[pgno++] = page; >>>> #ifdef CONFIG_XEN_HAVE_PVMMU >>>> /* >>>> @@ -645,8 +646,10 @@ void free_xenballooned_pages(int nr_pages, struct >>>> page **pages) >>>> mutex_lock(&balloon_mutex); >>>> >>>> for (i = 0; i < nr_pages; i++) { >>>> - if (pages[i]) >>>> + if (pages[i]) { >>>> + __SetPageOffline(pages[i]); >>>> balloon_append(pages[i]); >>>> + } >>>> } >>>> >>>> balloon_stats.target_unpopulated -= nr_pages; >>>> >>>> >>>> At least this way, the pages allocated (and thus eventually mapped to >>>> user space) would not be marked, but the other ones would remain marked >>>> and could be excluded by makedumptool. >>>> >>> >>> I think this patch should do the trick. Julien, could you give it a >>> try? On x86 I can't reproduce your problem easily as dom0 is PV with >>> plenty of unpopulated pages for grant memory not suffering from >>> missing "offline" bit. >> >> Sure. I managed to get the console working with the patch suggested by >> David. Feel free to add my tested-by if when you resend it as is. > > David, could you please send a proper patch with your Sob? > Yes, on it :) Cheers! > > Juergen > -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-14 14:12 ` [Xen-devel] " Julien Grall ` (2 preceding siblings ...) 2019-03-14 14:15 ` Juergen Gross @ 2019-03-14 14:15 ` Juergen Gross 3 siblings, 0 replies; 38+ messages in thread From: Juergen Gross @ 2019-03-14 14:15 UTC (permalink / raw) To: Julien Grall, David Hildenbrand, Boris Ostrovsky, Andrew Cooper, Matthew Wilcox Cc: k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 14/03/2019 15:12, Julien Grall wrote: > Hi, > > On 3/14/19 8:37 AM, Juergen Gross wrote: >> On 12/03/2019 20:46, David Hildenbrand wrote: >>> On 12.03.19 19:23, David Hildenbrand wrote: >>> >>> I guess something like this could do the trick if I understood it >>> correctly: >>> >>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c >>> index 39b229f9e256..d37dd5bb7a8f 100644 >>> --- a/drivers/xen/balloon.c >>> +++ b/drivers/xen/balloon.c >>> @@ -604,6 +604,7 @@ int alloc_xenballooned_pages(int nr_pages, struct >>> page **pages) >>> while (pgno < nr_pages) { >>> page = balloon_retrieve(true); >>> if (page) { >>> + __ClearPageOffline(page); >>> pages[pgno++] = page; >>> #ifdef CONFIG_XEN_HAVE_PVMMU >>> /* >>> @@ -645,8 +646,10 @@ void free_xenballooned_pages(int nr_pages, struct >>> page **pages) >>> mutex_lock(&balloon_mutex); >>> >>> for (i = 0; i < nr_pages; i++) { >>> - if (pages[i]) >>> + if (pages[i]) { >>> + __SetPageOffline(pages[i]); >>> balloon_append(pages[i]); >>> + } >>> } >>> >>> balloon_stats.target_unpopulated -= nr_pages; >>> >>> >>> At least this way, the pages allocated (and thus eventually mapped to >>> user space) would not be marked, but the other ones would remain marked >>> and could be excluded by makedumptool. >>> >> >> I think this patch should do the trick. Julien, could you give it a >> try? On x86 I can't reproduce your problem easily as dom0 is PV with >> plenty of unpopulated pages for grant memory not suffering from >> missing "offline" bit. > > Sure. I managed to get the console working with the patch suggested by > David. Feel free to add my tested-by if when you resend it as is. David, could you please send a proper patch with your Sob? Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 19:46 ` David Hildenbrand 2019-03-14 8:37 ` Juergen Gross @ 2019-03-14 8:37 ` Juergen Gross 1 sibling, 0 replies; 38+ messages in thread From: Juergen Gross @ 2019-03-14 8:37 UTC (permalink / raw) To: David Hildenbrand, Boris Ostrovsky, Andrew Cooper, Matthew Wilcox, Julien Grall Cc: k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 12/03/2019 20:46, David Hildenbrand wrote: > On 12.03.19 19:23, David Hildenbrand wrote: >> On 12.03.19 19:02, Boris Ostrovsky wrote: >>> On 3/12/19 1:24 PM, Andrew Cooper wrote: >>>> On 12/03/2019 17:18, David Hildenbrand wrote: >>>>> On 12.03.19 18:14, Matthew Wilcox wrote: >>>>>> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>>>>>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>>>>>> It looks like all the arm test for linus [1] and next [2] tree >>>>>>>> are now failing. x86 seems to be mostly ok. >>>>>>>> >>>>>>>> The bisector fingered the following commit: >>>>>>>> >>>>>>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>>>>>> Author: Matthew Wilcox <willy@infradead.org> >>>>>>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>>>>>> >>>>>>>> mm/memory.c: prevent mapping typed pages to userspace >>>>>>>> Pages which use page_type must never be mapped to userspace as it would >>>>>>>> destroy their page type. Add an explicit check for this instead of >>>>>>>> assuming that kernel drivers always get this right. >>>>>> Oh good, it found a real problem. >>>>>> >>>>>>> It turns out the problem is because the balloon driver will call >>>>>>> __SetPageOffline() on allocated page. Therefore the page has a type and >>>>>>> vm_insert_pages will deny the insertion. >>>>>>> >>>>>>> My knowledge is quite limited in this area. So I am not sure how we can >>>>>>> solve the problem. >>>>>>> >>>>>>> I would appreciate if someone could provide input of to fix the mapping. >>>>>> I don't know the balloon driver, so I don't know why it was doing this, >>>>>> but what it was doing was Wrong and has been since 2014 with: >>>>>> >>>>>> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >>>>>> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >>>>>> Date: Thu Oct 9 15:29:27 2014 -0700 >>>>>> >>>>>> mm/balloon_compaction: redesign ballooned pages management >>>>>> >>>>>> If ballooned pages are supposed to be mapped into userspace, you can't mark >>>>>> them as ballooned pages using the mapcount field. >>>>>> >>>>> Asking myself why anybody would want to map balloon inflated pages into >>>>> user space (this just sounds plain wrong but my understanding to what >>>>> XEN balloon driver does might be limited), but I assume the easy fix >>>>> would be to revert >>>> I suspect the bug here is that the balloon driver is (ab)used for a >>>> second purpose >>> >>> Yes. And its name is alloc_xenballooned_pages(). >>> >> >> Haven't had a look at the code yet, but would another temporary fix be >> to clear/set PG_offline when allocating/freeing a ballooned page? >> (assuming here that only such pages will be mapped to user space) >> > > I guess something like this could do the trick if I understood it correctly: > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 39b229f9e256..d37dd5bb7a8f 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -604,6 +604,7 @@ int alloc_xenballooned_pages(int nr_pages, struct > page **pages) > while (pgno < nr_pages) { > page = balloon_retrieve(true); > if (page) { > + __ClearPageOffline(page); > pages[pgno++] = page; > #ifdef CONFIG_XEN_HAVE_PVMMU > /* > @@ -645,8 +646,10 @@ void free_xenballooned_pages(int nr_pages, struct > page **pages) > mutex_lock(&balloon_mutex); > > for (i = 0; i < nr_pages; i++) { > - if (pages[i]) > + if (pages[i]) { > + __SetPageOffline(pages[i]); > balloon_append(pages[i]); > + } > } > > balloon_stats.target_unpopulated -= nr_pages; > > > At least this way, the pages allocated (and thus eventually mapped to > user space) would not be marked, but the other ones would remain marked > and could be excluded by makedumptool. > I think this patch should do the trick. Julien, could you give it a try? On x86 I can't reproduce your problem easily as dom0 is PV with plenty of unpopulated pages for grant memory not suffering from missing "offline" bit. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 18:23 ` [Xen-devel] " David Hildenbrand 2019-03-12 19:46 ` David Hildenbrand @ 2019-03-12 19:46 ` David Hildenbrand 1 sibling, 0 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-12 19:46 UTC (permalink / raw) To: Boris Ostrovsky, Andrew Cooper, Matthew Wilcox, Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel On 12.03.19 19:23, David Hildenbrand wrote: > On 12.03.19 19:02, Boris Ostrovsky wrote: >> On 3/12/19 1:24 PM, Andrew Cooper wrote: >>> On 12/03/2019 17:18, David Hildenbrand wrote: >>>> On 12.03.19 18:14, Matthew Wilcox wrote: >>>>> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>>>>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>>>>> It looks like all the arm test for linus [1] and next [2] tree >>>>>>> are now failing. x86 seems to be mostly ok. >>>>>>> >>>>>>> The bisector fingered the following commit: >>>>>>> >>>>>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>>>>> Author: Matthew Wilcox <willy@infradead.org> >>>>>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>>>>> >>>>>>> mm/memory.c: prevent mapping typed pages to userspace >>>>>>> Pages which use page_type must never be mapped to userspace as it would >>>>>>> destroy their page type. Add an explicit check for this instead of >>>>>>> assuming that kernel drivers always get this right. >>>>> Oh good, it found a real problem. >>>>> >>>>>> It turns out the problem is because the balloon driver will call >>>>>> __SetPageOffline() on allocated page. Therefore the page has a type and >>>>>> vm_insert_pages will deny the insertion. >>>>>> >>>>>> My knowledge is quite limited in this area. So I am not sure how we can >>>>>> solve the problem. >>>>>> >>>>>> I would appreciate if someone could provide input of to fix the mapping. >>>>> I don't know the balloon driver, so I don't know why it was doing this, >>>>> but what it was doing was Wrong and has been since 2014 with: >>>>> >>>>> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >>>>> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >>>>> Date: Thu Oct 9 15:29:27 2014 -0700 >>>>> >>>>> mm/balloon_compaction: redesign ballooned pages management >>>>> >>>>> If ballooned pages are supposed to be mapped into userspace, you can't mark >>>>> them as ballooned pages using the mapcount field. >>>>> >>>> Asking myself why anybody would want to map balloon inflated pages into >>>> user space (this just sounds plain wrong but my understanding to what >>>> XEN balloon driver does might be limited), but I assume the easy fix >>>> would be to revert >>> I suspect the bug here is that the balloon driver is (ab)used for a >>> second purpose >> >> Yes. And its name is alloc_xenballooned_pages(). >> > > Haven't had a look at the code yet, but would another temporary fix be > to clear/set PG_offline when allocating/freeing a ballooned page? > (assuming here that only such pages will be mapped to user space) > I guess something like this could do the trick if I understood it correctly: diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 39b229f9e256..d37dd5bb7a8f 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -604,6 +604,7 @@ int alloc_xenballooned_pages(int nr_pages, struct page **pages) while (pgno < nr_pages) { page = balloon_retrieve(true); if (page) { + __ClearPageOffline(page); pages[pgno++] = page; #ifdef CONFIG_XEN_HAVE_PVMMU /* @@ -645,8 +646,10 @@ void free_xenballooned_pages(int nr_pages, struct page **pages) mutex_lock(&balloon_mutex); for (i = 0; i < nr_pages; i++) { - if (pages[i]) + if (pages[i]) { + __SetPageOffline(pages[i]); balloon_append(pages[i]); + } } balloon_stats.target_unpopulated -= nr_pages; At least this way, the pages allocated (and thus eventually mapped to user space) would not be marked, but the other ones would remain marked and could be excluded by makedumptool. -- Thanks, David / dhildenb _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:18 ` xen: Can't insert balloon page into VM userspace (WAS " David Hildenbrand ` (2 preceding siblings ...) (?) @ 2019-03-12 17:39 ` Julien Grall -1 siblings, 0 replies; 38+ messages in thread From: Julien Grall @ 2019-03-12 17:39 UTC (permalink / raw) To: David Hildenbrand, Matthew Wilcox Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel, Boris Ostrovsky Hi David, On 3/12/19 5:18 PM, David Hildenbrand wrote: > On 12.03.19 18:14, Matthew Wilcox wrote: >> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>> It looks like all the arm test for linus [1] and next [2] tree >>>> are now failing. x86 seems to be mostly ok. >>>> >>>> The bisector fingered the following commit: >>>> >>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>> Author: Matthew Wilcox <willy@infradead.org> >>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>> >>>> mm/memory.c: prevent mapping typed pages to userspace >>>> Pages which use page_type must never be mapped to userspace as it would >>>> destroy their page type. Add an explicit check for this instead of >>>> assuming that kernel drivers always get this right. >> >> Oh good, it found a real problem. >> >>> It turns out the problem is because the balloon driver will call >>> __SetPageOffline() on allocated page. Therefore the page has a type and >>> vm_insert_pages will deny the insertion. >>> >>> My knowledge is quite limited in this area. So I am not sure how we can >>> solve the problem. >>> >>> I would appreciate if someone could provide input of to fix the mapping. >> >> I don't know the balloon driver, so I don't know why it was doing this, >> but what it was doing was Wrong and has been since 2014 with: >> >> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >> Date: Thu Oct 9 15:29:27 2014 -0700 >> >> mm/balloon_compaction: redesign ballooned pages management >> >> If ballooned pages are supposed to be mapped into userspace, you can't mark >> them as ballooned pages using the mapcount field. >> > > Asking myself why anybody would want to map balloon inflated pages into > user space (this just sounds plain wrong but my understanding to what > XEN balloon driver does might be limited), but I assume the easy fix > would be to revert Balloon pages are used to map foreign guest pages. As backend PV drivers may live in userspace (e.g QEMU, Xenconsoled...) we need to be able to to insert balloon pages in the VM. > > > commit 2f085ff37d08ecbc7849d5abb9424bd7927dda1d I guess you meant 77c4adf6a6df6f8f39807eaed48eb73d0eb4261e? I have reverted the patch and can now access the guest console. Is there a way to keep this patch and at the same time mapping the page in the userspace? > Author: David Hildenbrand <david@redhat.com> > Date: Wed Mar 6 11:42:24 2019 +1100 > > xen/balloon: mark inflated pages PG_offline > > Mark inflated and never onlined pages PG_offline, to tell the world that > the content is stale and should not be dumped. > > Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:18 ` xen: Can't insert balloon page into VM userspace (WAS " David Hildenbrand ` (3 preceding siblings ...) (?) @ 2019-03-12 17:39 ` Julien Grall 2019-03-12 17:49 ` xen: Can't insert balloon page into VM userspace (WAS " David Hildenbrand 2019-03-12 17:49 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " David Hildenbrand -1 siblings, 2 replies; 38+ messages in thread From: Julien Grall @ 2019-03-12 17:39 UTC (permalink / raw) To: David Hildenbrand, Matthew Wilcox Cc: osstest service owner, xen-devel, Juergen Gross, Konrad Rzeszutek Wilk, Boris Ostrovsky, Stefano Stabellini, linux-kernel, Kees Cook, k.khlebnikov, Julien Freche, Nadav Amit, VMware, Inc., linux-mm Hi David, On 3/12/19 5:18 PM, David Hildenbrand wrote: > On 12.03.19 18:14, Matthew Wilcox wrote: >> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>> It looks like all the arm test for linus [1] and next [2] tree >>>> are now failing. x86 seems to be mostly ok. >>>> >>>> The bisector fingered the following commit: >>>> >>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>> Author: Matthew Wilcox <willy@infradead.org> >>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>> >>>> mm/memory.c: prevent mapping typed pages to userspace >>>> Pages which use page_type must never be mapped to userspace as it would >>>> destroy their page type. Add an explicit check for this instead of >>>> assuming that kernel drivers always get this right. >> >> Oh good, it found a real problem. >> >>> It turns out the problem is because the balloon driver will call >>> __SetPageOffline() on allocated page. Therefore the page has a type and >>> vm_insert_pages will deny the insertion. >>> >>> My knowledge is quite limited in this area. So I am not sure how we can >>> solve the problem. >>> >>> I would appreciate if someone could provide input of to fix the mapping. >> >> I don't know the balloon driver, so I don't know why it was doing this, >> but what it was doing was Wrong and has been since 2014 with: >> >> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >> Date: Thu Oct 9 15:29:27 2014 -0700 >> >> mm/balloon_compaction: redesign ballooned pages management >> >> If ballooned pages are supposed to be mapped into userspace, you can't mark >> them as ballooned pages using the mapcount field. >> > > Asking myself why anybody would want to map balloon inflated pages into > user space (this just sounds plain wrong but my understanding to what > XEN balloon driver does might be limited), but I assume the easy fix > would be to revert Balloon pages are used to map foreign guest pages. As backend PV drivers may live in userspace (e.g QEMU, Xenconsoled...) we need to be able to to insert balloon pages in the VM. > > > commit 2f085ff37d08ecbc7849d5abb9424bd7927dda1d I guess you meant 77c4adf6a6df6f8f39807eaed48eb73d0eb4261e? I have reverted the patch and can now access the guest console. Is there a way to keep this patch and at the same time mapping the page in the userspace? > Author: David Hildenbrand <david@redhat.com> > Date: Wed Mar 6 11:42:24 2019 +1100 > > xen/balloon: mark inflated pages PG_offline > > Mark inflated and never onlined pages PG_offline, to tell the world that > the content is stale and should not be dumped. > > Cheers, -- Julien Grall ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:39 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " Julien Grall @ 2019-03-12 17:49 ` David Hildenbrand 2019-03-12 17:49 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " David Hildenbrand 1 sibling, 0 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-12 17:49 UTC (permalink / raw) To: Julien Grall, Matthew Wilcox Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel, Boris Ostrovsky On 12.03.19 18:39, Julien Grall wrote: > Hi David, > > On 3/12/19 5:18 PM, David Hildenbrand wrote: >> On 12.03.19 18:14, Matthew Wilcox wrote: >>> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>>> It looks like all the arm test for linus [1] and next [2] tree >>>>> are now failing. x86 seems to be mostly ok. >>>>> >>>>> The bisector fingered the following commit: >>>>> >>>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>>> Author: Matthew Wilcox <willy@infradead.org> >>>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>>> >>>>> mm/memory.c: prevent mapping typed pages to userspace >>>>> Pages which use page_type must never be mapped to userspace as it would >>>>> destroy their page type. Add an explicit check for this instead of >>>>> assuming that kernel drivers always get this right. >>> >>> Oh good, it found a real problem. >>> >>>> It turns out the problem is because the balloon driver will call >>>> __SetPageOffline() on allocated page. Therefore the page has a type and >>>> vm_insert_pages will deny the insertion. >>>> >>>> My knowledge is quite limited in this area. So I am not sure how we can >>>> solve the problem. >>>> >>>> I would appreciate if someone could provide input of to fix the mapping. >>> >>> I don't know the balloon driver, so I don't know why it was doing this, >>> but what it was doing was Wrong and has been since 2014 with: >>> >>> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >>> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >>> Date: Thu Oct 9 15:29:27 2014 -0700 >>> >>> mm/balloon_compaction: redesign ballooned pages management >>> >>> If ballooned pages are supposed to be mapped into userspace, you can't mark >>> them as ballooned pages using the mapcount field. >>> >> >> Asking myself why anybody would want to map balloon inflated pages into >> user space (this just sounds plain wrong but my understanding to what >> XEN balloon driver does might be limited), but I assume the easy fix >> would be to revert > > Balloon pages are used to map foreign guest pages. As backend PV drivers > may live in userspace (e.g QEMU, Xenconsoled...) we need to be able to > to insert balloon pages in the VM. Okay, so this is really XEN specific (especially looking at Andrew's reply). All other balloon drivers told the hypervisor that the inflated page is dead and it is not going to be use before telling the hypervisor otherwise. Mapping to user space would violate that contract (and even be considered harmful in some hypervisor implementations). > >> >> >> commit 2f085ff37d08ecbc7849d5abb9424bd7927dda1d > > I guess you meant 77c4adf6a6df6f8f39807eaed48eb73d0eb4261e? Yes indeed, no idea where that commit id came from :) > > I have reverted the patch and can now access the guest console. Is there > a way to keep this patch and at the same time mapping the page in the > userspace? Not without another page flag. And we all know that is unlikely to happen :) Thanks! > > >> Author: David Hildenbrand <david@redhat.com> >> Date: Wed Mar 6 11:42:24 2019 +1100 >> >> xen/balloon: mark inflated pages PG_offline >> >> Mark inflated and never onlined pages PG_offline, to tell the world that >> the content is stale and should not be dumped. >> >> > > Cheers, > -- Thanks, David / dhildenb _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:39 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " Julien Grall 2019-03-12 17:49 ` xen: Can't insert balloon page into VM userspace (WAS " David Hildenbrand @ 2019-03-12 17:49 ` David Hildenbrand 1 sibling, 0 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-12 17:49 UTC (permalink / raw) To: Julien Grall, Matthew Wilcox Cc: osstest service owner, xen-devel, Juergen Gross, Konrad Rzeszutek Wilk, Boris Ostrovsky, Stefano Stabellini, linux-kernel, Kees Cook, k.khlebnikov, Julien Freche, Nadav Amit, VMware, Inc., linux-mm On 12.03.19 18:39, Julien Grall wrote: > Hi David, > > On 3/12/19 5:18 PM, David Hildenbrand wrote: >> On 12.03.19 18:14, Matthew Wilcox wrote: >>> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>>> It looks like all the arm test for linus [1] and next [2] tree >>>>> are now failing. x86 seems to be mostly ok. >>>>> >>>>> The bisector fingered the following commit: >>>>> >>>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>>> Author: Matthew Wilcox <willy@infradead.org> >>>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>>> >>>>> mm/memory.c: prevent mapping typed pages to userspace >>>>> Pages which use page_type must never be mapped to userspace as it would >>>>> destroy their page type. Add an explicit check for this instead of >>>>> assuming that kernel drivers always get this right. >>> >>> Oh good, it found a real problem. >>> >>>> It turns out the problem is because the balloon driver will call >>>> __SetPageOffline() on allocated page. Therefore the page has a type and >>>> vm_insert_pages will deny the insertion. >>>> >>>> My knowledge is quite limited in this area. So I am not sure how we can >>>> solve the problem. >>>> >>>> I would appreciate if someone could provide input of to fix the mapping. >>> >>> I don't know the balloon driver, so I don't know why it was doing this, >>> but what it was doing was Wrong and has been since 2014 with: >>> >>> commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 >>> Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> >>> Date: Thu Oct 9 15:29:27 2014 -0700 >>> >>> mm/balloon_compaction: redesign ballooned pages management >>> >>> If ballooned pages are supposed to be mapped into userspace, you can't mark >>> them as ballooned pages using the mapcount field. >>> >> >> Asking myself why anybody would want to map balloon inflated pages into >> user space (this just sounds plain wrong but my understanding to what >> XEN balloon driver does might be limited), but I assume the easy fix >> would be to revert > > Balloon pages are used to map foreign guest pages. As backend PV drivers > may live in userspace (e.g QEMU, Xenconsoled...) we need to be able to > to insert balloon pages in the VM. Okay, so this is really XEN specific (especially looking at Andrew's reply). All other balloon drivers told the hypervisor that the inflated page is dead and it is not going to be use before telling the hypervisor otherwise. Mapping to user space would violate that contract (and even be considered harmful in some hypervisor implementations). > >> >> >> commit 2f085ff37d08ecbc7849d5abb9424bd7927dda1d > > I guess you meant 77c4adf6a6df6f8f39807eaed48eb73d0eb4261e? Yes indeed, no idea where that commit id came from :) > > I have reverted the patch and can now access the guest console. Is there > a way to keep this patch and at the same time mapping the page in the > userspace? Not without another page flag. And we all know that is unlikely to happen :) Thanks! > > >> Author: David Hildenbrand <david@redhat.com> >> Date: Wed Mar 6 11:42:24 2019 +1100 >> >> xen/balloon: mark inflated pages PG_offline >> >> Mark inflated and never onlined pages PG_offline, to tell the world that >> the content is stale and should not be dumped. >> >> > > Cheers, > -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:14 ` xen: Can't insert balloon page into VM userspace (WAS " Matthew Wilcox (?) (?) @ 2019-03-12 17:23 ` David Hildenbrand -1 siblings, 0 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-12 17:23 UTC (permalink / raw) To: Matthew Wilcox, Julien Grall Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, VMware, Inc., osstest service owner, linux-kernel, linux-mm, Julien Freche, Nadav Amit, xen-devel, Boris Ostrovsky On 12.03.19 18:14, Matthew Wilcox wrote: > On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >> On 3/12/19 3:59 PM, Julien Grall wrote: >>> It looks like all the arm test for linus [1] and next [2] tree >>> are now failing. x86 seems to be mostly ok. >>> >>> The bisector fingered the following commit: >>> >>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>> Author: Matthew Wilcox <willy@infradead.org> >>> Date: Tue Mar 5 15:46:06 2019 -0800 >>> >>> mm/memory.c: prevent mapping typed pages to userspace >>> Pages which use page_type must never be mapped to userspace as it would >>> destroy their page type. Add an explicit check for this instead of >>> assuming that kernel drivers always get this right. > > Oh good, it found a real problem. > >> It turns out the problem is because the balloon driver will call >> __SetPageOffline() on allocated page. Therefore the page has a type and >> vm_insert_pages will deny the insertion. >> >> My knowledge is quite limited in this area. So I am not sure how we can >> solve the problem. >> >> I would appreciate if someone could provide input of to fix the mapping. > > I don't know the balloon driver, so I don't know why it was doing this, > but what it was doing was Wrong and has been since 2014 with: Just to clarify on that point, XEN balloon does not use balloon compaction as far as I know (only virtio-balloon and as far as I know now also vmware balloon). Both of them don't map any such pages to user space, so it never was and isn't a problem. > > commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 > Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> > Date: Thu Oct 9 15:29:27 2014 -0700 > > mm/balloon_compaction: redesign ballooned pages management > > If ballooned pages are supposed to be mapped into userspace, you can't mark > them as ballooned pages using the mapcount field. > -- Thanks, David / dhildenb _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:14 ` xen: Can't insert balloon page into VM userspace (WAS " Matthew Wilcox ` (2 preceding siblings ...) (?) @ 2019-03-12 17:23 ` David Hildenbrand 2019-03-12 17:25 ` xen: Can't insert balloon page into VM userspace (WAS " Nadav Amit 2019-03-12 17:25 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " Nadav Amit -1 siblings, 2 replies; 38+ messages in thread From: David Hildenbrand @ 2019-03-12 17:23 UTC (permalink / raw) To: Matthew Wilcox, Julien Grall Cc: osstest service owner, xen-devel, Juergen Gross, Konrad Rzeszutek Wilk, Boris Ostrovsky, Stefano Stabellini, linux-kernel, Kees Cook, k.khlebnikov, Julien Freche, Nadav Amit, VMware, Inc., linux-mm On 12.03.19 18:14, Matthew Wilcox wrote: > On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >> On 3/12/19 3:59 PM, Julien Grall wrote: >>> It looks like all the arm test for linus [1] and next [2] tree >>> are now failing. x86 seems to be mostly ok. >>> >>> The bisector fingered the following commit: >>> >>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>> Author: Matthew Wilcox <willy@infradead.org> >>> Date: Tue Mar 5 15:46:06 2019 -0800 >>> >>> mm/memory.c: prevent mapping typed pages to userspace >>> Pages which use page_type must never be mapped to userspace as it would >>> destroy their page type. Add an explicit check for this instead of >>> assuming that kernel drivers always get this right. > > Oh good, it found a real problem. > >> It turns out the problem is because the balloon driver will call >> __SetPageOffline() on allocated page. Therefore the page has a type and >> vm_insert_pages will deny the insertion. >> >> My knowledge is quite limited in this area. So I am not sure how we can >> solve the problem. >> >> I would appreciate if someone could provide input of to fix the mapping. > > I don't know the balloon driver, so I don't know why it was doing this, > but what it was doing was Wrong and has been since 2014 with: Just to clarify on that point, XEN balloon does not use balloon compaction as far as I know (only virtio-balloon and as far as I know now also vmware balloon). Both of them don't map any such pages to user space, so it never was and isn't a problem. > > commit d6d86c0a7f8ddc5b38cf089222cb1d9540762dc2 > Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com> > Date: Thu Oct 9 15:29:27 2014 -0700 > > mm/balloon_compaction: redesign ballooned pages management > > If ballooned pages are supposed to be mapped into userspace, you can't mark > them as ballooned pages using the mapcount field. > -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:23 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " David Hildenbrand @ 2019-03-12 17:25 ` Nadav Amit 2019-03-12 17:25 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " Nadav Amit 1 sibling, 0 replies; 38+ messages in thread From: Nadav Amit @ 2019-03-12 17:25 UTC (permalink / raw) To: David Hildenbrand Cc: Juergen Gross, k.khlebnikov, Stefano Stabellini, Kees Cook, Konrad Rzeszutek Wilk, Julien Freche, osstest service owner, Matthew Wilcox, linux-kernel, linux-mm, Pv-drivers, Julien Grall, xen-devel, Boris Ostrovsky > On Mar 12, 2019, at 10:23 AM, David Hildenbrand <david@redhat.com> wrote: > > On 12.03.19 18:14, Matthew Wilcox wrote: >> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>> It looks like all the arm test for linus [1] and next [2] tree >>>> are now failing. x86 seems to be mostly ok. >>>> >>>> The bisector fingered the following commit: >>>> >>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>> Author: Matthew Wilcox <willy@infradead.org> >>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>> >>>> mm/memory.c: prevent mapping typed pages to userspace >>>> Pages which use page_type must never be mapped to userspace as it would >>>> destroy their page type. Add an explicit check for this instead of >>>> assuming that kernel drivers always get this right. >> >> Oh good, it found a real problem. >> >>> It turns out the problem is because the balloon driver will call >>> __SetPageOffline() on allocated page. Therefore the page has a type and >>> vm_insert_pages will deny the insertion. >>> >>> My knowledge is quite limited in this area. So I am not sure how we can >>> solve the problem. >>> >>> I would appreciate if someone could provide input of to fix the mapping. >> >> I don't know the balloon driver, so I don't know why it was doing this, >> but what it was doing was Wrong and has been since 2014 with: > > Just to clarify on that point, XEN balloon does not use balloon > compaction as far as I know (only virtio-balloon and as far as I know > now also vmware balloon). Both of them don't map any such pages to user > space, so it never was and isn't a problem. I still need to submit the next version of the patches, but yes, we are not about to map them to userspace (dah). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] [linux-linus bisection] complete test-arm64-arm64-xl-xsm) 2019-03-12 17:23 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " David Hildenbrand 2019-03-12 17:25 ` xen: Can't insert balloon page into VM userspace (WAS " Nadav Amit @ 2019-03-12 17:25 ` Nadav Amit 1 sibling, 0 replies; 38+ messages in thread From: Nadav Amit @ 2019-03-12 17:25 UTC (permalink / raw) To: David Hildenbrand Cc: Matthew Wilcox, Julien Grall, osstest service owner, xen-devel, Juergen Gross, Konrad Rzeszutek Wilk, Boris Ostrovsky, Stefano Stabellini, linux-kernel, Kees Cook, k.khlebnikov, Julien Freche, Pv-drivers, linux-mm > On Mar 12, 2019, at 10:23 AM, David Hildenbrand <david@redhat.com> wrote: > > On 12.03.19 18:14, Matthew Wilcox wrote: >> On Tue, Mar 12, 2019 at 05:05:39PM +0000, Julien Grall wrote: >>> On 3/12/19 3:59 PM, Julien Grall wrote: >>>> It looks like all the arm test for linus [1] and next [2] tree >>>> are now failing. x86 seems to be mostly ok. >>>> >>>> The bisector fingered the following commit: >>>> >>>> commit 0ee930e6cafa048c1925893d0ca89918b2814f2c >>>> Author: Matthew Wilcox <willy@infradead.org> >>>> Date: Tue Mar 5 15:46:06 2019 -0800 >>>> >>>> mm/memory.c: prevent mapping typed pages to userspace >>>> Pages which use page_type must never be mapped to userspace as it would >>>> destroy their page type. Add an explicit check for this instead of >>>> assuming that kernel drivers always get this right. >> >> Oh good, it found a real problem. >> >>> It turns out the problem is because the balloon driver will call >>> __SetPageOffline() on allocated page. Therefore the page has a type and >>> vm_insert_pages will deny the insertion. >>> >>> My knowledge is quite limited in this area. So I am not sure how we can >>> solve the problem. >>> >>> I would appreciate if someone could provide input of to fix the mapping. >> >> I don't know the balloon driver, so I don't know why it was doing this, >> but what it was doing was Wrong and has been since 2014 with: > > Just to clarify on that point, XEN balloon does not use balloon > compaction as far as I know (only virtio-balloon and as far as I know > now also vmware balloon). Both of them don't map any such pages to user > space, so it never was and isn't a problem. I still need to submit the next version of the patches, but yes, we are not about to map them to userspace (dah). ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm 2019-03-12 15:59 ` Julien Grall 2019-03-12 17:05 ` xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) Julien Grall 2019-03-12 17:05 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " Julien Grall @ 2019-03-12 17:27 ` Roger Pau Monné 2019-03-12 18:00 ` Wei Liu 2 siblings, 1 reply; 38+ messages in thread From: Roger Pau Monné @ 2019-03-12 17:27 UTC (permalink / raw) To: Julien Grall Cc: Juergen Gross, Stefano Stabellini, Konrad Rzeszutek Wilk, osstest service owner, xen-devel, Boris Ostrovsky On Tue, Mar 12, 2019 at 03:59:04PM +0000, Julien Grall wrote: > Hi all, > > It looks like all the arm test for linus [1] and next [2] tree > are now failing. x86 seems to be mostly ok. I'm quite sure x86 PVH dom0 is also broken after this change. > The bisector fingered the following commit: > > commit 0ee930e6cafa048c1925893d0ca89918b2814f2c > Author: Matthew Wilcox <willy@infradead.org> > Date: Tue Mar 5 15:46:06 2019 -0800 > > mm/memory.c: prevent mapping typed pages to userspace > > Pages which use page_type must never be mapped to userspace as it would > destroy their page type. Add an explicit check for this instead of > assuming that kernel drivers always get this right. > > Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org > Signed-off-by: Matthew Wilcox <willy@infradead.org> > Reviewed-by: Kees Cook <keescook@chromium.org> > Reviewed-by: David Hildenbrand <david@redhat.com> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: Will Deacon <will.deacon@arm.com> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> > > I have tried the latest linus mater as Dom0 and see some issue to get the > console guest: > > 42sh> sudo xl create -c ~/works/guest/guest.cfg > Parsing config from /home/julien/works/guest/guest.cfg > xenconsole: Could not read tty from store: Success > > I have added a print in the error path added by the commit above to see > what and where it happens: > > [ 182.366372] PageAnon 0 PageSlab 0 page_has_type 1 > [ 182.371076] WARNING: CPU: 2 PID: 2210 at mm/memory.c:1459 vm_insert_page+0x3e > 0/0x430 > [ 182.378837] Modules linked in: > [ 182.381974] CPU: 2 PID: 2210 Comm: xenstored Not tainted 5.0.0-10742-gea29548 > 1b6e3-dirty #1310 > [ 182.390672] Hardware name: ARM Juno development board (r2) (DT) > [ 182.396678] pstate: 40000005 (nZcv daif -PAN -UAO) > [ 182.401553] pc : vm_insert_page+0x3e0/0x430 > [ 182.405816] lr : vm_insert_page+0x3e0/0x430 > [ 182.410077] sp : ffff000012773bc0 > [ 182.413471] x29: ffff000012773bc0 x28: 0000ffff8d3fa000 > [ 182.418866] x27: 0000000000000008 x26: 0000000000000001 > [ 182.424261] x25: 0000000000000008 x24: 0000ffff8d3fa000 > [ 182.429656] x23: 0068000000000f53 x22: ffff8008ab520a00 > [ 182.435052] x21: ffff000011644a88 x20: 0000000000000000 > [ 182.440454] x19: ffff7e00229b0e80 x18: 0000000000000000 > [ 182.445841] x17: 0000000000000000 x16: 0000000000000000 > [ 182.451245] x15: 00000000fffffff0 x14: 0000000000000000 > [ 182.456631] x13: ffff000012339ff0 x12: 0000000000000006 > [ 182.462027] x11: ffff000010ec4980 x10: ffff0000107d01f8 > [ 182.467422] x9 : 00000000fffb9fff x8 : ffff8008ab55a0a0 > [ 182.472817] x7 : 0000000000000001 x6 : ffff8008bb02a220 > [ 182.478212] x5 : ffff8008bb02a220 x4 : 0000000000000000 > [ 182.483607] x3 : ffff8008bb032708 x2 : b98ad6a7b7eb2900 > [ 182.489002] x1 : 0000000000000000 x0 : 0000000000000025 > [ 182.494397] Call trace: > [ 182.496924] vm_insert_page+0x3e0/0x430 > [ 182.500853] gntdev_mmap+0x188/0x288 > [ 182.504495] mmap_region+0x3dc/0x578 > [ 182.508149] do_mmap+0x2d4/0x478 > [ 182.511457] vm_mmap_pgoff+0xe0/0x108 > [ 182.515198] ksys_mmap_pgoff+0xac/0x308 > [ 182.519116] __arm64_sys_mmap+0x28/0x38 > [ 182.523029] el0_svc_handler+0x88/0x100 > [ 182.526943] el0_svc+0x8/0xc > [ 182.529901] ---[ end trace cf738ac71bfed946 ]--- > > Does it ring any bell? Ballooned pages are used by Linux in order to map foreign pages or grants, and it seems like this process doesn't mark the page as online when they are use to map foreign memory or grants. The easiest solution might be to mark pages as onlined in alloc_xenballooned_pages? Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm 2019-03-12 17:27 ` [linux-linus bisection] complete test-arm64-arm64-xl-xsm Roger Pau Monné @ 2019-03-12 18:00 ` Wei Liu 0 siblings, 0 replies; 38+ messages in thread From: Wei Liu @ 2019-03-12 18:00 UTC (permalink / raw) To: Roger Pau Monné Cc: Juergen Gross, Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk, osstest service owner, Julien Grall, xen-devel, Boris Ostrovsky On Tue, Mar 12, 2019 at 06:27:03PM +0100, Roger Pau Monné wrote: > On Tue, Mar 12, 2019 at 03:59:04PM +0000, Julien Grall wrote: > > Hi all, > > > > It looks like all the arm test for linus [1] and next [2] tree > > are now failing. x86 seems to be mostly ok. > > I'm quite sure x86 PVH dom0 is also broken after this change. > > > The bisector fingered the following commit: > > > > commit 0ee930e6cafa048c1925893d0ca89918b2814f2c > > Author: Matthew Wilcox <willy@infradead.org> > > Date: Tue Mar 5 15:46:06 2019 -0800 > > > > mm/memory.c: prevent mapping typed pages to userspace > > > > Pages which use page_type must never be mapped to userspace as it would > > destroy their page type. Add an explicit check for this instead of > > assuming that kernel drivers always get this right. > > > > Link: http://lkml.kernel.org/r/20190129053830.3749-1-willy@infradead.org > > Signed-off-by: Matthew Wilcox <willy@infradead.org> > > Reviewed-by: Kees Cook <keescook@chromium.org> > > Reviewed-by: David Hildenbrand <david@redhat.com> > > Cc: Michael Ellerman <mpe@ellerman.id.au> > > Cc: Will Deacon <will.deacon@arm.com> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> > > > > I have tried the latest linus mater as Dom0 and see some issue to get the > > console guest: > > > > 42sh> sudo xl create -c ~/works/guest/guest.cfg > > Parsing config from /home/julien/works/guest/guest.cfg > > xenconsole: Could not read tty from store: Success > > > > I have added a print in the error path added by the commit above to see > > what and where it happens: > > > > [ 182.366372] PageAnon 0 PageSlab 0 page_has_type 1 > > [ 182.371076] WARNING: CPU: 2 PID: 2210 at mm/memory.c:1459 vm_insert_page+0x3e > > 0/0x430 > > [ 182.378837] Modules linked in: > > [ 182.381974] CPU: 2 PID: 2210 Comm: xenstored Not tainted 5.0.0-10742-gea29548 > > 1b6e3-dirty #1310 > > [ 182.390672] Hardware name: ARM Juno development board (r2) (DT) > > [ 182.396678] pstate: 40000005 (nZcv daif -PAN -UAO) > > [ 182.401553] pc : vm_insert_page+0x3e0/0x430 > > [ 182.405816] lr : vm_insert_page+0x3e0/0x430 > > [ 182.410077] sp : ffff000012773bc0 > > [ 182.413471] x29: ffff000012773bc0 x28: 0000ffff8d3fa000 > > [ 182.418866] x27: 0000000000000008 x26: 0000000000000001 > > [ 182.424261] x25: 0000000000000008 x24: 0000ffff8d3fa000 > > [ 182.429656] x23: 0068000000000f53 x22: ffff8008ab520a00 > > [ 182.435052] x21: ffff000011644a88 x20: 0000000000000000 > > [ 182.440454] x19: ffff7e00229b0e80 x18: 0000000000000000 > > [ 182.445841] x17: 0000000000000000 x16: 0000000000000000 > > [ 182.451245] x15: 00000000fffffff0 x14: 0000000000000000 > > [ 182.456631] x13: ffff000012339ff0 x12: 0000000000000006 > > [ 182.462027] x11: ffff000010ec4980 x10: ffff0000107d01f8 > > [ 182.467422] x9 : 00000000fffb9fff x8 : ffff8008ab55a0a0 > > [ 182.472817] x7 : 0000000000000001 x6 : ffff8008bb02a220 > > [ 182.478212] x5 : ffff8008bb02a220 x4 : 0000000000000000 > > [ 182.483607] x3 : ffff8008bb032708 x2 : b98ad6a7b7eb2900 > > [ 182.489002] x1 : 0000000000000000 x0 : 0000000000000025 > > [ 182.494397] Call trace: > > [ 182.496924] vm_insert_page+0x3e0/0x430 > > [ 182.500853] gntdev_mmap+0x188/0x288 > > [ 182.504495] mmap_region+0x3dc/0x578 > > [ 182.508149] do_mmap+0x2d4/0x478 > > [ 182.511457] vm_mmap_pgoff+0xe0/0x108 > > [ 182.515198] ksys_mmap_pgoff+0xac/0x308 > > [ 182.519116] __arm64_sys_mmap+0x28/0x38 > > [ 182.523029] el0_svc_handler+0x88/0x100 > > [ 182.526943] el0_svc+0x8/0xc > > [ 182.529901] ---[ end trace cf738ac71bfed946 ]--- > > > > Does it ring any bell? > > Ballooned pages are used by Linux in order to map foreign pages or > grants, and it seems like this process doesn't mark the page as online > when they are use to map foreign memory or grants. > > The easiest solution might be to mark pages as onlined in > alloc_xenballooned_pages? But then that means those pages, which could contain sensitive guest data, could be potentially dumped? Wei. > > Roger. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2019-03-14 14:16 UTC | newest] Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-11 23:52 [linux-linus bisection] complete test-arm64-arm64-xl-xsm osstest service owner 2019-03-12 15:59 ` Julien Grall 2019-03-12 17:05 ` xen: Can't insert balloon page into VM userspace (WAS Re: [linux-linus bisection] complete test-arm64-arm64-xl-xsm) Julien Grall 2019-03-12 17:05 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " Julien Grall 2019-03-12 17:14 ` Matthew Wilcox 2019-03-12 17:14 ` xen: Can't insert balloon page into VM userspace (WAS " Matthew Wilcox 2019-03-12 17:18 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " David Hildenbrand 2019-03-12 17:18 ` xen: Can't insert balloon page into VM userspace (WAS " David Hildenbrand 2019-03-12 17:24 ` Andrew Cooper 2019-03-12 17:24 ` [Xen-devel] " Andrew Cooper 2019-03-12 18:02 ` Boris Ostrovsky 2019-03-12 18:02 ` [Xen-devel] " Boris Ostrovsky 2019-03-12 18:11 ` Andrew Cooper 2019-03-12 18:11 ` [Xen-devel] " Andrew Cooper 2019-03-12 18:23 ` David Hildenbrand 2019-03-12 18:23 ` [Xen-devel] " David Hildenbrand 2019-03-12 19:46 ` David Hildenbrand 2019-03-14 8:37 ` Juergen Gross 2019-03-14 14:12 ` Julien Grall 2019-03-14 14:12 ` [Xen-devel] " Julien Grall 2019-03-14 14:14 ` David Hildenbrand 2019-03-14 14:14 ` [Xen-devel] " David Hildenbrand 2019-03-14 14:15 ` Juergen Gross 2019-03-14 14:16 ` David Hildenbrand 2019-03-14 14:16 ` [Xen-devel] " David Hildenbrand 2019-03-14 14:15 ` Juergen Gross 2019-03-14 8:37 ` Juergen Gross 2019-03-12 19:46 ` David Hildenbrand 2019-03-12 17:39 ` Julien Grall 2019-03-12 17:39 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " Julien Grall 2019-03-12 17:49 ` xen: Can't insert balloon page into VM userspace (WAS " David Hildenbrand 2019-03-12 17:49 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " David Hildenbrand 2019-03-12 17:23 ` xen: Can't insert balloon page into VM userspace (WAS " David Hildenbrand 2019-03-12 17:23 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " David Hildenbrand 2019-03-12 17:25 ` xen: Can't insert balloon page into VM userspace (WAS " Nadav Amit 2019-03-12 17:25 ` xen: Can't insert balloon page into VM userspace (WAS Re: [Xen-devel] " Nadav Amit 2019-03-12 17:27 ` [linux-linus bisection] complete test-arm64-arm64-xl-xsm Roger Pau Monné 2019-03-12 18:00 ` Wei Liu
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.