On Tue, Apr 11, 2017 at 06:31:36AM -0600, Jan Beulich wrote:
> >>> On 11.04.17 at 13:24, wrote:
> > On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote:
> >> >>> On 10.04.17 at 21:44, wrote:
> >> wouldn't it be better to handle this with a static state variable,
> >> which gets checked/se
>>> On 11.04.17 at 13:24, wrote:
> On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote:
>> >>> On 10.04.17 at 21:44, wrote:
>> wouldn't it be better to handle this with a static state variable,
>> which gets checked/set atomically, and which if already set simply
>> leads to a continuatio
On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote:
> >>> On 10.04.17 at 21:44, wrote:
>
> Please don't forget Cc-ing the maintainer(s) of the code being modified.
>
> > @@ -1187,12 +1182,22 @@ static int do_kexec_op_internal(unsigned long op,
> > XEN_GUES
>>> On 10.04.17 at 21:44, wrote:
Please don't forget Cc-ing the maintainer(s) of the code being modified.
> @@ -1187,12 +1182,22 @@ static int do_kexec_op_internal(unsigned long op,
> XEN_GUEST_HANDLE_PARAM(void) uarg,
> bool_t co
When we concurrently try to unload and load crash
images we eventually get:
Xen call trace:
[] machine_kexec_add_page+0x3a0/0x3fa
[] machine_kexec_load+0xdb/0x107
[] kexec.c#kexec_load_slot+0x11/0x42
[] kexec.c#kexec_load+0x119/0x150
[] kexec.c#do_kexec_op_internal+0xab/0xcf