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  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]
Date:   Sun, 13 Dec 2020 04:55:39 -0800
From:   Guenter Roeck <>
To:     Miguel Ojeda <>
Cc:     Masahiro Yamada <>,
        "Jason A . Donenfeld" <>,
        Nathan Chancellor <>,
        Nick Desaulniers <>,
        Shuah Khan <>,
        clang-built-linux <>,
        linux-kernel <>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        Network Development <>,
Subject: Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK

On 12/12/20 9:04 PM, Miguel Ojeda wrote:
> On Sat, Dec 12, 2020 at 5:18 PM Guenter Roeck <> wrote:
>> This patch results in:
>> arch/sh/kernel/cpu/sh4a/smp-shx3.c: In function 'shx3_prepare_cpus':
>> arch/sh/kernel/cpu/sh4a/smp-shx3.c:76:3: error: ignoring return value of 'request_irq' declared with attribute 'warn_unused_result'
>> when building sh:defconfig. Checking for calls to request_irq()
>> suggests that there will be other similar errors in various builds.
>> Reverting the patch fixes the problem.
> Which ones? From a quick grep and some filtering I could only find one
> file with wrong usage apart from this one:
>     drivers/net/ethernet/lantiq_etop.c:
> request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", priv);
>     drivers/net/ethernet/lantiq_etop.c:
> request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx", priv);
> Of course, this does not cover other functions, but it means there
> aren't many issues and/or people building the code if nobody complains
> within a few weeks. So I think we can fix them as they come.

Witz komm raus, Du bist umzingelt.

The key here is "if nobody complains". I would argue that it is _your_
responsibility to do those builds, and not the reponsibility of others
to do it for you.

But, sure, your call. Please feel free to ignore my report.


Powered by blists - more mailing lists