Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + Documentation/admin-guide/hw-vuln/index.rst | 1 + .../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++ Documentation/admin-guide/kernel-parameters.txt | 36 +++ Makefile | 4 +- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/msr-index.h | 25 +++ arch/x86/include/asm/nospec-branch.h | 2 + arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++--- arch/x86/kernel/cpu/common.c | 52 ++++- arch/x86/kvm/vmx/vmx.c | 72 ++++++ arch/x86/kvm/vmx/vmx.h | 2 + arch/x86/kvm/x86.c | 3 + drivers/base/cpu.c | 8 + include/linux/cpu.h | 3 + tools/arch/x86/include/asm/cpufeatures.h | 1 + tools/arch/x86/include/asm/msr-index.h | 25 +++ 17 files changed, 676 insertions(+), 41 deletions(-)
This is the start of the stable review cycle for the 5.10.123 release.
There are 11 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, 16 Jun 2022 18:37:02 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.123-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 5.10.123-rc1
Josh Poimboeuf <jpoimboe@kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx/vmx.c | 72 ++++++
arch/x86/kvm/vmx/vmx.h | 2 +
arch/x86/kvm/x86.c | 3 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 3 +
tools/arch/x86/include/asm/cpufeatures.h | 1 +
tools/arch/x86/include/asm/msr-index.h | 25 +++
17 files changed, 676 insertions(+), 41 deletions(-)
Hi!
> This is the start of the stable review cycle for the 5.10.123 release.
> There are 11 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.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
On 14/06/2022 19:40, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.123 release.
> There are 11 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, 16 Jun 2022 18:37:02 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.123-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
No new regressions for Tegra. I am seeing the following kernel warning
that is causing a boot test to fail, but this has been happening for a
few releases now (I would have reported it earlier but we have been
having some infrastructure issues) ...
WARNING KERN urandom_read_iter: 82 callbacks suppressed
This appears to be introduced by commit "random: convert to using
fops->read_iter()" [0]. Interestingly, I am not seeing this in the
mainline as far as I can tell and so I am not sure if there is something
else that is missing?
Test results for stable-v5.10:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
75 tests: 74 pass, 1 fail
Linux version: 5.10.123-rc1-gf67ea0f67087
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Test failures: tegra194-p2972-0000: boot.py
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
[0]
https://lore.kernel.org/lkml/20220527084907.568432116@linuxfoundation.org/
--
nvpublic
Hi Jon,
On Thu, Jun 16, 2022 at 09:48:37AM +0100, Jon Hunter wrote:
> No new regressions for Tegra. I am seeing the following kernel warning
> that is causing a boot test to fail, but this has been happening for a
> few releases now (I would have reported it earlier but we have been
> having some infrastructure issues) ...
>
> WARNING KERN urandom_read_iter: 82 callbacks suppressed
>
> This appears to be introduced by commit "random: convert to using
> fops->read_iter()" [0]. Interestingly, I am not seeing this in the
> mainline as far as I can tell and so I am not sure if there is something
> else that is missing?
>
>
> Test results for stable-v5.10:
> 10 builds: 10 pass, 0 fail
> 28 boots: 28 pass, 0 fail
> 75 tests: 74 pass, 1 fail
>
> Linux version: 5.10.123-rc1-gf67ea0f67087
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
> tegra20-ventana, tegra210-p2371-2180,
> tegra210-p3450-0000, tegra30-cardhu-a04
>
> Test failures: tegra194-p2972-0000: boot.py
>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
>
> Jon
>
> [0]
> https://lore.kernel.org/lkml/20220527084907.568432116@linuxfoundation.org/
Please CC me on RNG issues.
I'm surprised that this message results in a failure. It's not a
WARN_ON() or a BUG() that's being triggered here. This is just the
simple `pr_warn("%s: %d callbacks suppressed\n")` in lib/ratelimit.c,
which really shouldn't be causing your CI to fail. Sounds like your
harness could use some adjusting.
Nonetheless, you have found a 4 year old bug in the urandom warning
accounting that was recently made more easily triggerable by a newer
commit, though not the one you mentioned. I'll fix this up and keep you
CC'd on the patch, which should make it into stable as well.
Jason
Hi Jason,
On 16/06/2022 14:11, Jason A. Donenfeld wrote:
> Hi Jon,
>
> On Thu, Jun 16, 2022 at 09:48:37AM +0100, Jon Hunter wrote:
>> No new regressions for Tegra. I am seeing the following kernel warning
>> that is causing a boot test to fail, but this has been happening for a
>> few releases now (I would have reported it earlier but we have been
>> having some infrastructure issues) ...
>>
>> WARNING KERN urandom_read_iter: 82 callbacks suppressed
>>
>> This appears to be introduced by commit "random: convert to using
>> fops->read_iter()" [0]. Interestingly, I am not seeing this in the
>> mainline as far as I can tell and so I am not sure if there is something
>> else that is missing?
>>
>>
>> Test results for stable-v5.10:
>> 10 builds: 10 pass, 0 fail
>> 28 boots: 28 pass, 0 fail
>> 75 tests: 74 pass, 1 fail
>>
>> Linux version: 5.10.123-rc1-gf67ea0f67087
>> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
>> tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
>> tegra20-ventana, tegra210-p2371-2180,
>> tegra210-p3450-0000, tegra30-cardhu-a04
>>
>> Test failures: tegra194-p2972-0000: boot.py
>>
>> Tested-by: Jon Hunter <jonathanh@nvidia.com>
>>
>> Jon
>>
>> [0]
>> https://lore.kernel.org/lkml/20220527084907.568432116@linuxfoundation.org/
>
> Please CC me on RNG issues.
Yes no problem.
> I'm surprised that this message results in a failure. It's not a
> WARN_ON() or a BUG() that's being triggered here. This is just the
> simple `pr_warn("%s: %d callbacks suppressed\n")` in lib/ratelimit.c,
> which really shouldn't be causing your CI to fail. Sounds like your
> harness could use some adjusting.
It is not a hard failure, but any new warning will be flagged and cause
this particular test to fail. So all I could see is that a new warning
was occurring and wanted to understand what was going on. We can ignore
the warning if necessary.
> Nonetheless, you have found a 4 year old bug in the urandom warning
> accounting that was recently made more easily triggerable by a newer
> commit, though not the one you mentioned. I'll fix this up and keep you
> CC'd on the patch, which should make it into stable as well.
OK, great! Happy to test anything on my end.
Cheers
Jon
--
nvpublic
random.c ratelimits how much it warns about uninitialized urandom reads
using __ratelimit. When the RNG is finally initialized, it prints the
number of missed messages due to ratelimiting.
It has been this way since that functionality was introduced back in
2018. Recently, cc1e127bfa95 ("random: remove ratelimiting for in-kernel
unseeded randomness") put a bit more stress on the urandom ratelimiting,
which teased out a bug in the implementation.
Specifically, when under pressure, __ratelimit() will print its own
message and reset the count back to 0, making the final message at the
end less useful. Secondly, it does so as a pr_warn(), which apparently
is undesirable for people's CI.
Fortunately, __ratelimit() has the RATELIMIT_MSG_ON_RELEASE flag exactly
for this purpose, so we set the flag.
Fixes: 4e00b339e264 ("random: rate limit unseeded randomness warnings")
Cc: stable@vger.kernel.org
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Reported-by: Ron Economos <re@w6rz.net>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
drivers/char/random.c | 2 +-
include/linux/ratelimit_types.h | 12 ++++++++----
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index d0e4c89c4fcb..07a022e24057 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -87,7 +87,7 @@ static struct fasync_struct *fasync;
/* Control how we warn userspace. */
static struct ratelimit_state urandom_warning =
- RATELIMIT_STATE_INIT("warn_urandom_randomness", HZ, 3);
+ RATELIMIT_STATE_INIT_FLAGS("urandom_warning", HZ, 3, RATELIMIT_MSG_ON_RELEASE);
static int ratelimit_disable __read_mostly =
IS_ENABLED(CONFIG_WARN_ALL_UNSEEDED_RANDOM);
module_param_named(ratelimit_disable, ratelimit_disable, int, 0644);
diff --git a/include/linux/ratelimit_types.h b/include/linux/ratelimit_types.h
index c21c7f8103e2..002266693e50 100644
--- a/include/linux/ratelimit_types.h
+++ b/include/linux/ratelimit_types.h
@@ -23,12 +23,16 @@ struct ratelimit_state {
unsigned long flags;
};
-#define RATELIMIT_STATE_INIT(name, interval_init, burst_init) { \
- .lock = __RAW_SPIN_LOCK_UNLOCKED(name.lock), \
- .interval = interval_init, \
- .burst = burst_init, \
+#define RATELIMIT_STATE_INIT_FLAGS(name, interval_init, burst_init, flags_init) { \
+ .lock = __RAW_SPIN_LOCK_UNLOCKED(name.lock), \
+ .interval = interval_init, \
+ .burst = burst_init, \
+ .flags = flags_init, \
}
+#define RATELIMIT_STATE_INIT(name, interval_init, burst_init) \
+ RATELIMIT_STATE_INIT_FLAGS(name, interval_init, burst_init, 0)
+
#define RATELIMIT_STATE_INIT_DISABLED \
RATELIMIT_STATE_INIT(ratelimit_state, 0, DEFAULT_RATELIMIT_BURST)
--
2.35.1On 6/16/22 6:20 AM, Jason A. Donenfeld wrote:
> random.c ratelimits how much it warns about uninitialized urandom reads
> using __ratelimit. When the RNG is finally initialized, it prints the
> number of missed messages due to ratelimiting.
>
> It has been this way since that functionality was introduced back in
> 2018. Recently, cc1e127bfa95 ("random: remove ratelimiting for in-kernel
> unseeded randomness") put a bit more stress on the urandom ratelimiting,
> which teased out a bug in the implementation.
>
> Specifically, when under pressure, __ratelimit() will print its own
> message and reset the count back to 0, making the final message at the
> end less useful. Secondly, it does so as a pr_warn(), which apparently
> is undesirable for people's CI.
>
> Fortunately, __ratelimit() has the RATELIMIT_MSG_ON_RELEASE flag exactly
> for this purpose, so we set the flag.
>
> Fixes: 4e00b339e264 ("random: rate limit unseeded randomness warnings")
> Cc: stable@vger.kernel.org
> Reported-by: Jon Hunter <jonathanh@nvidia.com>
> Reported-by: Ron Economos <re@w6rz.net>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> drivers/char/random.c | 2 +-
> include/linux/ratelimit_types.h | 12 ++++++++----
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index d0e4c89c4fcb..07a022e24057 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -87,7 +87,7 @@ static struct fasync_struct *fasync;
>
> /* Control how we warn userspace. */
> static struct ratelimit_state urandom_warning =
> - RATELIMIT_STATE_INIT("warn_urandom_randomness", HZ, 3);
> + RATELIMIT_STATE_INIT_FLAGS("urandom_warning", HZ, 3, RATELIMIT_MSG_ON_RELEASE);
> static int ratelimit_disable __read_mostly =
> IS_ENABLED(CONFIG_WARN_ALL_UNSEEDED_RANDOM);
> module_param_named(ratelimit_disable, ratelimit_disable, int, 0644);
> diff --git a/include/linux/ratelimit_types.h b/include/linux/ratelimit_types.h
> index c21c7f8103e2..002266693e50 100644
> --- a/include/linux/ratelimit_types.h
> +++ b/include/linux/ratelimit_types.h
> @@ -23,12 +23,16 @@ struct ratelimit_state {
> unsigned long flags;
> };
>
> -#define RATELIMIT_STATE_INIT(name, interval_init, burst_init) { \
> - .lock = __RAW_SPIN_LOCK_UNLOCKED(name.lock), \
> - .interval = interval_init, \
> - .burst = burst_init, \
> +#define RATELIMIT_STATE_INIT_FLAGS(name, interval_init, burst_init, flags_init) { \
> + .lock = __RAW_SPIN_LOCK_UNLOCKED(name.lock), \
> + .interval = interval_init, \
> + .burst = burst_init, \
> + .flags = flags_init, \
> }
>
> +#define RATELIMIT_STATE_INIT(name, interval_init, burst_init) \
> + RATELIMIT_STATE_INIT_FLAGS(name, interval_init, burst_init, 0)
> +
> #define RATELIMIT_STATE_INIT_DISABLED \
> RATELIMIT_STATE_INIT(ratelimit_state, 0, DEFAULT_RATELIMIT_BURST)
>
Tested on 5.15.48 kernel for RISC-V RV64. Works good, urandom_read_iter
warnings are suppressed.
Tested-by: Ron Economos <re@w6rz.net>
On 6/16/22 1:48 AM, Jon Hunter wrote: > > On 14/06/2022 19:40, Greg Kroah-Hartman wrote: >> This is the start of the stable review cycle for the 5.10.123 release. >> There are 11 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, 16 Jun 2022 18:37:02 +0000. >> Anything received after that time might be too late. >> >> The whole patch series can be found in one patch at: >> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.123-rc1.gz >> >> or in the git tree and branch at: >> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git >> linux-5.10.y >> and the diffstat can be found below. >> >> thanks, >> >> greg k-h > > No new regressions for Tegra. I am seeing the following kernel warning > that is causing a boot test to fail, but this has been happening for a > few releases now (I would have reported it earlier but we have been > having some infrastructure issues) ... > > WARNING KERN urandom_read_iter: 82 callbacks suppressed > > This appears to be introduced by commit "random: convert to using > fops->read_iter()" [0]. Interestingly, I am not seeing this in the > mainline as far as I can tell and so I am not sure if there is > something else that is missing? > I'm also seeing this on RISC-V. 5.15 and 5.17, but not 5.18.
On 16/06/2022 10:46, Ron Economos wrote: > On 6/16/22 1:48 AM, Jon Hunter wrote: >> >> On 14/06/2022 19:40, Greg Kroah-Hartman wrote: >>> This is the start of the stable review cycle for the 5.10.123 release. >>> There are 11 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, 16 Jun 2022 18:37:02 +0000. >>> Anything received after that time might be too late. >>> >>> The whole patch series can be found in one patch at: >>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.123-rc1.gz >>> >>> or in the git tree and branch at: >>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git >>> linux-5.10.y >>> and the diffstat can be found below. >>> >>> thanks, >>> >>> greg k-h >> >> No new regressions for Tegra. I am seeing the following kernel warning >> that is causing a boot test to fail, but this has been happening for a >> few releases now (I would have reported it earlier but we have been >> having some infrastructure issues) ... >> >> WARNING KERN urandom_read_iter: 82 callbacks suppressed >> >> This appears to be introduced by commit "random: convert to using >> fops->read_iter()" [0]. Interestingly, I am not seeing this in the >> mainline as far as I can tell and so I am not sure if there is >> something else that is missing? >> > I'm also seeing this on RISC-V. 5.15 and 5.17, but not 5.18. > That's good to know. I don't see this on 5.18 either, just 5.10, 5.15 and 5.17. Jon -- nvpublic
Hi Jon, On Thu, Jun 16, 2022 at 11:11:25AM +0100, Jon Hunter wrote: > On 16/06/2022 10:46, Ron Economos wrote: > > On 6/16/22 1:48 AM, Jon Hunter wrote: > > I'm also seeing this on RISC-V. 5.15 and 5.17, but not 5.18. > That's good to know. I don't see this on 5.18 either, just 5.10, 5.15 > and 5.17. Right. 5.18 has https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48bff1053c172e6c7f340e506027d118147c8b7f which I thought was a bit too risky to backport. So on 5.18 you're not seeing this behavior because /dev/urandom is always seeded magically and hence there is never an opportunity to warn about unseeded randomness. Maybe we can think about backporting that if no issues come up after several months, but I'd rather tread lightly with that one. Anyway, as mentioned in the other message, I've got a patch I'll send out in a minute for the unwanted pr_warn(). Jason
On 2022-06-14 20:40:22, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.123 release. > There are 11 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, 16 Jun 2022 18:37:02 +0000. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.123-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h Hi Greg - I successfully tested this release candidate in x86_64 Hyper-V Azure VMs with speculation controls both enabled and disabled. Speculation controls are passed through to the guest and, of particular interest for this release candidate, set the FB_CLEAR bit in the IA32_ARCH_CAPABILITIES MSR. The FB_CLEAR bit's presence is accurately conveyed in the kernel log messages during boot and in the /sys/devices/system/cpu/vulnerabilities/mmio_stale_data file. I did a full LTP run in both scenarios (the results were the same) and also compared the results to a previous run against the v5.10.118 release (there were no regressions). Tested-by: Tyler Hicks <tyhicks@linux.microsoft.com> Tyler
On 2022/6/15 2:40, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.123 release. > There are 11 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, 16 Jun 2022 18:37:02 +0000. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.123-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h > Tested on arm64 and x86 for 5.10.123-rc1, Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Branch: linux-5.10.y Version: 5.10.123-rc1 Commit: f67ea0f670870facb37c20f19e483ec74a2cba63 Compiler: gcc version 7.3.0 (GCC) arm64: -------------------------------------------------------------------- Testcase Result Summary: total: 9033 passed: 9033 failed: 0 timeout: 0 -------------------------------------------------------------------- x86: -------------------------------------------------------------------- Testcase Result Summary: total: 9033 passed: 9033 failed: 0 timeout: 0 -------------------------------------------------------------------- Tested-by: Hulk Robot <hulkrobot@huawei.com>
On Tue, Jun 14, 2022 at 08:40:22PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.123 release. > There are 11 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, 16 Jun 2022 18:37:02 +0000. > Anything received after that time might be too late. > Build results: total: 163 pass: 163 fail: 0 Qemu test results: total: 477 pass: 477 fail: 0 Tested-by: Guenter Roeck <linux@roeck-us.net> Guenter
On Wed, 15 Jun 2022 at 00:15, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > This is the start of the stable review cycle for the 5.10.123 release. > There are 11 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, 16 Jun 2022 18:37:02 +0000. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.123-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> ## Build * kernel: 5.10.123-rc1 * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc * git branch: linux-5.10.y * git commit: f67ea0f670870facb37c20f19e483ec74a2cba63 * git describe: v5.10.122-12-gf67ea0f67087 * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.122-12-gf67ea0f67087 ## Test Regressions (compared to v5.10.118) No test regressions found. ## Metric Regressions (compared to v5.10.118) No metric regressions found. ## Test Fixes (compared to v5.10.118) No test fixes found. ## Metric Fixes (compared to v5.10.118) No metric fixes found. ## Test result summary total: 123351, pass: 110941, fail: 243, skip: 11563, xfail: 604 ## Build Summary * arc: 10 total, 10 passed, 0 failed * arm: 314 total, 314 passed, 0 failed * arm64: 58 total, 58 passed, 0 failed * i386: 52 total, 49 passed, 3 failed * mips: 37 total, 37 passed, 0 failed * parisc: 12 total, 12 passed, 0 failed * powerpc: 51 total, 51 passed, 0 failed * riscv: 27 total, 27 passed, 0 failed * s390: 21 total, 21 passed, 0 failed * sh: 24 total, 24 passed, 0 failed * sparc: 12 total, 12 passed, 0 failed * x86_64: 56 total, 55 passed, 1 failed ## Test suites summary * fwts * igt-gpu-tools * kunit * kvm-unit-tests * libgpiod * libhugetlbfs * log-parser-boot * log-parser-test * ltp-cap_bounds * ltp-cap_bounds-tests * ltp-commands * ltp-commands-tests * ltp-containers * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests * ltp-fcntl-locktests-tests * ltp-filecaps * ltp-filecaps-tests * ltp-fs * ltp-fs-tests * ltp-fs_bind * ltp-fs_bind-tests * ltp-fs_perms_simple * ltp-fs_perms_simple-tests * ltp-fsx * ltp-fsx-tests * ltp-hugetlb * ltp-hugetlb-tests * ltp-io * ltp-io-tests * ltp-ipc * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty * ltp-pty-tests * ltp-sched-tests * ltp-securebits * ltp-securebits-tests * ltp-smoke * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * packetdrill * perf * perf/Zstd-perf.data-compression * rcutorture * ssuite * v4l2-compliance * vdso -- Linaro LKFT https://lkft.linaro.org
Hi Greg, On Tue, Jun 14, 2022 at 08:40:22PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.123 release. > There are 11 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, 16 Jun 2022 18:37:02 +0000. > Anything received after that time might be too late. Build test (gcc version 11.3.1 20220612): mips: 63 configs -> no failure arm: 104 configs -> no failure arm64: 3 configs -> no failure x86_64: 4 configs -> no failure alpha allmodconfig -> no failure powerpc allmodconfig -> no failure riscv allmodconfig -> no failure s390 allmodconfig -> no failure xtensa allmodconfig -> no failure Boot test: x86_64: Booted on my test laptop. No regression. x86_64: Booted on qemu. No regression. [1] arm64: Booted on rpi4b (4GB model). No regression. [2] [1]. https://openqa.qa.codethink.co.uk/tests/1339 [2]. https://openqa.qa.codethink.co.uk/tests/1343 Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> -- Regards Sudip
On Tue, 14 Jun 2022 20:40:22 +0200, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 5.10.123 release.
> There are 11 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, 16 Jun 2022 18:37:02 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.123-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
5.10.123-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Tested-by: Fox Chen <foxhlchen@gmail.com>
On 6/14/22 12:40 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.123 release. > There are 11 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, 16 Jun 2022 18:37:02 +0000. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.123-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. Tested-by: Shuah Khan <skhan@linuxfoundation.org> thanks, -- Shuah
On 6/14/22 11:40, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.123 release. > There are 11 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, 16 Jun 2022 18:37:02 +0000. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.123-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli <f.fainelli@gmail.com> -- Florian
© 2016 - 2026 Red Hat, Inc.