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 95451C433F5 for ; Mon, 8 Nov 2021 16:23:52 +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 8D30661350 for ; Mon, 8 Nov 2021 16:23:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8D30661350 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org 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 4HnxJ60vN0z2yph for ; Tue, 9 Nov 2021 03:23:50 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=srs0=mnkb=p3=goodmis.org=rostedt@kernel.org; receiver=) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4HnxHY10V7z2yQH for ; Tue, 9 Nov 2021 03:23:21 +1100 (AEDT) Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E868D61284; Mon, 8 Nov 2021 16:23:14 +0000 (UTC) Date: Mon, 8 Nov 2021 11:23:13 -0500 From: Steven Rostedt To: Borislav Petkov Subject: Re: [PATCH v0 00/42] notifiers: Return an error when callback is already registered Message-ID: <20211108112313.73d0727e@gandalf.local.home> In-Reply-To: References: <20211108101157.15189-1-bp@alien8.de> <20211108101924.15759-1-bp@alien8.de> <20211108141703.GB1666297@rowland.harvard.edu> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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-devel@alsa-project.org, x86@kernel.org, linux-sh@vger.kernel.org, linux-iio@vger.kernel.org, linux-remoteproc@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-mips@vger.kernel.org, netdev@vger.kernel.org, Ayush Sawal , sparclinux@vger.kernel.org, linux-clk@vger.kernel.org, linux-leds@vger.kernel.org, linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org, Rohit Maheshwari , linux-staging@lists.linux.dev, bcm-kernel-feedback-list@broadcom.com, Geert Uytterhoeven , linux-xtensa@linux-xtensa.org, Arnd Bergmann , linux-pm@vger.kernel.org, intel-gfx@lists.freedesktop.org, Vinay Kumar Yadav , linux-um@lists.infradead.org, rcu@vger.kernel.org, linux-fbdev@vger.kernel.org, xen-devel@lists.xenproject.org, linux-tegra@vger.kernel.org, openipmi-developer@lists.sourceforge.net, intel-gvt-dev@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-edac@vger.kernel.org, linux-parisc@vger.kernel.org, Greg Kroah-Hartman , linux-usb@vger.kernel.org, LKML , Alan Stern , linux-renesas-soc@vger.kernel.org, linux-crypto@vger.kernel.org, linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, 8 Nov 2021 15:35:50 +0100 Borislav Petkov wrote: > On Mon, Nov 08, 2021 at 03:24:39PM +0100, Borislav Petkov wrote: > > I guess I can add another indirection to notifier_chain_register() and > > avoid touching all the call sites. > > IOW, something like this below. > > This way I won't have to touch all the callsites and the registration > routines would still return a proper value instead of returning 0 > unconditionally. I prefer this method. Question, how often does this warning trigger? Is it common to see in development? -- Steve