Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Wed, 6 Apr 2022 10:26:15 +0200
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     Guenter Roeck <linux@roeck-us.net>, linux-kernel@vger.kernel.org,
        stable@vger.kernel.org, torvalds@linux-foundation.org,
        akpm@linux-foundation.org, shuah@kernel.org, patches@kernelci.org,
        lkft-triage@lists.linaro.org, pavel@denx.de, jonathanh@nvidia.com,
        f.fainelli@gmail.com, sudipm.mukherjee@gmail.com,
        slade@sladewatkins.com, Sasha Levin <sashal@kernel.org>
Subject: Re: [PATCH 5.10 000/599] 5.10.110-rc1 review
Message-ID: <Yk1Op5c0mbtR0VLw@kroah.com>
References: <20220405070258.802373272@linuxfoundation.org>
 <20220406010749.GA1133386@roeck-us.net>
 <20220406023025.GA1926389@roeck-us.net>
 <20220405225212.061852f9@gandalf.local.home>
 <20220405230812.2feca4ed@gandalf.local.home>
 <20220405232413.6b38e966@gandalf.local.home>
 <Yk1LMYzEOv7vmEHR@kroah.com>
 <Yk1N5Vg+YrGxrfVo@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Yk1N5Vg+YrGxrfVo@kroah.com>
Precedence: bulk

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@goodmis.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@vger if/when you want them queued up
there, that would be great.

thanks,

greg k-h