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: <20200227120618.GA6312@afzalpc>
Date:   Thu, 27 Feb 2020 17:36:18 +0530
From:   afzal mohammed <afzal.mohd.ma@...il.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Greg Ungerer <gerg@...ux-m68k.org>,
        Finn Thain <fthain@...egraphics.com.au>,
        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()

Hi Geert,

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] ?).

Also as most are tick timers, if request_irq() fails, system would die
in that case. But i have seen (iirc in MIPS), in the same execution
sequence multiple setup_irq() invocations, so every instance might not
be unavoidable for system boot.

For tick timer cases, a BUG() might be suitable, but i didn't even
think of that option as that is a recipe for getting trashed from head
penguin (though he would not care trivial patches like this), same
scenario w/ adding warnings.

> Just my 2 €c.

That is my 2 paise, but per exchange rate it will be far less ;)

Regards
afzal