Xen 4.11.1 panic

Xen 4.11.1 panic

[Manuel Bouyer]

Hello,
I tried updating my NetBSD dom0 to 4.11.1 (from 4.11.0 with security patches),
and on a 32bits PV domU shutdown I get (100% reproductible):
(XEN) Assertion 'preemptible' failed at mm.c:2493                           
(XEN) ----[ Xen-4.11.1nb0  x86_64  debug=y   Tainted:  C   ]----            
(XEN) CPU:    1                                                             
(XEN) RIP:    e008:[<ffff82d08028b192>] free_page_type+0x232/0x790          
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor (d0v0)                 
(XEN) rax: 4000000000000000   rbx: 4400000000000001   rcx: 4000000000000000 
(XEN) rdx: ffff830000000000   rsi: 4400000000000001   rdi: ffff82e004215260 
(XEN) rbp: ffff82e004215260   rsp: ffff83023704fab8   r8:  0000000000000000 
(XEN) r9:  0000000000000000   r10: ffff82e000000000   r11: ffff82e004226000 
(XEN) r12: 0000000000000000   r13: ffff8302135d9000   r14: 10ffffffffffffff 
(XEN) r15: 1000000000000000   cr0: 000000008005003b   cr4: 0000000000002660 
(XEN) cr3: 000000022f0f6000   cr2: 00007f7ff60ce7a0
(XEN) fsb: 00007f7ff7ff36c0   gsb: ffffffff80ca42c0   gss: 0000000000000000
(XEN) ds: 003f   es: 003f   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen code around <ffff82d08028b192> (free_page_type+0x232/0x790):
(XEN)  05 00 00 45 85 e4 75 02 <0f> 0b 8b 45 18 85 c0 74 18 89 c0 48 c1 e0 0c 49
(XEN) Xen stack trace from rsp=ffff83023704fab8:
(XEN)    ffff83023704fe38 00000000000000ec 4400000000000001 ffff82e004215260
(XEN)    ffff82e004215240 00ffffffffffffff 10ffffffffffffff 1000000000000000
(XEN)    ffff82d08028b83d 00ff8300bedfc000 ffff83023704ffff ffff82d000000000
(XEN)    ffff82e004215260 ffff82e004215240 ffff8302135d9000 0000000000210a92
(XEN)    ffff820040019000 0200000000000000 ffff82d08028bedf 00000000000001ff
(XEN)    ffff82e004215240 ffff82d08028b25e ffff830200000000 ffff83023704ffff
(XEN)    4400000000000001 ffff82e004215240 ffff82e004206c60 00ffffffffffffff
(XEN)    10ffffffffffffff 1000000000000000 ffff82d08028b83d 0100000000000002
(XEN)    ffff83023704ffff ffff830200000001 ffff82e004215240 ffff82e004206c60
(XEN)    0000000000000000 ffff820040015010 0000000000000000 ffff820040015000
(XEN)    ffff82d08028af30 0000000000000002 ffff82e004206c60 0000000000000000
(XEN)    ffff820040015010 ffff82d08028b3d1 0000000000210363 ffff8302135d9000
(XEN)    6400000000000001 ffff82e004206c60 0000000000000000 00ffffffffffffff
(XEN)    10ffffffffffffff 1000000000000000 ffff82d08028b83d 01ff82d08022697f
(XEN)    ffff83023704ffff ffff830200000001 ffff82e004206c60 ffff83023704fd10
(XEN)    ffff8302135d9028 ffff8302135d9000 ffff8302135d9020 ffff82e004206c70
(XEN)    ffff82d08028bf1f ffff82d080274e6b ffff83023701ec00 e400000000000001
(XEN)    ffff83023704ffff 8000000000000000 ffff8302135d9000 0000000000000000
(XEN)    ffff8302135d9018 deadbeefdeadf00d 0000000000000001 00007f7ff7b32004
(XEN)    ffff82d080278f83 ffff8302135d9000 00007f7ff7b32004 ffff82d080208b2d
(XEN) Xen call trace:
(XEN)    [<ffff82d08028b192>] free_page_type+0x232/0x790
(XEN)    [<ffff82d08028b83d>] mm.c#_put_page_type+0x14d/0x380
(XEN)    [<ffff82d08028bedf>] mm.c#put_page_from_l2e+0xdf/0x110
(XEN)    [<ffff82d08028b25e>] free_page_type+0x2fe/0x790
(XEN)    [<ffff82d08028b83d>] mm.c#_put_page_type+0x14d/0x380
(XEN)    [<ffff82d08028af30>] mm.c#put_page_from_l3e+0x1a0/0x1d0
(XEN)    [<ffff82d08028b3d1>] free_page_type+0x471/0x790
(XEN)    [<ffff82d08028b83d>] mm.c#_put_page_type+0x14d/0x380
(XEN)    [<ffff82d08028bf1f>] put_page_type_preemptible+0xf/0x10
(XEN)    [<ffff82d080274e6b>] domain.c#relinquish_memory+0xab/0x460
(XEN)    [<ffff82d080278f83>] domain_relinquish_resources+0x203/0x290
(XEN)    [<ffff82d080208b2d>] domain_kill+0xbd/0x150
(XEN)    [<ffff82d080205c53>] do_domctl+0x7d3/0x1a90
(XEN)    [<ffff82d0802711e0>] do_physdev_op_compat+0/0x70
(XEN)    [<ffff82d080205480>] do_domctl+0/0x1a90
(XEN)    [<ffff82d08036b53b>] pv_hypercall+0x20b/0x440
(XEN)    [<ffff82d080372432>] lstar_enter+0xa2/0x120
(XEN)    [<ffff82d08037243e>] lstar_enter+0xae/0x120
(XEN)    [<ffff82d080372432>] lstar_enter+0xa2/0x120
(XEN)    [<ffff82d08037243e>] lstar_enter+0xae/0x120
(XEN)    [<ffff82d080372432>] lstar_enter+0xa2/0x120
(XEN)    [<ffff82d08037243e>] lstar_enter+0xae/0x120
(XEN)    [<ffff82d0803724a0>] lstar_enter+0x110/0x120
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 1:
(XEN) Assertion 'preemptible' failed at mm.c:2493
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

