linux-kernel - Re: [PATCH v2 06/18] m68k: Replace setup_irq() by request

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: <alpine.LNX.2.22.394.2002280927130.8@nippy.intranet>
Date:   Fri, 28 Feb 2020 09:38:20 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     afzal mohammed <afzal.mohd.ma@...il.com>
cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Greg Ungerer <gerg@...ux-m68k.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 06/18] m68k: Replace setup_irq() by request_irq()

On Thu, 27 Feb 2020, afzal mohammed wrote:

> On Thu, Feb 27, 2020 at 09:32:46AM +0100, Geert Uytterhoeven wrote:
> > On Thu, Feb 27, 2020 at 9:18 AM afzal mohammed <afzal.mohd.ma@...il.com> wrote:

> > > Since most of the existing setup_irq() didn't even check & handle 
> > > error return, my first thought was just s/setup_irq/request_irq, it 
> > > was easier from scripting pointing of view. i felt uncomfortable 
> > > doing nothing in case of error. Also noted that request_irq() 
> > > definition has a "__much_check", so decided to add it.
> > 
> > Most (all?) of the code calling setup_irq() is very old, and most of 
> > the calls happen very early, so any such failures are hard failures 
> > that prevent the system from booting at all.  Hence printing a message 
> > may be futile, as it may happen before the console has been 
> > initialized (modulo early-printk).
> 
> The main reason to at least acknowledge the return value was due to 
> __much_check in request_irq() definition, though w/ the compiler that i 
> used, there were no warnings, i feared that it might warn w/ some other 
> compilers & in some cases (may be W=[1-3] ?).
> 

This isn't new code, so I'd assume it's been "checked" in the sense of 
"reviewed and tested".

So the lack of an error message could be taken to mean that there's no 
need for an error message.

If you want to stop the compiler complaining about an unchecked return 
value, assuming that it does so, please consider using

	if (request_irq(...))
		pr_debug(...);

That way there is no penalty paid for adding error messages that the 
original author apparently did not want.