All of lore.kernel.org
 help / color / mirror / Atom feed
* [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: [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

* 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

* 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: [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: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-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: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: 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: 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: [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: 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: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: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: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: [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

* 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 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 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
                               ` (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
                               ` (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: 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: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: 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-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-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-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  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 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: 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                     ` [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: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-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: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

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.