From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754849AbbKYJEY (ORCPT ); Wed, 25 Nov 2015 04:04:24 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:50352 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754767AbbKYJEQ (ORCPT ); Wed, 25 Nov 2015 04:04:16 -0500 From: Arnd Bergmann To: y2038@lists.linaro.org Cc: Alison Schofield , achim_leubner@adaptec.com, JBottomley@odin.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [Y2038] [PATCH v2] scsi: gdth: replace struct timeval with ktime_get_real_seconds() Date: Wed, 25 Nov 2015 10:03:57 +0100 Message-ID: <3133545.iF2pfcmJbC@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <1448412247-2716-1-git-send-email-amsfield22@gmail.com> References: <20151119214304.GA16713@d830.WORKGROUP> <1448412247-2716-1-git-send-email-amsfield22@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:wPeujA0tBk5J/3rwxgOtts9n2RBmb1BQHMROYeW1DuwB0XIGfiJ eHv96/Wmd5b7pTOBK0kU7KA3As6Ny3EPYfaXOQJHN7PLbXAcG1SbXo+nDUPs/8AsTdXxOGi IspJ6FRBJmGm7Rudmf/bVoUA2yotdRkx3WlA7XoERfJqEHxa1mAjF5doYldmjthmtHZiST9 fhICcth9EJ+2HlgvlFQOQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Ow9ISbdDZvw=:znMtGnpO/343df601zUKm2 OMuB3REGCRJtovTPjrZcaRqKfp56HI+Rfi7ITqR1E2M7VJn76zPVGEqY5uh7iYN/Ba8gPHFXk P4uVm/4jaenhktRhESqjVucKnHn+6MG7kMU9kgbbVDnAZdRuWkihMrJ3P3N0MONCMXYixx4EF ANxYKgvA4aJ5d2jxclK0SMBAdndzcU0CayXHXNHQaV0dH6BR5mPWaW8KUeqzxFxf4OhRl5OjB HR8vn0Gyga15zOaMoINlLc+Era3UCeTTomrOD7UN8e3WUxKNOk52V1/fZ1gaWYxQXyDpMnrna Kr5qzwxhBKYX+yE2fTNQ5UG2QPd2eIwP4dRSPdqBp6tvyB/AwiqDyVnL8zLYd7KP1oY3TTh+I 10uLtnhhudJq5p6tIs0rwDTWw9LlubVCb9C0W73SGWlLaCDYVMYGrwgfeC2PdwNEAmfTD3+Xh vwJu+AgP82m6l4lm5A56A3X/UwJZVZsBsxe8PD+/pIOjnOnmprypQTtVTRIoInZM7rq34ZfWo Mle5NNGF3BEEoOAnUALTCAbylPZbMT7EUOUoeArhFk48d41iLHc/saYi21sbN8Z0t5kT2cZrU 0H3KXGj9ZjXcF2Zbx11dNkr7ci/WtD2+IWk/qdeBaKy/NPeqqqyImAzrJjau00N5w4ODM91KW 1H+6rhGej/snPqCKAOgGfle11CiAyBI4wndPB0ED91Ozpe11lPSkeIrdmqX+b0yJovBPp+FQ2 nDFlr5K6TOKnzizA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 24 November 2015 16:44:07 Alison Schofield wrote: > struct timeval will overflow on 32-bit systems in y2038 and is being > removed from the kernel. Replace the use of struct timeval and > do_gettimeofday() with ktime_get_real_seconds() which provides a 64-bit > seconds value and is y2038 safe. > > gdth driver requires changes in two areas: > > 1) gdth_store_event() loads two u32 timestamp fields for ioctl GDTIOCTL_EVENT > > These timestamp fields are part of struct gdth_evt_str used for passing > event data to userspace. At the first instance of an event we do > (first_stamp=last_stamp="current time"). If that same event repeats, > we do (last_stamp="current time") AND increment same_count to indicate > how many times the event has repeated since first_stamp. > > This patch replaces the use of timeval and do_gettimeofday() with > ktime_get_real_seconds() cast to u32 to extend the timestamp fields > to y2106. > > Beyond y2106, the userspace tools (ie. RAID controller monitors) can > work around the time rollover and this driver would still not need to > change. > > Alternative: The alternative approach is to introduce a new ioctl in gdth > with the u32 time fields defined as u64. This would require userspace > changes now, but not in y2106. > > 2) gdth_show_info() calculates elapsed time using u32 first_stamp > > It is adding events with timestamps to a seq_file. Timestamps are > calculated as the "current time" minus the first_stamp. > > This patch replaces the use of timeval and do_gettimeofday() with > ktime_get_real_seconds() cast to u32 to calculate the timestamp. > > This elapsed time calculation is safe even when the time wraps (beyond > y2106) due to how unsigned subtraction works. A comment has been added > to the code to indicate this safety. > > Alternative: This piece itself doesn't warrant an alternative, but > if we do introduce a new structure & ioctl with u64 timestamps, this > would change accordingly. > > Signed-off-by: Alison Schofield Reviewed-by: Arnd Bergmann