Re: [PATCH 5.15 000/123] 5.15.82-rc2 review

[Greg Kroah-Hartman]

On Tue, Dec 06, 2022 at 07:11:39AM -0800, Guenter Roeck wrote:
> On 12/6/22 04:42, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.15.82 release.
> > There are 123 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu, 08 Dec 2022 12:40:31 +0000.
> > Anything received after that time might be too late.
> > 
> 
> arch/riscv/kernel/smp.c: In function 'handle_IPI':
> arch/riscv/kernel/smp.c:195:44: error: 'cpu' undeclared (first use in this function)
>   195 |                         ipi_cpu_crash_stop(cpu, get_irq_regs());
>       |                                            ^~~
> arch/riscv/kernel/smp.c:195:44: note: each undeclared identifier is reported only once for each function it appears in
> arch/riscv/kernel/smp.c:217:22: error: 'old_regs' undeclared (first use in this function)
>   217 |         set_irq_regs(old_regs);
>       |                      ^~~~~~~~
> 
> This is with v5.15.81-124-g9269e46bc838.
> 
> The backport of commit 9b932aadfc47d seems wrong. The original version introduces
> the cpu variable in handle_IPI(). The backport doesn't, and removes old_regs
> instead.
> 
> Backport:
> 
>  void handle_IPI(struct pt_regs *regs)
>  {
> -       struct pt_regs *old_regs = set_irq_regs(regs);
>         unsigned long *pending_ipis = &ipi_data[smp_processor_id()].bits;
>         unsigned long *stats = ipi_data[smp_processor_id()].stats;
> 
> Original:
> 
> void handle_IPI(struct pt_regs *regs)
>  {
> -       unsigned long *pending_ipis = &ipi_data[smp_processor_id()].bits;
> -       unsigned long *stats = ipi_data[smp_processor_id()].stats;
> +       unsigned int cpu = smp_processor_id();
> +       unsigned long *pending_ipis = &ipi_data[cpu].bits;
> +       unsigned long *stats = ipi_data[cpu].stats;
> 
> Upstream includes commit 7ecbc648102f which removes the old_regs variable.
> That doesn't mean it can be removed in the backport.

Yeah, that looks odd.  I've dropped it from both 5.15 and 6.0 now and
will push out a new -rc with that removed.

thanks for testing!

greg k-h