4.8.5 too [Re: Xen 4.11.1 panic]

[Manuel Bouyer]

On Tue, Dec 18, 2018 at 11:19:04PM +0100, Manuel Bouyer wrote:
> Hello,
> I tried updating my NetBSD dom0 to 4.11.1 (from 4.11.0 with security patches),
> and on a 32bits PV domU shutdown I get (100% reproductible):

I get the same panic on 4.8.5. Also, I didn't mention it but there's
no problems with 64bits PV guests.

(XEN) Assertion 'preemptible' failed at mm.c:2593                           
(XEN) ----[ Xen-4.8.5nb0  x86_64  debug=y   Tainted:  C   ]----             
(XEN) CPU:    1                                                             
(XEN) RIP:    e008:[<ffff82d08017c66b>] free_page_type+0x23b/0x790          
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor (d0v0)                 
(XEN) rax: 2000000000000000   rbx: 2400000000000001   rcx: 2000000000000000 
(XEN) rdx: ffff830000000000   rsi: 2400000000000001   rdi: ffff82e004215260 
(XEN) rbp: ffff82e004215260   rsp: ffff83023704fad8   r8:  0000000000000000 
(XEN) r9:  0000000000000000   r10: ffff82e000000000   r11: 0000000000000001 
(XEN) r12: 0000000000000000   r13: ffff830213136000   r14: 007fffffffffffff
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 0000000000002660
(XEN) cr3: 000000022f0f6000   cr2: 00007f7ff60ce7a0
(XEN) fsb: 00007f7ff7ff27c0   gsb: ffffffff80ca42c0   gss: 0000000000000000
(XEN) ds: 003f   es: 003f   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen code around <ffff82d08017c66b> (free_page_type+0x23b/0x790):
(XEN)  05 00 00 45 85 e4 75 02 <0f> 0b 8b 45 18 85 c0 74 18 89 c0 48 c1 e0 0c 49
(XEN) Xen stack trace from rsp=ffff83023704fad8:
(XEN)    ffff82d08024c7fb ffff82d08014703d 2400000000000001 2400000000000001
(XEN)    ffff82e004215260 ffff82e004215240 007fffffffffffff 0000000000000000
(XEN)    ffff82d08017cc76 00ff82d08013133d ffff83023704ffff ffff82e004215260
(XEN)    ffff82e004215240 ffff830213136000 0000000000210a92 ffff820040002000
(XEN)    0200000000000000 ffff82d08017d6a7 00000000000001ff ffff82d08017c737
(XEN)    1000000000000000 ffff83023704ffff 2400000000000001 2400000000000001
(XEN)    ffff82e004215240 ffff82e004206ce0 007fffffffffffff 0000000000000001
(XEN)    ffff82d08017cc76 01ff830237044000 ffff83023704ffff ffff82e004215240
(XEN)    ffff82e004206ce0 0000000000000000 0000000000000000 ffff820040000010
(XEN)    ffff820040000000 ffff82d08017c400 0000000000000002 ffff82e004206ce0
(XEN)    0000000000000000 0000000000000000 ffff82d08017c89f 0000000000210367
(XEN)    ffff830213136000 3400000000000001 3400000000000001 ffff82e004206ce0
(XEN)    0000000000000000 007fffffffffffff 0000000000000001 ffff82d08017cc76
(XEN)    01ff82e004225fe0 ffff83023704ffff ffff82e004206ce0 ffff83023704fd10
(XEN)    ffff830213136028 ffff830213136000 ffff830213136020 ffff82e004206cf0
(XEN)    ffff82d08017d6ef ffff82d08016570b ffff82d08017d850 7400000000000001
(XEN)    ffff83023704ffff 4000000000000000 ffff830213136000 0000000000000000
(XEN)    0000000000000000 deadbeefdeadf00d 0000000000000001 ffff830213136020
(XEN)    ffff82d08016b4b3 ffff830213136000 00007f7ff7b2e004 ffff82d080106882
(XEN)    ffff830213136000 00007f7ff7b2e004 0000000000000000 ffff82d0801039ec
(XEN) Xen call trace:
(XEN)    [<ffff82d08017c66b>] free_page_type+0x23b/0x790
(XEN)    [<ffff82d08024c7fb>] common_interrupt+0x9b/0x120
(XEN)    [<ffff82d08014703d>] ns16550.c#ns16550_interrupt+0x5d/0x70
(XEN)    [<ffff82d08017cc76>] mm.c#_put_page_type+0xb6/0x2f0
(XEN)    [<ffff82d08017d6a7>] mm.c#put_page_from_l2e+0x197/0x1d0
(XEN)    [<ffff82d08017c737>] free_page_type+0x307/0x790
(XEN)    [<ffff82d08017cc76>] mm.c#_put_page_type+0xb6/0x2f0
(XEN)    [<ffff82d08017c400>] mm.c#put_page_from_l3e+0x1a0/0x1d0
(XEN)    [<ffff82d08017c89f>] free_page_type+0x46f/0x790
(XEN)    [<ffff82d08017cc76>] mm.c#_put_page_type+0xb6/0x2f0
(XEN)    [<ffff82d08017d6ef>] put_page_type_preemptible+0xf/0x10
(XEN)    [<ffff82d08016570b>] domain.c#relinquish_memory+0xab/0x450
(XEN)    [<ffff82d08017d850>] destroy_gdt+0x160/0x1b0
(XEN)    [<ffff82d08016b4b3>] domain_relinquish_resources+0x203/0x290
(XEN)    [<ffff82d080106882>] domain_kill+0x92/0x130
(XEN)    [<ffff82d0801039ec>] do_domctl+0x80c/0x1a70
(XEN)    [<ffff82d0801031e0>] do_domctl+0/0x1a70
(XEN)    [<ffff82d08016cb08>] pv_hypercall+0x208/0x420
(XEN)    [<ffff82d08024c432>] lstar_enter+0xa2/0x120
(XEN)    [<ffff82d08024c43e>] lstar_enter+0xae/0x120
(XEN)    [<ffff82d08024c432>] lstar_enter+0xa2/0x120
(XEN)    [<ffff82d08024c43e>] lstar_enter+0xae/0x120
(XEN)    [<ffff82d08024c432>] lstar_enter+0xa2/0x120
(XEN)    [<ffff82d08024c43e>] lstar_enter+0xae/0x120
(XEN)    [<ffff82d08024c4a0>] lstar_enter+0x110/0x120
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 1:
(XEN) Assertion 'preemptible' failed at mm.c:2593
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.11.1 panic

