From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout01.posteo.de (mout01.posteo.de. [185.67.36.65]) by gmr-mx.google.com with ESMTPS id w128si91764wmd.0.2016.02.18.01.03.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Feb 2016 01:03:25 -0800 (PST) Received: from dovecot03.posteo.de (dovecot03.posteo.de [172.16.0.13]) by mout01.posteo.de (Postfix) with ESMTPS id 8AE2820AE1 for ; Thu, 18 Feb 2016 10:03:25 +0100 (CET) Subject: [rtc-linux] Re: [PATCH] rtc: max77686: fix irqf_oneshot.cocci warnings To: Krzysztof Kozlowski , ldewangan@nvidia.com References: <1455782816-5814-1-git-send-email-valentin.rothberg@posteo.net> <56C57D1E.805@samsung.com> <56C584CC.2000104@posteo.net> <56C585EF.6030509@samsung.com> Cc: kbuild-all@01.org, alexandre.belloni@free-electrons.com, javier@osg.samsung.com, cw00.choi@samsung.com, a.zummo@towertech.it, linux-kernel@vger.kernel.org, rtc-linux@googlegroups.com, kbuild test robot From: Valentin Rothberg Message-ID: <56C588DC.1040909@posteo.net> Date: Thu, 18 Feb 2016 10:03:24 +0100 MIME-Version: 1.0 In-Reply-To: <56C585EF.6030509@samsung.com> Content-Type: text/plain; charset=UTF-8 Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Hi Krzysztof, On 2/18/16 9:50 AM, Krzysztof Kozlowski wrote: > On 18.02.2016 17:46, Valentin Rothberg wrote: >> >> >> Hi Krzysztof, >> >> On 2/18/16 9:13 AM, Krzysztof Kozlowski wrote: >>> On 18.02.2016 17:06, Valentin Rothberg wrote: >>>> From: kbuild test robot >>>> >>>> Since commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests") >>>> threaded IRQs without a primary handler need to be requested with >>>> IRQF_ONESHOT, otherwise the request will fail. >>>> >>>> So pass the IRQF_ONESHOT flag in this case. >>>> >>>> Generated by: scripts/coccinelle/misc/irqf_oneshot.cocci >>>> >>>> CC: Laxman Dewangan >>>> Signed-off-by: Fengguang Wu >>>> Signed-off-by: Valentin Rothberg >>>> --- >>>> drivers/rtc/rtc-max77686.c | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>> >>> Nack, because: >>> 1. AFAIR this is a false positive. >> >> Looking at kernel/irq/manage.c +1250 such requests will be rejected >> unconditionally when the primary handler is NULL, except when the chip >> is marked to be oneshot safe. >> >> Is there another semantic that I am not aware of? In case the script >> produces false positives, I will change it immediately. > > The handler is "irq_nested_primary_handler". > >>> 2. Was it tested? Was it reproduced? Was the bug actually spotted or >>> just coccicheck pointed this and you assumed that "request will fail"? >>> >>> Coccicheck is a great tool... but not necessarily for pointing run-time >>> bugs. >> >> I did not test it. To me the issue rather seems seems like something >> where Coccinelle is really good at, static analysis. > > Yet, this is somehow subtle (device inter-dependencies) so it falls out > of static into runtime (I mean runtime analysis is needed). Thanks for your answer. I wasn't aware of this at all. Best regards, Valentin -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1425708AbcBRJDj (ORCPT ); Thu, 18 Feb 2016 04:03:39 -0500 Received: from mout01.posteo.de ([185.67.36.65]:39317 "EHLO mout01.posteo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1425570AbcBRJD2 (ORCPT ); Thu, 18 Feb 2016 04:03:28 -0500 Subject: Re: [PATCH] rtc: max77686: fix irqf_oneshot.cocci warnings To: Krzysztof Kozlowski , ldewangan@nvidia.com References: <1455782816-5814-1-git-send-email-valentin.rothberg@posteo.net> <56C57D1E.805@samsung.com> <56C584CC.2000104@posteo.net> <56C585EF.6030509@samsung.com> Cc: kbuild-all@01.org, alexandre.belloni@free-electrons.com, javier@osg.samsung.com, cw00.choi@samsung.com, a.zummo@towertech.it, linux-kernel@vger.kernel.org, rtc-linux@googlegroups.com, kbuild test robot From: Valentin Rothberg Message-ID: <56C588DC.1040909@posteo.net> Date: Thu, 18 Feb 2016 10:03:24 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C585EF.6030509@samsung.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Krzysztof, On 2/18/16 9:50 AM, Krzysztof Kozlowski wrote: > On 18.02.2016 17:46, Valentin Rothberg wrote: >> >> >> Hi Krzysztof, >> >> On 2/18/16 9:13 AM, Krzysztof Kozlowski wrote: >>> On 18.02.2016 17:06, Valentin Rothberg wrote: >>>> From: kbuild test robot >>>> >>>> Since commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests") >>>> threaded IRQs without a primary handler need to be requested with >>>> IRQF_ONESHOT, otherwise the request will fail. >>>> >>>> So pass the IRQF_ONESHOT flag in this case. >>>> >>>> Generated by: scripts/coccinelle/misc/irqf_oneshot.cocci >>>> >>>> CC: Laxman Dewangan >>>> Signed-off-by: Fengguang Wu >>>> Signed-off-by: Valentin Rothberg >>>> --- >>>> drivers/rtc/rtc-max77686.c | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>> >>> Nack, because: >>> 1. AFAIR this is a false positive. >> >> Looking at kernel/irq/manage.c +1250 such requests will be rejected >> unconditionally when the primary handler is NULL, except when the chip >> is marked to be oneshot safe. >> >> Is there another semantic that I am not aware of? In case the script >> produces false positives, I will change it immediately. > > The handler is "irq_nested_primary_handler". > >>> 2. Was it tested? Was it reproduced? Was the bug actually spotted or >>> just coccicheck pointed this and you assumed that "request will fail"? >>> >>> Coccicheck is a great tool... but not necessarily for pointing run-time >>> bugs. >> >> I did not test it. To me the issue rather seems seems like something >> where Coccinelle is really good at, static analysis. > > Yet, this is somehow subtle (device inter-dependencies) so it falls out > of static into runtime (I mean runtime analysis is needed). Thanks for your answer. I wasn't aware of this at all. Best regards, Valentin