From mboxrd@z Thu Jan 1 00:00:00 1970 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 7CFF6C433EF for ; Mon, 8 Nov 2021 20:59:58 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ED03D61051 for ; Mon, 8 Nov 2021 20:59:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org ED03D61051 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Hp3Qh4Ypwz3cBr for ; Tue, 9 Nov 2021 07:59:56 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=netrider.rowland.org (client-ip=192.131.102.5; helo=netrider.rowland.org; envelope-from=stern+618c59fc@netrider.rowland.org; receiver=) Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lists.ozlabs.org (Postfix) with SMTP id 4Hp3QB1Vpwz2xLJ for ; Tue, 9 Nov 2021 07:59:29 +1100 (AEDT) Received: (qmail 1679175 invoked by uid 1000); 8 Nov 2021 15:59:26 -0500 Date: Mon, 8 Nov 2021 15:59:26 -0500 From: Alan Stern To: Borislav Petkov Subject: Re: [PATCH v0 42/42] notifier: Return an error when callback is already registered Message-ID: <20211108205926.GA1678880@rowland.harvard.edu> References: <20211108101157.15189-1-bp@alien8.de> <20211108101157.15189-43-bp@alien8.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ALSA Development Mailing List , the arch/x86 maintainers , Linux-sh list , linux-iio@vger.kernel.org, "open list:REMOTE PROCESSOR \(REMOTEPROC\) SUBSYSTEM" , linux-hyperv@vger.kernel.org, "open list:BROADCOM NVRAM DRIVER" , netdev , Ayush Sawal , sparclinux , linux-clk , linux-leds , linux-s390 , scsi , Rohit Maheshwari , linux-staging@lists.linux.dev, Geert Uytterhoeven , openipmi-developer@lists.sourceforge.net, bcm-kernel-feedback-list , "open list:TENSILICA XTENSA PORT \(xtensa\)" , Arnd Bergmann , Linux PM list , Intel Graphics Development , Vinay Kumar Yadav , linux-um , Steven Rostedt , rcu@vger.kernel.org, Linux Fbdev development list , xen-devel@lists.xenproject.org, linux-tegra , Thomas Gleixner , intel-gvt-dev@lists.freedesktop.org, Linux ARM , linux-edac@vger.kernel.org, Parisc List , Greg Kroah-Hartman , USB list , LKML , Linux-Renesas , Linux Crypto Mailing List , alpha , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Nov 08, 2021 at 05:21:45PM +0100, Borislav Petkov wrote: > On Mon, Nov 08, 2021 at 05:12:16PM +0100, Geert Uytterhoeven wrote: > > Returning void is the other extreme ;-) > > > > There are 3 levels (ignoring BUG_ON()/panic () inside the callee): > > 1. Return void: no one can check success or failure, > > 2. Return an error code: up to the caller to decide, > > 3. Return a __must_check error code: every caller must check. > > > > I'm in favor of 2, as there are several places where it cannot fail. > > Makes sense to me. I'll do that in the next iteration. Is there really any reason for returning an error code? For example, is it anticipated that at some point in the future these registration calls might fail? Currently, the only reason for failing to register a notifier callback is because the callback is already registered. In a sense this isn't even an actual failure -- after the registration returns the callback _will_ still be registered. So if the call can never really fail, why bother with a return code? Especially since the caller can't do anything with such a code value. Given the current state of affairs, I vote in favor of 1 (plus a WARN or something similar to generate a stack dump in the callee, since double registration really is a bug). Alan Stern