[Jan Beulich]

>>> On 18.12.18 at 23:19, <bouyer@antioche.eu.org> wrote:
> I tried updating my NetBSD dom0 to 4.11.1 (from 4.11.0 with security patches),

Hmm, the issue stems from the XSA-273 changes, so did you perhaps
mean "with some security patches", and you didn't have those ones
applied?

> and on a 32bits PV domU shutdown I get (100% reproductible):
> (XEN) Assertion 'preemptible' failed at mm.c:2493                           
> (XEN) ----[ Xen-4.11.1nb0  x86_64  debug=y   Tainted:  C   ]----            
> (XEN) CPU:    1                                                             
> (XEN) RIP:    e008:[<ffff82d08028b192>] free_page_type+0x232/0x790          
> (XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor (d0v0)                 
> (XEN) rax: 4000000000000000   rbx: 4400000000000001   rcx: 4000000000000000 
> (XEN) rdx: ffff830000000000   rsi: 4400000000000001   rdi: ffff82e004215260 
> (XEN) rbp: ffff82e004215260   rsp: ffff83023704fab8   r8:  0000000000000000 
> (XEN) r9:  0000000000000000   r10: ffff82e000000000   r11: ffff82e004226000 
> (XEN) r12: 0000000000000000   r13: ffff8302135d9000   r14: 10ffffffffffffff 
> (XEN) r15: 1000000000000000   cr0: 000000008005003b   cr4: 0000000000002660 
> (XEN) cr3: 000000022f0f6000   cr2: 00007f7ff60ce7a0
> (XEN) fsb: 00007f7ff7ff36c0   gsb: ffffffff80ca42c0   gss: 0000000000000000
> (XEN) ds: 003f   es: 003f   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen code around <ffff82d08028b192> (free_page_type+0x232/0x790):
> (XEN)  05 00 00 45 85 e4 75 02 <0f> 0b 8b 45 18 85 c0 74 18 89 c0 48 c1 e0 0c 
> 49
> (XEN) Xen stack trace from rsp=ffff83023704fab8:
> (XEN)    ffff83023704fe38 00000000000000ec 4400000000000001 ffff82e004215260
> (XEN)    ffff82e004215240 00ffffffffffffff 10ffffffffffffff 1000000000000000
> (XEN)    ffff82d08028b83d 00ff8300bedfc000 ffff83023704ffff ffff82d000000000
> (XEN)    ffff82e004215260 ffff82e004215240 ffff8302135d9000 0000000000210a92
> (XEN)    ffff820040019000 0200000000000000 ffff82d08028bedf 00000000000001ff
> (XEN)    ffff82e004215240 ffff82d08028b25e ffff830200000000 ffff83023704ffff
> (XEN)    4400000000000001 ffff82e004215240 ffff82e004206c60 00ffffffffffffff
> (XEN)    10ffffffffffffff 1000000000000000 ffff82d08028b83d 0100000000000002
> (XEN)    ffff83023704ffff ffff830200000001 ffff82e004215240 ffff82e004206c60
> (XEN)    0000000000000000 ffff820040015010 0000000000000000 ffff820040015000
> (XEN)    ffff82d08028af30 0000000000000002 ffff82e004206c60 0000000000000000
> (XEN)    ffff820040015010 ffff82d08028b3d1 0000000000210363 ffff8302135d9000
> (XEN)    6400000000000001 ffff82e004206c60 0000000000000000 00ffffffffffffff
> (XEN)    10ffffffffffffff 1000000000000000 ffff82d08028b83d 01ff82d08022697f
> (XEN)    ffff83023704ffff ffff830200000001 ffff82e004206c60 ffff83023704fd10
> (XEN)    ffff8302135d9028 ffff8302135d9000 ffff8302135d9020 ffff82e004206c70
> (XEN)    ffff82d08028bf1f ffff82d080274e6b ffff83023701ec00 e400000000000001
> (XEN)    ffff83023704ffff 8000000000000000 ffff8302135d9000 0000000000000000
> (XEN)    ffff8302135d9018 deadbeefdeadf00d 0000000000000001 00007f7ff7b32004
> (XEN)    ffff82d080278f83 ffff8302135d9000 00007f7ff7b32004 ffff82d080208b2d
> (XEN) Xen call trace:
> (XEN)    [<ffff82d08028b192>] free_page_type+0x232/0x790
> (XEN)    [<ffff82d08028b83d>] mm.c#_put_page_type+0x14d/0x380
> (XEN)    [<ffff82d08028bedf>] mm.c#put_page_from_l2e+0xdf/0x110
> (XEN)    [<ffff82d08028b25e>] free_page_type+0x2fe/0x790
> (XEN)    [<ffff82d08028b83d>] mm.c#_put_page_type+0x14d/0x380
> (XEN)    [<ffff82d08028af30>] mm.c#put_page_from_l3e+0x1a0/0x1d0

The line number above doesn't match any one with a respective
ASSERT() in plain 4.11.1. There are a few nearby ones, and hence
I can only guess that it's the one that was recently added (in
PGT_l2_page_table handling of free_page_type()). Can you confirm
this please with the exact sources you've used for your build?

