I finally nailed the last stability issue related to the patchset this
morning. It is an extremely old issue and I tried to locate the root
cause for it with Richard off-list 2 years ago. Unfortunately it was
without success at that time.
This issue is inherent in "stock" UML, but very difficul
From: Anton Ivanov
This is a fix for a very old UML bug which can be triggered with stock
UML. It takes a lot of effort to trigger it there because the
lseek()/read() | write() mechanics of the UBD driver implicitly sync the
memory all the time by hitting the appropriate barrier implementation
Am 26.09.2014 13:49, schrieb anton.iva...@kot-begemot.co.uk:
> From: Anton Ivanov
>
> This is a fix for a very old UML bug which can be triggered with stock
> UML. It takes a lot of effort to trigger it there because the
> lseek()/read() | write() mechanics of the UBD driver implicitly sync the
On 26/09/14 12:56, Richard Weinberger wrote:
[snip]
> +#ifdef CONFIG_X86_32
> + alternative("lock; addl $0,0(%%esp)", "mfence", X86_FEATURE_XMM2);
> +#else
> + asm volatile("mfence":::"memory");
> +#endif
> Why not mb()?
> I'm not sure whether this fix is correct.
Looking at the actual d
From: Anton Ivanov
Occasionally, under very heavy load inside UML, on host
or both one of the processes in UML will remain in D state
or will fail to reap a child which will sit in Z state.
This is very difficult to reproduce with stock UML because
the lseek()/read()|write()|fsync() in the ubd d
