linux-kernel - Re: [PATCH 5.10 000/599] 5.10.110-rc1 review

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]

Date:   Wed, 6 Apr 2022 10:26:15 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Guenter Roeck <linux@...ck-us.net>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, torvalds@...ux-foundation.org,
        akpm@...ux-foundation.org, shuah@...nel.org, patches@...nelci.org,
        lkft-triage@...ts.linaro.org, pavel@...x.de, jonathanh@...dia.com,
        f.fainelli@...il.com, sudipm.mukherjee@...il.com,
        slade@...dewatkins.com, Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 5.10 000/599] 5.10.110-rc1 review

On Wed, Apr 06, 2022 at 10:23:01AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 06, 2022 at 10:11:29AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Apr 05, 2022 at 11:24:13PM -0400, Steven Rostedt wrote:
> > > On Tue, 5 Apr 2022 23:08:12 -0400
> > > Steven Rostedt <rostedt@...dmis.org> wrote:
> > > 
> > > > Here's a thought, if you decide to backport a patch to stable, and you see
> > > > that there's another commit with a "Fixes" tag to the automatically
> > > > selected commit. DO NOT BACKPORT IF THE FIXES PATCH FAILS TO GO BACK TOO!
> > > 
> > > Seriously. This should be the case for *all* backported patches, not just
> > > the AUTOSEL ones.
> > > 
> > > Otherwise you are backporting a commit to "stable" that is KNOWN TO BE
> > > BROKEN!
> > 
> > My scripts usually do catch this, let me go see what went wrong...
> 
> Ok, my fault, my scripts _did_ catch this, but I ignored it as it was
> filled with other noise.  I've now queued this commit up.
> 
> thanks for catching this and sorry for missing it the first time around.

Wait, no, I did catch this!  And I sent you a "FAILED" email about it, 4
of them:
	https://lore.kernel.org/r/164905985821176@kroah.com
	https://lore.kernel.org/r/16490598521299@kroah.com
	https://lore.kernel.org/r/1649059845215213@kroah.com
	https://lore.kernel.org/r/16490598398133@kroah.com
as the commit applied, but broke the build:

kernel/trace/trace_events.c: In function ‘update_event_fields’:
kernel/trace/trace_events.c:2459:40: error: ‘TRACE_EVENT_FL_DYNAMIC’ undeclared (first use in this function); did you mean ‘FTRACE_OPS_FL_DYNAMIC’?
 2459 |         if (WARN_ON_ONCE(call->flags & TRACE_EVENT_FL_DYNAMIC))
      |                                        ^~~~~~~~~~~~~~~~~~~~~~
./include/asm-generic/bug.h:102:32: note: in definition of macro ‘WARN_ON_ONCE’
  102 |         int __ret_warn_on = !!(condition);                      \
      |                                ^~~~~~~~~
kernel/trace/trace_events.c:2459:40: note: each undeclared identifier is reported only once for each function it appears in
 2459 |         if (WARN_ON_ONCE(call->flags & TRACE_EVENT_FL_DYNAMIC))
      |                                        ^~~~~~~~~~~~~~~~~~~~~~
./include/asm-generic/bug.h:102:32: note: in definition of macro ‘WARN_ON_ONCE’
  102 |         int __ret_warn_on = !!(condition);                      \
      |                                ^~~~~~~~~
kernel/trace/trace_events.c:2491:25: error: ‘struct trace_event_call’ has no member named ‘module’
 2491 |                 if (call->module)
      |                         ^~
kernel/trace/trace_events.c:2492:47: error: ‘struct trace_event_call’ has no member named ‘module’
 2492 |                         add_str_to_module(call->module, str);
      |                                               ^~


But I didn't drop the offending commit, I should have done that.

I'll go and drop the offending commit here, if you could submit both of
them as working backports to stable@...r if/when you want them queued up
there, that would be great.

thanks,

greg k-h