linux-kernel - Re: [RFC PATCH v2 05/11] time: Convert all users of do_settimeofday() to use do

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 30 Oct 2014 17:06:29 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	John Stultz <john.stultz@...aro.org>
cc:	"pang.xunlei" <pang.xunlei@...aro.org>,
	lkml <linux-kernel@...r.kernel.org>,
	"rtc-linux@...glegroups.com" <rtc-linux@...glegroups.com>,
	xen-devel@...ts.xenproject.org,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>
Subject: Re: [RFC PATCH v2 05/11] time: Convert all users of do_settimeofday()
 to use do_settimeofday64()

On Thu, 30 Oct 2014, John Stultz wrote:
> On Thu, Oct 30, 2014 at 7:49 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > First of all this wants to be a seperate patch. Secondly it wants to
> > be a patch series which addresses the whole XEN space which is
> > involved in this. That involves other changes to x86 as well, but we
> > really can do better than mechanically pushing the problem one step
> > deeper just to get rid of the non safe do_settimeofday() variant.
> >
> > It does not matter WHEN we remove that. What matters is that we do the
> > conversion in sensible contexts and not by mechanically pushing the
> > problem one layer down, leave cryptic TODO comments around and think
> > we achieved something.
> 
> So agreed that this patch should be broken up.
> 
> And yea, as a side effect of your earlier feedback to add 64bit
> interfaces and slowly migrate, I guess it does make sense to handle
> all the interfaces first, and then cohesively address each subsystem,
> rather then addressing interface by interface through the whole
> system.  My suggested partitioning of the problem doesn't produce as
> nice to understand patches.

This is very different to the BKL push down, where we really had to
see the context in the particular file/subsystem to understand what it
was actually protecting or not.

> That said, this is a big project with a number of folks attacking it,
> and as seen in the Xen code (where xen's settime logic bleeds into the
> pv persistent clock logic), if we go subsystem by subsystem rather
> then interface by interface, there will be cases where subsystems
> interact and I think we'll still have to have similar TODOs notes and
> iterations. I think having some greppable tag in the comments will
> help as we iterate through things.

That's fine as long as we do not just go blindly and push stuff down
one level deeper w/o looking at the complete call chain first. Doing
the whole x86 rtc related stuff in one series (after the core
interfaces are in place) avoids the whole todo churn nicely.

Interactions are expected, but we should avoid them if possible by
partitioning the patches in a sensible manner.
 
> > John: What kind of weird hackery is that alarm-dev thing? This should
> > rather die than being fixed.
> 
> I think it was agreed at plumbers that we can drop alarm-dev from
> staging. But if its fixed before its dropped, or just dropped doesn't
> matter.

One pointless patch less :)

We really can leave that alone and either kill do_settimeofday() after
its gone or expedite its death by removing do_settimeofday().

Thanks,

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