From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750889AbbD3Eff (ORCPT ); Thu, 30 Apr 2015 00:35:35 -0400 Received: from smtp-out-01.shaw.ca ([64.59.136.137]:55717 "EHLO smtp-out-01.shaw.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750717AbbD3Efd (ORCPT ); Thu, 30 Apr 2015 00:35:33 -0400 X-Greylist: delayed 487 seconds by postgrey-1.27 at vger.kernel.org; Thu, 30 Apr 2015 00:35:33 EDT X-Authority-Analysis: v=2.1 cv=HfbeNHw8 c=1 sm=1 tr=0 a=f/edn6q14DUxYFbwN4BeGQ==:117 a=f/edn6q14DUxYFbwN4BeGQ==:17 a=kj9zAlcOel0A:10 a=e9J7MTPGsLIA:10 a=20KFwNOVAAAA:8 a=A8udrbo2KZiBOysc4UYA:9 a=CjuIK1q_8ugA:10 Date: Wed, 29 Apr 2015 23:27:21 -0500 From: Trevor Cordes To: linux-kernel@vger.kernel.org, John Stultz , Thomas Gleixner , Josh Boyer Subject: Re: regression in ktime.h circa 3.16.0-rc5+ breaks lirc irsend, bad commit 166afb64511 Message-ID: <20150429232721.59b89cb1@pog.tecnopolis.ca> In-Reply-To: <20150323165725.GA25008@pog.tecnopolis.ca> References: <20150323165725.GA25008@pog.tecnopolis.ca> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNW+PG/r38T7KkFyZCBbalHKUqk2saCiHLRnazWTyiL4BYStbhrk4EOETS9yGmJD2vKJrS77nJxdn7XT5gBM9CT+S4mxaP/TG+PrRJfdnGpcysbBiL37WQsFZrcuSIGv9npuwWhlWEMac4cekQREVyEwlvEPfHSSq5jHRLpOPJTnCVKXhhgR+gDNIOjB2qb4XCemlyQY2jaZWxrpdQNNfv1+NfFJ3RAEqYM79cvC51Unwt23WCmwAXQbC8WbmvyAo68SgJga62tTK2E8JdmlBHY= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sorry for the top-posting; Josh Boyer suggested I re-mail this mail from last month which didn't get any replies. I'm still having this weird kernel bug affecting me and I've bisected it down to like 2-4 lines of code. (I've thought more about my theory regarding unsigned/signed below and it's probably wrong, so ignore my prognosticating.) Please see my rhbz link near the bottom for the full details. Thanks everyone! On 2015-03-23 Trevor Cordes wrote: > Hello everyone, this is my first attempt at bisecting a kernel to > solve a bug. Please bear with me. > > I have successfully bisected and located a commit that is causing my > problem. Look at commit 166afb64511. > > ktime_to_us returns s64, but the commit changes it so ktime_to_us > just returns what ktime_divns returns, and ktime_divns returns a > u64! If the u64 is big enough, wouldn't it wrap s64 around to a > negative number? Or, perhaps if some caller is passing in negative > ktime_t to begin with it will trigger without having to hit big > numbers. With my limited knowledge of C, I am stabbing in the dark > here. > > That's just my guess as to why this commit causes my problem. My bug > symptom is my previously working MythTV lirc blaster no longer > reliably sends IR signals. Using irsend to test I can see irsend is > just timing out (and only sometimes blasts, usually the first > attempt). On good kernels it returns immediately after blasting. > > This little patch (at bottom of email) that puts the code back in > place and gets rid of the function call fixes the problem for me. I > applied this patch to the very latest FC21 > kernel-PAE-3.19.1-201.fc21.i686 src.rpm and rpmbuilded and the bug is > gone! I can once again MythTV. Hooray. > > I suspect no one else is seeing this because less people are running > 32-bit now, and perhaps in most code paths the value of the u64 never > gets above 2^63. I suspect something in drivers/media (possibly) is > passing very high or negative values (possibly another bug) to these > calls. > > Obviously my patch isn't the real solution, the real solution is to > make the new function calls use a consistent 64-bit type, or figure > out what in my code path is calling these functions and check it for > value sanity. > > I've documented the whole process / details of this bug in RHBZ: > https://bugzilla.redhat.com/show_bug.cgi?id=1200353 > > Thanks! > > diff -uNr a/include/linux/ktime.h b/include/linux/ktime.h > --- a/include/linux/ktime.h 2015-02-08 20:54:22.000000000 -0600 > +++ b/include/linux/ktime.h 2015-03-23 01:09:43.000000000 -0500 > @@ -173,12 +173,16 @@ > > static inline s64 ktime_to_us(const ktime_t kt) > { > - return ktime_divns(kt, NSEC_PER_USEC); > +/* return ktime_divns(kt, NSEC_PER_USEC); */ > + struct timeval tv = ktime_to_timeval(kt); > + return (s64) tv.tv_sec * USEC_PER_SEC + tv.tv_usec; > } > > static inline s64 ktime_to_ms(const ktime_t kt) > { > - return ktime_divns(kt, NSEC_PER_MSEC); > +/* return ktime_divns(kt, NSEC_PER_MSEC); */ > + struct timeval tv = ktime_to_timeval(kt); > + return (s64) tv.tv_sec * MSEC_PER_SEC + tv.tv_usec / > USEC_PER_MSEC; } > > static inline s64 ktime_us_delta(const ktime_t later, const ktime_t > earlier)