On 08/01/2020 10:43, Juergen Gross wrote:
> console_force_unlock() might result in subsequent ASSERT() triggering
> when CONFIG_DEBUG_LOCKS was active. Avoid that by calling
> spin_debug_disable() in console_force_unlock() and make the spinlock
> debug assertions trigger only if spin_debug was active.
>
> Signed-off-by: Juergen Gross <jgr...@suse.com>
> ---
> xen/common/spinlock.c | 2 +-
> xen/drivers/char/console.c | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
> index ed69f0a4d2..2a06de3e6a 100644
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -85,7 +85,7 @@ static void got_lock(union lock_debug *debug)
>
> static void rel_lock(union lock_debug *debug)
> {
> - ASSERT(debug->cpu == smp_processor_id());
> + ASSERT(atomic_read(&spin_debug) <= 0 || debug->cpu ==
> smp_processor_id());
Personally, I think the logic would be easier to follow as:
if ( atomic_read(&spin_debug) )
ASSERT(debug->cpu == smp_processor_id());
Otherwise, LGTM. Acked-by: Andrew Cooper <andrew.coop...@citrix.com>.
Can be fixed on commit if you agree.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
