linux-kernel - Re: [patch 2/3] pvclock: detect watchdog reset at pvclock read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Oct 2013 14:22:09 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	Marcelo Tosatti <mtosatti@...hat.com>
Cc:	kvm@...r.kernel.org, pbonzini@...hat.com, gleb@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 2/3] pvclock: detect watchdog reset at pvclock read

On Wed, Oct 09, 2013 at 06:26:33PM -0300, Marcelo Tosatti wrote:
> From https://lkml.org/lkml/2013/7/3/675:
> 
> "Agree. However, can't see how there is a way around "having custom
> kvm/paravirt splat all over", for watchdogs that do:
> 
> 1. check for watchdog resets
> 2. read time via sched_clock or xtime.
> 3. based on 2, decide whether there has been a longer delay than
> acceptable.
> 
> This is the case for the softlockup timer interrupt. So the splat there
> is necessary (otherwise any potential notification of vm-pause event 
> noticed at 2 might be missed because its checked at 1).
> 
> For watchdogs that measure time based on interrupt event (such as hung
> task, rcu_cpu_stall, checking for the notification at sched_clock or
> lower is fine)."
> 

Sorry for the delay, I was trying to spend time understanding the problem
again.  Rik van Riel helped me (as I could just walk over to him).

I was trying to figure out if there was a way to convert the softlockup to
something more virt-friendly mechanism.  I was toying with the idea of
having the softlockup use schedule_timeout and then have the
touch_softlockup routine keep rescheduling (delay) the timeout.  The idea
was that if it actually timed out, it was guaranteed to be a lockup.  This
removed the need for the duration calculation but more importantly, I
believe the schedule_timeout routine was guest time aware.

But I haven't had the chance to think through the whole thing to know if
that was the right way to go or if there was pitfalls.  Just busy with
other stuff.

Regardless, I think this patchset solves a particular problem and I am ok
with it (even v2 I believe).

Cheers,
Don

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/