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 8E721C4167B for ; Mon, 8 Nov 2021 14:17:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7A25E61076 for ; Mon, 8 Nov 2021 14:17:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240330AbhKHOTv (ORCPT ); Mon, 8 Nov 2021 09:19:51 -0500 Received: from netrider.rowland.org ([192.131.102.5]:33279 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S240306AbhKHOTs (ORCPT ); Mon, 8 Nov 2021 09:19:48 -0500 Received: (qmail 1667203 invoked by uid 1000); 8 Nov 2021 09:17:03 -0500 Date: Mon, 8 Nov 2021 09:17:03 -0500 From: Alan Stern To: Borislav Petkov Cc: LKML , Arnd Bergmann , Ayush Sawal , Greg Kroah-Hartman , Rohit Maheshwari , Steven Rostedt , Vinay Kumar Yadav , alsa-devel@alsa-project.org, bcm-kernel-feedback-list@broadcom.com, intel-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, linux-crypto@vger.kernel.org, linux-edac@vger.kernel.org, linux-fbdev@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-iio@vger.kernel.org, linux-leds@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-remoteproc@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org, linux-sh@vger.kernel.org, linux-staging@lists.linux.dev, linux-tegra@vger.kernel.org, linux-um@lists.infradead.org, linux-usb@vger.kernel.org, linux-xtensa@linux-xtensa.org, netdev@vger.kernel.org, openipmi-developer@lists.sourceforge.net, rcu@vger.kernel.org, sparclinux@vger.kernel.org, x86@kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v0 00/42] notifiers: Return an error when callback is already registered Message-ID: <20211108141703.GB1666297@rowland.harvard.edu> References: <20211108101157.15189-1-bp@alien8.de> <20211108101924.15759-1-bp@alien8.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211108101924.15759-1-bp@alien8.de> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 08, 2021 at 11:19:24AM +0100, Borislav Petkov wrote: > From: Borislav Petkov > > Hi all, > > this is a huge patchset for something which is really trivial - it > changes the notifier registration routines to return an error value > if a notifier callback is already present on the respective list of > callbacks. For more details scroll to the last patch. > > Everything before it is converting the callers to check the return value > of the registration routines and issue a warning, instead of the WARN() > notifier_chain_register() does now. What reason is there for moving the check into the callers? It seems like pointless churn. Why not add the error return code, change the WARN to pr_warn, and leave the callers as they are? Wouldn't that end up having exactly the same effect? For that matter, what sort of remedial action can a caller take if the return code is -EEXIST? Is there any point in forcing callers to check the return code if they can't do anything about it? > Before the last patch has been applied, though, that checking is a > NOP which would make the application of those patches trivial - every > maintainer can pick a patch at her/his discretion - only the last one > enables the build warnings and that one will be queued only after the > preceding patches have all been merged so that there are no build > warnings. Why should there be _any_ build warnings? The real problem occurs when a notifier callback is added twice, not when a caller fails to check the return code. Double-registration is not the sort of thing that can be detected at build time. Alan Stern > Due to the sheer volume of the patches, I have addressed the respective > patch and the last one, which enables the warning, with addressees for > each maintained area so as not to spam people unnecessarily. > > If people prefer I carry some through tip, instead, I'll gladly do so - > your call. > > And, if you think the warning messages need to be more precise, feel > free to adjust them before committing. > > Thanks!