In any event, both Andrew and I must have overlooked the one
crucial place due to which the assertion is indeed wrong from
put_page_from_l2e():

        int rc = _put_page_type(pg, false, mfn_to_page(_mfn(pfn)));

Not allowing for preemption there is fine if the L2E is pointing to
an L1 table, but is now wrong if the L2E points to another L2,
which surely is the case when you see the assertion trigger.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.11.1 panic

[Manuel Bouyer]

On Wed, Dec 19, 2018 at 04:05:57AM -0700, Jan Beulich wrote:
> >>> On 18.12.18 at 23:19, <bouyer@antioche.eu.org> wrote:
> > I tried updating my NetBSD dom0 to 4.11.1 (from 4.11.0 with security patches),
> 
> Hmm, the issue stems from the XSA-273 changes, so did you perhaps
> mean "with some security patches", and you didn't have those ones
> applied?

Yes, for some reason XSA-273 isn't in the list of patches I had for
Xen 4.11.0. I guess I forgot it ...

> 
> > and on a 32bits PV domU shutdown I get (100% reproductible):
> > (XEN) Assertion 'preemptible' failed at mm.c:2493                           
> [...]
> 
> The line number above doesn't match any one with a respective
> ASSERT() in plain 4.11.1. There are a few nearby ones, and hence
> I can only guess that it's the one that was recently added (in
> PGT_l2_page_table handling of free_page_type()). Can you confirm
> this please with the exact sources you've used for your build?

