lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211108205926.GA1678880@rowland.harvard.edu>
Date:   Mon, 8 Nov 2021 15:59:26 -0500
From:   Alan Stern <stern@...land.harvard.edu>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Arnd Bergmann <arnd@...db.de>,
        Ayush Sawal <ayush.sawal@...lsio.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rohit Maheshwari <rohitm@...lsio.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Vinay Kumar Yadav <vinay.yadav@...lsio.com>,
        ALSA Development Mailing List <alsa-devel@...a-project.org>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
        Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
        intel-gvt-dev@...ts.freedesktop.org,
        alpha <linux-alpha@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-edac@...r.kernel.org,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        linux-hyperv@...r.kernel.org, linux-iio@...r.kernel.org,
        linux-leds <linux-leds@...r.kernel.org>,
        "open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
        Parisc List <linux-parisc@...r.kernel.org>,
        Linux PM list <linux-pm@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        "open list:REMOTE PROCESSOR \(REMOTEPROC\) SUBSYSTEM" 
        <linux-remoteproc@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        linux-s390 <linux-s390@...r.kernel.org>,
        scsi <linux-scsi@...r.kernel.org>,
        Linux-sh list <linux-sh@...r.kernel.org>,
        linux-staging@...ts.linux.dev,
        linux-tegra <linux-tegra@...r.kernel.org>,
        linux-um <linux-um@...ts.infradead.org>,
        USB list <linux-usb@...r.kernel.org>,
        "open list:TENSILICA XTENSA PORT \(xtensa\)" 
        <linux-xtensa@...ux-xtensa.org>, netdev <netdev@...r.kernel.org>,
        openipmi-developer@...ts.sourceforge.net, rcu@...r.kernel.org,
        sparclinux <sparclinux@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        xen-devel@...ts.xenproject.org
Subject: Re: [PATCH v0 42/42] notifier: Return an error when callback is
 already registered

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