From patchwork Thu Nov 16 11:51:39 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Will Deacon X-Patchwork-Id: 10060981 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 8B16760230 for ; Thu, 16 Nov 2017 11:51:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7DC662A9A0 for ; Thu, 16 Nov 2017 11:51:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 726C72A9A3; Thu, 16 Nov 2017 11:51:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id E5B2B2A9A0 for ; Thu, 16 Nov 2017 11:51:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=TOEgp3OJWMjAg1gZKJKCZGoxuy0d8mlls+D4TgP8TAU=; b=aaICK15nWM3wdQ cpyCbJJ+KDMJKBSOGJ40TfkhVr+JCRUNoTVOYsXtHU+6tn4Ct8W4m8DJ3z/M9c2XconvezpFKG8Q/ OJZmsYoddH3yCTZTOFloArSzCSx41roBEfD0Ew7evMKk2wy7h7X9woE8HAQHYkOe5YrvBIfzr0POq sqJAxCJi+cUS+k1l7Rhxgqwn1Jtk7qGFLYV/0u1MROaDmnZVx3e24H2JKVd3FdX2Npmsy/n2zl7vk YqY705Nypc1phEQE86o3fW3191AsUS/X49zwy1qmPvNEKB3KeoKSs17+5uUhw8BcI9q6sRkM2b1r3 XCF13fUP/0oaNqWxkuhA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1eFIi2-0002oQ-Dr; Thu, 16 Nov 2017 11:51:54 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1eFIhy-0002mU-US for linux-arm-kernel@lists.infradead.org; Thu, 16 Nov 2017 11:51:52 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C50A01435; Thu, 16 Nov 2017 03:51:30 -0800 (PST) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 968BB3F246; Thu, 16 Nov 2017 03:51:30 -0800 (PST) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 3FBC61AE0BE3; Thu, 16 Nov 2017 11:51:39 +0000 (GMT) Date: Thu, 16 Nov 2017 11:51:39 +0000 From: Will Deacon To: Linus Torvalds Subject: Re: [GIT PULL] arm64: updates for 4.15 Message-ID: <20171116115138.GF9361@arm.com> References: <20171114201132.GB18699@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20171116_035151_015236_EE856100 X-CRM114-Status: GOOD ( 26.10 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Lorenzo Pieralisi , Julien Thierry , Marc Zyngier , Catalin Marinas , Linux Kernel Mailing List , Thomas Gleixner , "linux-arm-kernel@lists.infradead.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Linus, On Wed, Nov 15, 2017 at 11:13:51AM -0800, Linus Torvalds wrote: > On Tue, Nov 14, 2017 at 12:11 PM, Will Deacon wrote: > > > > Please pull the following arm64 updates > > Pulled. However, looking at the non-arm changes, I noticed this: > > static inline int irq_is_percpu_devid(unsigned int irq) > ... > return desc->status_use_accessors & IRQ_PER_CPU_DEVID; > > and it matches the existing pattern in that file, so it is fine and > I'm not complaining about this pull. Thanks. > But that existing pattern happens to be very dangerous and bad. > > In particular, what can (and _has_ happened) is that people end up > using these functions that return true or false, and they assign the > result to something like a bitfield (or a char) or whatever. > > And the code looks *obviously* correct, when you have things like > > dev->percpu = irq_is_percpu_devid(dev->irq); > > and that "percpu" thing is just one status bit among many. It may even > *work*, because maybe that "percpu" flag ends up not being all that > important, or it just happens to never be set on the particular > hardware that people end up testing. > > But while it looks obviously correct, and might even work, it's really > fundamentally broken. Because that "true or false" function didn't > actually return 0/1, it returned 0 or 0x20000. > > And 0x20000 may not fit in a bitmask or a "char" or whatever. > > So I'm not a huge fan of "bool" in structures etc (a "unsigned int > percpu:1" really is fundamentally much better), but when it comes to > inline helper functions like this, "bool" really is the right return > type, because it avoids these issues, and turns the return value to > 0/1 if you actually use it in an integer context. Yes, that makes sense and just returning bool matches the code in kernel/irq/settings.h which is the other direct user of status_use_accessors. The small handful of callers also treat the returned value as a bool (as you'd expect), so we're good. Patch below. Will --->8 From a13a3e00d86d9f8d2af330d7a5165197166c37ce Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Thu, 16 Nov 2017 10:49:34 +0000 Subject: [PATCH] irqdesc: Use bool return type instead of int The irq_balancing_disabled and irq_is_percpu{,_devid} functions are clearly intended to return bool like the functions in kernel/irq/settings.h, but actually return an int containing a masked value of desc->status_use_accessors. This can lead to subtle breakage if, for example, the return value is subsequently truncated when assigned to a narrower type. As Linus points out: | In particular, what can (and _has_ happened) is that people end up | using these functions that return true or false, and they assign the | result to something like a bitfield (or a char) or whatever. | | And the code looks *obviously* correct, when you have things like | | dev->percpu = irq_is_percpu_devid(dev->irq); | | and that "percpu" thing is just one status bit among many. It may even | *work*, because maybe that "percpu" flag ends up not being all that | important, or it just happens to never be set on the particular | hardware that people end up testing. | | But while it looks obviously correct, and might even work, it's really | fundamentally broken. Because that "true or false" function didn't | actually return 0/1, it returned 0 or 0x20000. | | And 0x20000 may not fit in a bitmask or a "char" or whatever. Fix the problem by consistently using bool as the return type for these functions. Reported-by: Linus Torvalds Signed-off-by: Will Deacon --- include/linux/irqdesc.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h index dd418955962b..39fb3700f7a9 100644 --- a/include/linux/irqdesc.h +++ b/include/linux/irqdesc.h @@ -230,7 +230,7 @@ irq_set_chip_handler_name_locked(struct irq_data *data, struct irq_chip *chip, data->chip = chip; } -static inline int irq_balancing_disabled(unsigned int irq) +static inline bool irq_balancing_disabled(unsigned int irq) { struct irq_desc *desc; @@ -238,7 +238,7 @@ static inline int irq_balancing_disabled(unsigned int irq) return desc->status_use_accessors & IRQ_NO_BALANCING_MASK; } -static inline int irq_is_percpu(unsigned int irq) +static inline bool irq_is_percpu(unsigned int irq) { struct irq_desc *desc; @@ -246,7 +246,7 @@ static inline int irq_is_percpu(unsigned int irq) return desc->status_use_accessors & IRQ_PER_CPU; } -static inline int irq_is_percpu_devid(unsigned int irq) +static inline bool irq_is_percpu_devid(unsigned int irq) { struct irq_desc *desc;