linux-kernel - Re: kernel/trace/ftrace.c:7157:20: error: unused function 'ftrace_startup

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] [day] [month] [year] [list]

Date:   Mon, 14 Feb 2022 13:57:39 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Nathan Chancellor <nathan@...nel.org>
Cc:     kernel test robot <lkp@...el.com>,
        chongjiapeng <jiapeng.chong@...ux.alibaba.com>,
        llvm@...ts.linux.dev, kbuild-all@...ts.01.org,
        linux-kernel@...r.kernel.org
Subject: Re: kernel/trace/ftrace.c:7157:20: error: unused function
 'ftrace_startup_enable'

On Mon, 14 Feb 2022 08:53:04 -0700
Nathan Chancellor <nathan@...nel.org> wrote:

> I will be honest, I don't know why the robot flagged 172f7ba9772c as the
> commit that introduced this warning but it seems legitimate if
> CONFIG_DYNAMIC_FTRACE is not enabled, since ftrace_startup_enable() is
> only ever used within an '#ifdef CONFIG_DYNAMIC_FTRACE' block so I guess
> the stub is unnecessary?

I'm all fine for clean up patches, but I don't like "new warning" message
reports for things that use to be OK, but now are a warning.

In other words, if a bot updates its warnings, it should do a full pass of
the kernel before it starts on new commits, to flag all existing warnings
as OK (but possibly work for someone to clean up), but should not ever send
as a new warning message to the authors.

So, I'm going to ignore this. If someone wants to send me a clean up patch,
I'll test it and take it, but I do not have the time to clean up new
warnings that use to be OK unless they uncovered a real bug.

-- Steve