From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752171AbcF0TJJ (ORCPT ); Mon, 27 Jun 2016 15:09:09 -0400 Received: from mail-by2on0137.outbound.protection.outlook.com ([207.46.100.137]:52000 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751936AbcF0TJH (ORCPT ); Mon, 27 Jun 2016 15:09:07 -0400 X-Greylist: delayed 3567 seconds by postgrey-1.27 at vger.kernel.org; Mon, 27 Jun 2016 15:09:06 EDT Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Joe.Lawrence@stratus.com; Subject: Re: __rtc_read_alarm missing month/year field bug? To: "linux-kernel@vger.kernel.org" , References: <5768148E.8090304@stratus.com> CC: Alexandre Belloni , Alessandro Zummo From: Joe Lawrence Message-ID: <57716404.9080204@stratus.com> Date: Mon, 27 Jun 2016 13:36:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5768148E.8090304@stratus.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [198.97.42.5] X-ClientProxiedBy: CY1PR0801CA0029.namprd08.prod.outlook.com (10.163.136.167) To BN3PR0801MB2242.namprd08.prod.outlook.com (10.167.3.140) X-MS-Office365-Filtering-Correlation-Id: e0052052-4196-4e27-e795-08d39eb1877e X-Microsoft-Exchange-Diagnostics: 1;BN3PR0801MB2242;2:sLveEY39v3AEPk8oqKaLMi5OjD0rw0hMEYZVlXTjxTRvJ/j1PiiZ4Gr0W6Q30MSwH1cieM3GVgXiS8Va8Lal3UGYfxJZx4IZBwC8FRbWC+nZKVDLPfS6MgdCG4M36wi2/vQBlCMSBQskvHCev7iSF+Yub5/3wOzqQu6G8NqjQFiucWLHSn/2hy8HeuJcouzy;3:R33JugY8Q+2TVJvSiqgQmOE2S5UzJkV54aAuupbFz+X9n2rKIgZI6oTNrkQbTSZStgBI6X+/GC26h5f/139AjP1abrU/4K2YXbU4nZbchtkvIq7DOTCbHYXmfuXyNHpf X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0801MB2242; X-Microsoft-Exchange-Diagnostics: 1;BN3PR0801MB2242;25:osqnygr3MiFBBEYb8WLrlBvN+3rosuEzX+mxLJffaaxKiEMXtXdibuxPbid86K0mpbW5VaIiigH6CX2HNeLxKQL+SVJ05Y8sMTsYXm+IqOJw6725e6ZVkxNuSF8jU7sjb2OgNDOKFxmBaE3+XVDs1KGBdJOTAQyVRzwfBlD5BUG8JlrfgqPIf0nmZbgydyDcYDOMbpG1vKZWNrx4ffx1RY8yZIkv8CojLJabxDHFeKszejE3Ql3MIlC4GUL+szgw4K0Zy485ZzHU24SCs1ewptr1DtLUXsYcIC58bderKBL73DMWM8cV/+Y+9N48iLhtxlbUuFYdQ+0sjucnFNjsMmAcEfK4ZFl3DAN8QtF1X9Kr6UTaY3+s5URqzNzsUVJKaFZEvaGKpNPknz8uzmRyQ5XPc7UtP25FFXYh9V6/OBi+Wlih31FhNISeddMM35ebX1hfboSjHyJYzKf+m/zhA/KWAyeqhAhXLLrswgUmntSS3Gp+J5oiUyYYsyy9OEdCmw7ctyF25PimBYbQlxUHXJcLqEdtBazhQn//efEGo6nGnI0w5IBG48DNJD8vJzzMbC1Uf1QhtGb3y+4u1HAcwbcAFZdtqNOqwjPe+H/0nG60yZlKMjP1jxjb1xn0B/SiX5dSMlNJ5J39pR83BuilnHzbDBAoTMVi2venHYTvYuljo3PT7XMn8Fsk6opfYvelJUH9e8Gcx1VyvKoSpa0iyA==;31:QpWnfyDaPZ6/DonsB7Vma0OdOloxrVpknHQySgmR5lsmCih3uvNNo8fO7uWbA3R883qcYE1KieWR7CYWXNa/325IvirQvPHQOCUd7ZpysCWHskQEreXz66m1selF9ldqiKZahldvvdbCI4sn1mGHlBVIRO4bFHCYKnTT2NYlxh0KfrvOFkWb3xs2njR/jp0NAJSaonWSiCfMhNx45eZWxw== X-Microsoft-Exchange-Diagnostics: 1;BN3PR0801MB2242;20:F9B9mSFZ89IL3kywcGI2L1SnYkKa7HryGKu+LbtMkaok28BBHk1syXnjgs3H3J2aWHuHRQuhNd3GTjs0b3l7VnUgBkElMHul1pZk6yYD68xM5U8FMBoVUHHUqhSOCzWG6QJrl1LnBqNiQeykkaa+9CUz2afGaN7YCVbNWNctj3wxtePVV+M9WZx0e6w8cG4qa+C4JD2EjWDFdoE8Zdzx8wL9Tq9CbfXMuGrvUZQQFunl+MLiZ78f9khku9Mn3LKUQRFO/4fn1e1LkmnvEzSwX7m6WHtRkYeJYKJ0E/X5m+L727FZEH5RWPSxBCqrsy3ZLuRiCLH8VAJRM26lSQW4rU41g8n4ZrigIuDXBnsdGDdnpRYFSFql+bqlqAOHlP/SucSyiijDJtYKbWhxUfNytj7Xj3CF75Wr7tsSINxIct+OWdXSiL+Fk5B9WupSMCufcEKJVH48fA+Ik465ms28rK4AgrHOBMQr5uQ6BvGbtmOMfZjEg8fl5ezBcVad9fap;4:a3kNWUIbPdGbKUrGKQv9S+H/DJJkUDlW0Ju2uk1/lAJ9Avo0omb/iO7I1LZiW6QkUVyxTHDDaUtP+wBI/DzfaveIfmFTlk71vZrNg7tWuFmP+/zz4Vbx/zVLB3lLjfV/wQigrB87m15C6C4BoQFXore91UrNGMnk7G7zEWlimvUvGRkMkDfqaZ1pGnM7Ft3xpIRCwhcAB5yZC6sthD4ER7MM6Xs2nKHij6+uXkDMTg5d1YkP4TOirrDvYkP4erGtTPQYa0kPhXnaqSZaNXpjbUTmPGEIy9zTiFB9/45hZRDiWGFTzxC+ZMyGprFN1r0tWhHndz8HYJ3Lu1SEF+GAUq8LlBph5iEnL+tQ5cVd9FdjKdDmSpm8BVFfQY1fHBIPBkOeG6+VqLtyv/ZUbvEAJS/ZqWvUbdDJeOIoKuM6VB8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);SRVR:BN3PR0801MB2242;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0801MB2242; X-Forefront-PRVS: 09860C2161 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(199003)(24454002)(377454003)(377424004)(117636001)(42186005)(59896002)(5890100001)(106356001)(105586002)(99136001)(47776003)(65956001)(66066001)(65816999)(65806001)(77096005)(230700001)(23676002)(189998001)(2950100001)(122286003)(4326007)(5001770100001)(97736004)(2501003)(586003)(50466002)(19580395003)(3846002)(19580405001)(6116002)(4001350100001)(64126003)(83506001)(36756003)(81166006)(81156014)(8676002)(68736007)(2906002)(54356999)(76176999)(101416001)(50986999)(92566002)(7846002)(86362001)(87266999)(305945005)(7736002)(62816006);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR0801MB2242;H:jlaw-desktop.mno.stratus.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA4MDFNQjIyNDI7MjM6TW5CZXdZelNmeXJFZmFENnBoTmFlVDkr?= =?utf-8?B?aHJzMEozM1V4REtsLzBFNW5TU0o3SWJHbHhIL2R1aUhoV1pUcmFtQWZJNHlq?= =?utf-8?B?VDBJNEdFaFFmbmhJaVA3N3QvaFNmZFVGVzE2WWNFMUxWdWNCSTVsU3FMSjVu?= =?utf-8?B?a1NndW4xM0tqaU9TRkwzWW5oMnovMkZZK29LRXZKOVBiaXQ2d0NiMlVORUoy?= =?utf-8?B?WGVmUEtBVmh6YlJVNlM1Q1VsUS9naHRxRS94WUM4YnVZcE5UaytKQmRxT0Iz?= =?utf-8?B?Z3VXM05pa1A1QzVzWUIxVXpxZGZoUFc3dngydktRbUVGVC9MYkE1RVlrb2NG?= =?utf-8?B?bCttSG1Sd2w1aUxXOFpCTk5Nbm1NZWgxYnJCajloTXR4VmdFRVI3Rlh6MmtJ?= =?utf-8?B?T0I5Z1A3ZU1lOVZtVWttQWhnSHcrT3J0MkpYZVRSUUFWeDdnZDRlcDltT1Z3?= =?utf-8?B?emhoaFRYR01qbFB1dit5Yjk2QWhqa0V4SE5mMGRXYnMyM1NEMlVzU0VnZllX?= =?utf-8?B?U1liQlZhUXZwWksrNEtUU3g1UlZZaEh1bStidVhqL2I1TWxHV3YrTUF6azFn?= =?utf-8?B?SHBoV2J6ZHF0c1ZoS0ZxQkl4ZWU5ZWRsTWZKOHhEdXBUaUY1Vll4czQ2VHRN?= =?utf-8?B?QUg4dlNQYWhqbG52enhUYzdGNTY2dXdxZHVvV2NVOEZRejBFb3V2OUQvUUl5?= =?utf-8?B?MWswa3IxVHJLN2Y1T1Jra1lzUEltRng1RTBReWc3MGxpUFJoekxmV1NqVllJ?= =?utf-8?B?U2VkVUU1bzFqN3FVcklvcmRGY0d1RURvV0xkK3hPaFBSd2I1M3pWQzhuanFQ?= =?utf-8?B?MG51RGZLbVdMekY1V0Q5NCs4aFdDbzh2MEt0RDBvb05yVVV5RTljZXBjQjBO?= =?utf-8?B?TjY2QVFoU3h3ekVyYTlGL0ZlaElJc0NoNUVZa3hNaWVIZWJwWTQrbFRSb1M2?= =?utf-8?B?LzEvM0lHNUUzSVFHeHZlanIxVEp4d01IRWZMRXZiNXV5MWJnbkg3VUdsYVR4?= =?utf-8?B?MEo1UUdWSTI4MDFwd0hFVWQ3MStnWjVUckx1QTBEMitUMksvTnZ0TzR5M1U1?= =?utf-8?B?WEdKVTl0RHZVSldBREJTdjAzd3RWOFdXcU1kRE1VdXFlaWdxVHBLcld4aXN1?= =?utf-8?B?S3FXajdqMEZFZFM0QkFoeGtFNDVkZWJSSUl4SCtsc3FyTlVWL3dZeW9vTG9j?= =?utf-8?B?UVd6ZmVmNVBSNlRaeEt4alhQeFQwY1kvVTNQMUlQcFFSUUdjKytHRXRBTDEv?= =?utf-8?B?MFY3dXVwSXp0YmVOYWJKb0dxSlVwRHZaNzU4S0N2UnhsNGUrSjRVYlFoYklk?= =?utf-8?B?RnM0cWZCc0dUdWdTRkRMZXJCWUI2eGpsSkZ1WnZod25LUUZuQW5pT0o3aUtt?= =?utf-8?B?a0dsUkpwNkIyTVZ4VDk0YlBZREcwQzJVZW9PS1JiM1dQQktQaENXVHE0Zkx3?= =?utf-8?B?Zm03ay8rUmlmaDk2cHZUL1NEeUJ0bGpxc2toUmpSTm0rMzdhWCtLaVBzd2hK?= =?utf-8?B?dTNzT1JNbnpFV0E4ZmNhUWR4S2ZNMFdaT2djY0I0MWZDQkwxdyswdjVuZkU4?= =?utf-8?B?NEVHYUUrVmdDQXFuVC9SS1Q3L0N0NmNEVWM0RjNkR0IvU2U5eDlQTTA4eEFh?= =?utf-8?B?OEd0b3RpNktBQmRRdnI0WEdxcVl4Qm05N0JnTnZXaXIwRkQyK0hXV0JCRzQy?= =?utf-8?B?RTlPUFJhVVluQkVmbVRqcEltbTdLVUh2SHNhU0RjSk9CVVA5ZWkxSlJpRHVa?= =?utf-8?B?Mlh3UTl1TVB0eC9YZjVJTnNnS0hzWS9QOVNXd3lXQWk1L3VaSzNMdk9LNGdo?= =?utf-8?B?Y0VXSjY1d2hRa2FZQlh1QnY5MFFSNmxvK2x6YkFKdytaWnRjdzVCK2Z3MllV?= =?utf-8?Q?V37vaHR7WhZmXBdcYr57TntonJ9UUNSkj/?= X-Microsoft-Exchange-Diagnostics: 1;BN3PR0801MB2242;6:WWltAxR60WM0CcfOk2VuDLwXhIPb55H9LULRPSdATuszO8Y1XzzR8VjIU2lIkwhwykTajU9TfOO95/tQOh6ujQ4l+IM6SgFlcSopF8jX+MycM4IOvVfHzdtHemcW0ndKRwUGNxPcinpNJGvtY537DAvf+gAeZtIWHp5FwvG0PtX3ISC0ggV5SrGZFwXVBnOxsuMmM2U4B0lfjac+4kD7EuyAntNWrzFlfWixmxpRTF/LOsynt++0/TgUb6RQJbWv10dAvmWm1InvY107pbCu2tFsjlzvVEoOY4ji6Z/XyZo=;5:Hl4D0tC1NrOxBrJr+ZqOJlsG2cSy+8xyXU+v2Ei1OgqTiceQAp/3V8el9SrX3xiV5QJfEub7QLfMgZ/RwUDILW2PsfcCCluL3vZk5kliJR3oShjNZVL3YtVfiwUd5VKaqXwPMwwJsWkX4qIxFQe3RA==;24:x5oHFNCITTeWdylInr4aJVGr/nk9SfD5MSiQ6av6H1tP6lxJTxbLF586P/SYRlB3804sg8W8Dr0Wfhdz5OLe+scKUyS2m9BfSGcu6xExnDk=;7:kWxDbBWpnMZ//IpsuM7Mh4JDBuchuyWQwwJHjHaQWb/uYQgtshBhI5T2+mYkKxtuZdIhA+q30y3BusjSlyAiM245B9SL7uMCCCIQv3Rq7xtHhWelqQagvq3mFEoOjw5YORR53rD4sKaa0Jjd9N/ejV288JS5fVxYZH62QNr0ZBBjKd/UwRH6+S72AX2VDcC5uHoPSxkgVzc5bbISj2/Boi+vBcL/ZTrjocpryTvlOHXz8Ht7u6ybmr+9yrm3Wp6C SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;BN3PR0801MB2242;20:DHWzFLSOM8hxpInMDhDs4W1CncXsoKy/xV6sPPBObwpZpHIsD1CLrKTzyOF+bbYNlCBY5n/pVrd8AA6AOBlMlFspE3tjgHO1wcw36q/jsiH74A18T2RTZSuWyjPXuzSIQn2oq9AJLDTT+yEi76671vxww8cVFAP44jIZqM8eCfs= X-OriginatorOrg: stratus.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2016 17:36:10.0285 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0801MB2242 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/20/2016 12:06 PM, Joe Lawrence wrote: > Hello Alessandro and Alexandre, > > I noticed an interesting cmos_rtc.rtc.aie_timer on a Stratus machine > running the 4.6 kernel, with an expiration time that puts the alarm way > out into next year. This is easily reproducible on this machine by > setting a wakealarm sometime in the near future, then rebooting. > > From a fresh boot: > > % cat /proc/driver/rtc > rtc_time : 17:55:10 > rtc_date : 2016-06-09 > alrm_time : 14:04:37 > alrm_date : 2017-06-09 << 2017 ? > alarm_IRQ : no > alrm_pending : no > update IRQ enabled : no > periodic IRQ enabled : no > periodic IRQ frequency : 1024 > max user IRQ frequency : 64 > 24hr : yes > periodic_IRQ : no > update_IRQ : no > HPET_emulated : yes > BCD : yes > DST_enable : no > periodic_freq : 1024 > batt_status : okay > > > I added some debugging code to the kernel, saw this on the next boot: > > __rtc_read_alarm: A - alarm->time.tm_year = -1, missing = 0 > __rtc_read_alarm: B - alarm->time.tm_year = 116, missing = 3 > __rtc_read_alarm: C - alarm->time.tm_year = 117 > > > Corresponding to these parts of __rtc_read_alarm: > > int __rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm) > ... > enum { none, day, month, year } missing = none; > ... > err = rtc_read_alarm_internal(rtc, alarm); > ... > /* Fill in the missing alarm fields using the timestamp; we > * know there's at least one since alarm->time is invalid. > */ > ... > [A] > if (alarm->time.tm_year == -1) { > alarm->time.tm_year = now.tm_year; > if (missing == none) > missing = year; > } > [B] > ... > switch (missing) { > ... > /* Year rollover ... easy except for leap years! */ > case year: > dev_dbg(&rtc->dev, "alarm rollover: %s\n", "year"); > do { > alarm->time.tm_year++; > } while (!is_leap_year(alarm->time.tm_year + 1900) > && rtc_valid_tm(&alarm->time) != 0); > [C] break; > > > I noticed that the missing year and month cases increment their > respective time units inside a do ... while (condition) loop, pushing > the default 'filled-in' values to now + 1. > > Should this 'roll-over' code check for a valid date before incrementing > the alarm time? (See attached patch.) I think this might also apply to > a missing month field as well. > > (After the patch + reboot): > > % cat /proc/driver/rtc > rtc_time : 18:24:02 > rtc_date : 2016-06-09 > alrm_time : 14:04:37 > alrm_date : 2016-06-09 > alarm_IRQ : no > alrm_pending : no > update IRQ enabled : no > periodic IRQ enabled : no > periodic IRQ frequency : 1024 > max user IRQ frequency : 64 > 24hr : yes > periodic_IRQ : no > update_IRQ : no > HPET_emulated : yes > BCD : yes > DST_enable : no > periodic_freq : 1024 > batt_status : okay > > -- >8 -- > > From d6feacf20b312c8ebfee902b8b84f68c1a82f035 Mon Sep 17 00:00:00 2001 > From: Joe Lawrence > Date: Thu, 9 Jun 2016 14:52:28 -0400 > Subject: [PATCH] rtc: check filled-in alarm values before incrementing > > In __rtc_read_alarm, check filled-in alarm->time.tm_year values (those > not returned by the RTC and defaulted to now.tm_year) before > incrementing them in the rollover handling case. > > Signed-off-by: Joe Lawrence > --- > drivers/rtc/interface.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c > index 9ef5f6f89f98..3098ce4167ef 100644 > --- a/drivers/rtc/interface.c > +++ b/drivers/rtc/interface.c > @@ -258,10 +258,10 @@ int __rtc_read_alarm(struct rtc_device *rtc, > struct rtc_wkalrm *alarm) > /* Year rollover ... easy except for leap years! */ > case year: > dev_dbg(&rtc->dev, "alarm rollover: %s\n", "year"); > - do { > + while (!is_leap_year(alarm->time.tm_year + 1900) > + && rtc_valid_tm(&alarm->time) != 0) { > alarm->time.tm_year++; > - } while (!is_leap_year(alarm->time.tm_year + 1900) > - && rtc_valid_tm(&alarm->time) != 0); > + } > break; > > default: > Ping? This isn't a major problem, but can setup endless RTC interrupts under certain conditions on said hardware. -- Joe