linux-kernel - [PATCH 0/3] Timekeeping fixes for 3.13? (v2)

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-next>] [day] [month] [year] [list]

Date:	Fri, 20 Dec 2013 10:59:43 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	John Stultz <john.stultz@...aro.org>,
	Sasha Levin <sasha.levin@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Prarit Bhargava <prarit@...hat.com>,
	Richard Cochran <richardcochran@...il.com>,
	Ingo Molnar <mingo@...nel.org>
Subject: [PATCH 0/3] Timekeeping fixes for 3.13? (v2)

Hey Ingo, Thomas,
	Here are the timekeeping fixes I was hoping to submit for 3.13,
including  the variable naming tweaks you wanted to see.

However, as I've been thinking about this a bit more, I'm a little
on the fence about sending these out this late in the -rc cycle. The 
lockdep splat is new in 3.13 due to the seqlock lockdep enablement,
but the actual potential deadlock is not new.

Also, given its so close to the holiday week, it might be wise to push
off to 3.14 with these. Does that sound reasonable?  If so please just
apply to tip/timers/core instead, and I'll send Thomas the rest of my
3.14 queue soon.

The changes here are:

The first is a regression caused by the shadow time code that
causes the tai offset to be overwritten. This keeps ntpd from being
able to initialize the tai_offset.

The second fixes an issue where the action flag returned from
accumulate_nsecs_to_secs was not being passed all the way down
to where we update the pv notifiers. While not critical, this
change is a prerequisite for the following critical fix.

The last patch fixes the potential timekeeping/hrtimer
deadlock Sasha found caused by clock_was_set_delayed() not actually
being safe to call while holding the timekeeping lock. This
leverages the previous patch to move the call outside the lock.

I have a number of other fixes queued, including the cleanup to the
tick code that will let us stop using clock_was_set_delayed all
together in the timekeeping code, but I'll save those for 3.14.

thanks
-john

Cc: Sasha Levin <sasha.levin@...cle.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Prarit Bhargava <prarit@...hat.com>
Cc: Richard Cochran <richardcochran@...il.com>
Cc: Ingo Molnar <mingo@...nel.org>

John Stultz (3):
  timekeeping: Fix lost updates to tai adjustment
  timekeeping: Fix potential lost pv notification of time change
  timekeeping: Avoid possible deadlock from clock_was_set_delayed

 kernel/time/timekeeping.c | 41 +++++++++++++++++++++++++++++------------
 1 file changed, 29 insertions(+), 12 deletions(-)

-- 
1.8.3.2

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