From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754040AbbJPLuM (ORCPT ); Fri, 16 Oct 2015 07:50:12 -0400 Received: from e06smtp15.uk.ibm.com ([195.75.94.111]:36731 "EHLO e06smtp15.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753640AbbJPLuJ (ORCPT ); Fri, 16 Oct 2015 07:50:09 -0400 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: heiko.carstens@de.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Fri, 16 Oct 2015 13:50:03 +0200 From: Heiko Carstens To: Thomas Gleixner , Stefan Liebler , Preeti U Murthy , Peter Zijlstra , linux-kernel@vger.kernel.org Subject: Re: futex timeout not working? (bisected) Message-ID: <20151016115003.GC6354@osiris> References: <20151015104347.GA4166@osiris> <20151016103123.GE4684@osiris> <20151016105451.GB6354@osiris> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151016105451.GB6354@osiris> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15101611-0021-0000-0000-000007942A9C Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 16, 2015 at 12:54:51PM +0200, Heiko Carstens wrote: > > > So you are saying this works on x86 and it must be some s390 specific bug? > > > > Looks like. I have no idea why that would break on s390. Did you try > > to revert the commit on top of tree? > > Reverting the patch isn't easy due to all the dependencies the code has in > the meantime. However the following code snippet does logically revert the > patch and it works again: > > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c > index 3739ac6aa473..c97dd1cc9bd5 100644 > --- a/kernel/time/timekeeping.c > +++ b/kernel/time/timekeeping.c > @@ -1953,12 +1953,10 @@ ktime_t ktime_get_update_offsets_now(unsigned int *cwsseq, ktime_t *offs_real, > nsecs = timekeeping_get_ns(&tk->tkr_mono); > base = ktime_add_ns(base, nsecs); > > - if (*cwsseq != tk->clock_was_set_seq) { > - *cwsseq = tk->clock_was_set_seq; > - *offs_real = tk->offs_real; > - *offs_boot = tk->offs_boot; > - *offs_tai = tk->offs_tai; > - } > + *cwsseq = tk->clock_was_set_seq; > + *offs_real = tk->offs_real; > + *offs_boot = tk->offs_boot; > + *offs_tai = tk->offs_tai; Adding the patch below also "fixes" this. Right now I don't see why this could architecture specific. Hmm. diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 3739ac6aa473..75771b15647c 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -1835,7 +1835,7 @@ void update_wall_time(void) * memcpy under the tk_core.seq against one before we start * updating. */ - timekeeping_update(tk, clock_set); + timekeeping_update(tk, clock_set | TK_CLOCK_WAS_SET); memcpy(real_tk, tk, sizeof(*tk)); /* The memcpy must come last. Do not put anything here! */ write_seqcount_end(&tk_core.seq);