Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Guenter Roeck <groeck7@gmail.com>
Date:   Tue, 9 May 2023 14:18:35 -0700
From:   Guenter Roeck <linux@roeck-us.net>
To:     Conor Dooley <conor@kernel.org>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        stable@vger.kernel.org, patches@lists.linux.dev,
        linux-kernel@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,
        srw@sladewatkins.net, rwarsow@gmx.de
Subject: Re: [PATCH 6.1 000/610] 6.1.28-rc2 review
Message-ID: <ce667220-5803-4b6a-a2d2-f538289af584@roeck-us.net>
References: <20230509030653.039732630@linuxfoundation.org>
 <0837e157-8615-418a-a3d3-1c14af11aba5@roeck-us.net>
 <20230509-robust-crate-5fe128d00e6d@spud>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230509-robust-crate-5fe128d00e6d@spud>
Precedence: bulk

On Tue, May 09, 2023 at 09:41:42PM +0100, Conor Dooley wrote:
> On Tue, May 09, 2023 at 12:57:58PM -0700, Guenter Roeck wrote:
> > On Tue, May 09, 2023 at 05:26:31AM +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 6.1.28 release.
> > > There are 610 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, 11 May 2023 03:05:05 +0000.
> > > Anything received after that time might be too late.
> > > 
> > 
> > Build results:
> > 	total: 155 pass: 155 fail: 0
> > Qemu test results:
> > 	total: 519 pass: 519 fail: 0
> > 
> > New persistent runtime warning when booting riscv32/64 images:
> 
> You sure this is new? I seem to be able to reproduce for QEMU (which I

New for my tests, yes.

> don't usually test) in several versions of 6.1. Don't see it in (my)
> hardware though, as the particular platform doesn't end up calling the
> offending function. Out of curiosity, what's your QEMU invocation?

Example boot from initrd:

qemu-system-riscv64 -M virt -m 512M \
     -no-reboot -kernel arch/riscv/boot/Image \
     -initrd rootfs.cpio \
     -device e1000,netdev=net0 \
     -netdev user,id=net0 -bios default \
     -append "panic=-1 rdinit=/sbin/init console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \
     -nographic -monitor none

qemu version is 8.0, but I don't think that makes a difference.
What does your command line look like ?

> 
> Anyways, looks like a partial backport is the cause. How's it look with:
> 
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index 694267d1fe81..fd1238df6149 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -9,6 +9,7 @@
>  #include <linux/bitmap.h>
>  #include <linux/ctype.h>
>  #include <linux/libfdt.h>
> +#include <linux/memory.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
>  #include <asm/alternative.h>
> @@ -316,8 +317,11 @@ void __init_or_module riscv_cpufeature_patch_func(struct alt_entry *begin,
>  		}
>  
>  		tmp = (1U << alt->errata_id);
> -		if (cpu_req_feature & tmp)
> +		if (cpu_req_feature & tmp) {
> +			mutex_lock(&text_mutex);
>  			patch_text_nosync(alt->old_ptr, alt->alt_ptr, alt->alt_len);
> +			mutex_unlock(&text_mutex);
> +		}
>  	}
>  }
>  #endif
> 

This fixes the problem for me.

Thanks,
Guenter