linux-kernel - Re: [PATCH v3 3/6] xen: introduce XENPF

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:	Thu, 12 Nov 2015 17:10:07 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	xen-devel@...ts.xensource.com,
	linux-arm-kernel@...ts.infradead.org, Ian.Campbell@...rix.com,
	linux-kernel@...r.kernel.org, konrad.wilk@...cle.com,
	david.vrabel@...rix.com
Subject: Re: [PATCH v3 3/6] xen: introduce XENPF_settime64

On Thursday 12 November 2015 10:30:23 Boris Ostrovsky wrote:
> > diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> > index 663c2ea..3bbd377 100644
> > --- a/arch/x86/xen/time.c
> > +++ b/arch/x86/xen/time.c
> > @@ -134,10 +134,10 @@ static int xen_pvclock_gtod_notify(struct notifier_block *nb,
> >       if (!was_set && timespec_compare(&now, &next_sync) < 0)
> >               return NOTIFY_OK;
> >   
> > -     op.cmd = XENPF_settime;
> > -     op.u.settime.secs = now.tv_sec;
> > -     op.u.settime.nsecs = now.tv_nsec;
> > -     op.u.settime.system_time = xen_clocksource_read();
> > +     op.cmd = XENPF_settime32;
> > +     op.u.settime32.secs = now.tv_sec;
> > +     op.u.settime32.nsecs = now.tv_nsec;
> > +     op.u.settime32.system_time = xen_clocksource_read();
> 
> Can/should we switch to time64 here? (This would require a couple more 
> changes but they would all be local to this routine).

We definitely should. We are in the process of removing all uses of
timespec from the kernel in favor of timespec64, and this requires
changing the Xen code as well if we want to do it right. I suppose that
both Dom0 and DomU will have to support the old and the new interface
for x86, so we have a fallback if the 64-bit interface fails.

	Arnd
--
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/