Here's what I have in xen/arch/x86/mm.c:
  2486      switch ( type & PGT_type_mask )  
  2487      {
  2488      case PGT_l1_page_table:
  2489          free_l1_table(page);
  2490          rc = 0; 
  2491          break;
  2492      case PGT_l2_page_table:
  2493          ASSERT(preemptible);
  2494          rc = free_l2_table(page); 
  2495          break; 
  2496      case PGT_l3_page_table:
  2497          ASSERT(preemptible);
  2498          rc = free_l3_table(page);
  2499          break;
  2500      case PGT_l4_page_table: 
  2501          ASSERT(preemptible);
  2502          rc = free_l4_table(page);
  2503          break;
  2504      default:

This is in free_page_type()

> 
> In any event, both Andrew and I must have overlooked the one
> crucial place due to which the assertion is indeed wrong from
> put_page_from_l2e():
> 
>         int rc = _put_page_type(pg, false, mfn_to_page(_mfn(pfn)));
> 
> Not allowing for preemption there is fine if the L2E is pointing to
> an L1 table, but is now wrong if the L2E points to another L2,
> which surely is the case when you see the assertion trigger.

Should we just change false to true here, or should the cases above be handled
differently ?

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.11.1 panic

[Jan Beulich]

>>> On 19.12.18 at 12:55, <bouyer@antioche.eu.org> wrote:
> On Wed, Dec 19, 2018 at 04:05:57AM -0700, Jan Beulich wrote:
>> In any event, both Andrew and I must have overlooked the one
>> crucial place due to which the assertion is indeed wrong from
>> put_page_from_l2e():
>> 
>>         int rc = _put_page_type(pg, false, mfn_to_page(_mfn(pfn)));
>> 
>> Not allowing for preemption there is fine if the L2E is pointing to
>> an L1 table, but is now wrong if the L2E points to another L2,
>> which surely is the case when you see the assertion trigger.
> 
> Should we just change false to true here, or should the cases above be 
> handled differently ?

Switching from false to true here is just the initial part of the
necessary change - if you did just this, you'd end up hitting
the ASSERT() right after the line above. There's quite a bit
more to it, and it needs to be done pretty carefully.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.11.1 panic

[Manuel Bouyer]

On Wed, Dec 19, 2018 at 05:54:42AM -0700, Jan Beulich wrote:
> >>> On 19.12.18 at 12:55, <bouyer@antioche.eu.org> wrote:
> > On Wed, Dec 19, 2018 at 04:05:57AM -0700, Jan Beulich wrote:
> >> In any event, both Andrew and I must have overlooked the one
> >> crucial place due to which the assertion is indeed wrong from
> >> put_page_from_l2e():
> >> 
> >>         int rc = _put_page_type(pg, false, mfn_to_page(_mfn(pfn)));
> >> 
> >> Not allowing for preemption there is fine if the L2E is pointing to
> >> an L1 table, but is now wrong if the L2E points to another L2,
> >> which surely is the case when you see the assertion trigger.
> > 
> > Should we just change false to true here, or should the cases above be 
> > handled differently ?
> 
> Switching from false to true here is just the initial part of the
> necessary change - if you did just this, you'd end up hitting
> the ASSERT() right after the line above. There's quite a bit
> more to it, and it needs to be done pretty carefully.

OK, so I'll wait for a more complete patch :)

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.11.1 panic

[Jan Beulich]

>>> On 19.12.18 at 13:54, <JBeulich@suse.com> wrote:
>>>> On 19.12.18 at 12:55, <bouyer@antioche.eu.org> wrote:
>> On Wed, Dec 19, 2018 at 04:05:57AM -0700, Jan Beulich wrote:
>>> In any event, both Andrew and I must have overlooked the one
>>> crucial place due to which the assertion is indeed wrong from
>>> put_page_from_l2e():
>>> 
>>>         int rc = _put_page_type(pg, false, mfn_to_page(_mfn(pfn)));
>>> 
>>> Not allowing for preemption there is fine if the L2E is pointing to
>>> an L1 table, but is now wrong if the L2E points to another L2,
>>> which surely is the case when you see the assertion trigger.
>> 
>> Should we just change false to true here, or should the cases above be 
>> handled differently ?
> 
> Switching from false to true here is just the initial part of the
> necessary change - if you did just this, you'd end up hitting
> the ASSERT() right after the line above. There's quite a bit
> more to it, and it needs to be done pretty carefully.

Actually there was no reason to alter the free_l2_table() paths
in the XSA-273 fixes: A switch to shadow mode can only occur
when validating page tables. Therefore I think you could safely
revert the respective hunks, which includes deleting the
ASSERT() you found triggering.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen 4.11.1 panic

[Manuel Bouyer]

On Thu, Dec 20, 2018 at 12:36:35AM -0700, Jan Beulich wrote:
> >>> On 19.12.18 at 13:54, <JBeulich@suse.com> wrote:
> >>>> On 19.12.18 at 12:55, <bouyer@antioche.eu.org> wrote:
> >> On Wed, Dec 19, 2018 at 04:05:57AM -0700, Jan Beulich wrote:
> >>> In any event, both Andrew and I must have overlooked the one
> >>> crucial place due to which the assertion is indeed wrong from
> >>> put_page_from_l2e():
> >>> 
> >>>         int rc = _put_page_type(pg, false, mfn_to_page(_mfn(pfn)));
> >>> 
> >>> Not allowing for preemption there is fine if the L2E is pointing to
> >>> an L1 table, but is now wrong if the L2E points to another L2,
> >>> which surely is the case when you see the assertion trigger.
> >> 
> >> Should we just change false to true here, or should the cases above be 
> >> handled differently ?
> > 
> > Switching from false to true here is just the initial part of the
> > necessary change - if you did just this, you'd end up hitting
> > the ASSERT() right after the line above. There's quite a bit
> > more to it, and it needs to be done pretty carefully.
> 
> Actually there was no reason to alter the free_l2_table() paths
> in the XSA-273 fixes: A switch to shadow mode can only occur
> when validating page tables. Therefore I think you could safely
> revert the respective hunks, which includes deleting the
> ASSERT() you found triggering.

You mean, Xen is not going to fix this ?

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel