Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67637C43217 for ; Mon, 8 Nov 2021 14:21:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 51629610A8 for ; Mon, 8 Nov 2021 14:21:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239177AbhKHOYM (ORCPT ); Mon, 8 Nov 2021 09:24:12 -0500 Received: from mail.skyhub.de ([5.9.137.197]:49490 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240432AbhKHOX6 (ORCPT ); Mon, 8 Nov 2021 09:23:58 -0500 Received: from zn.tnic (p200300ec2f33110093973d8dfcf40fd9.dip0.t-ipconnect.de [IPv6:2003:ec:2f33:1100:9397:3d8d:fcf4:fd9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id D08561EC04E4; Mon, 8 Nov 2021 15:21:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1636381269; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=oWsCJGhsvF17zUFafKKKz1XGvPrCUoTgLb0x72qzY0w=; b=DvalVyPWlBMIVGIell7SDhnTX9Q86iHxoTdmXzPxorrW7sqlHpzQzwtFgZEI1KmHXq30Gs yOE/y0FWs3djKZaj7cQDtIyWYYD5AKtdhjFE5l3EWLo8DNcP+YE1HL9C5d3kHwZrzRPHP8 xiS/nYCk2AFbtbv/wLq5RqiIdGlMN38= Date: Mon, 8 Nov 2021 15:21:04 +0100 From: Borislav Petkov To: Geert Uytterhoeven Cc: LKML , Thomas Gleixner , Arnd Bergmann , Ayush Sawal , Greg Kroah-Hartman , Rohit Maheshwari , Steven Rostedt , Vinay Kumar Yadav , ALSA Development Mailing List , bcm-kernel-feedback-list , Intel Graphics Development , intel-gvt-dev@lists.freedesktop.org, alpha , Linux ARM , linux-clk , Linux Crypto Mailing List , linux-edac@vger.kernel.org, Linux Fbdev development list , linux-hyperv@vger.kernel.org, linux-iio@vger.kernel.org, linux-leds , "open list:BROADCOM NVRAM DRIVER" , Parisc List , Linux PM list , linuxppc-dev , "open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM" , Linux-Renesas , linux-s390 , scsi , Linux-sh list , linux-staging@lists.linux.dev, linux-tegra , linux-um , USB list , "open list:TENSILICA XTENSA PORT (xtensa)" , netdev , openipmi-developer@lists.sourceforge.net, rcu@vger.kernel.org, sparclinux , the arch/x86 maintainers , xen-devel@lists.xenproject.org Subject: Re: [PATCH v0 42/42] notifier: Return an error when callback is already registered Message-ID: References: <20211108101157.15189-1-bp@alien8.de> <20211108101157.15189-43-bp@alien8.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 08, 2021 at 03:07:03PM +0100, Geert Uytterhoeven wrote: > I think the addition of __must_check is overkill, leading to the > addition of useless error checks and message printing. See the WARN in notifier_chain_register() - it will already do "message printing". > Many callers call this where it cannot fail, and where nothing can > be done in the very unlikely event that the call would ever start to > fail. This is an attempt to remove this WARN() hack in notifier_chain_register() and have the function return a proper error value instead of this "Currently always returns zero." which is bad design. Some of the registration functions around the tree check that retval and some don't. So if "it cannot fail" those registration either should not return a value or callers should check that return value - what we have now doesn't make a whole lot of sense. Oh, and then fixing this should avoid stuff like: + if (notifier_registered == false) { + mce_register_decode_chain(&amdgpu_bad_page_nb); + notifier_registered = true; + } from propagating in the code. The other idea I have is to add another indirection in notifier_chain_register() which will check the *proper* return value of a lower level __notifier_chain_register() and then issue that warning. That would definitely avoid touch so many call sites. Bottom line is: what we have now needs cleaning up. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette