Date   

Quality of wireless drivers (rtl8821ae, ath10k, wl18xx)

Pavel Machek
 

Hi!

On cip-members there's discussion about quality of selected wireless
drivers.

AFAICT we are reviewing changes to those drivers on -stable series
(good). We are not testing the drivers in any meaningful way, and it
may be good to mark them built-in (=y, not modular) in some configs so
at least probing is tested. Proper testing would be quite hard, and
ammount of changes to them in stable probably does not require it.

To me it looks like wl18xx is getting very little changes; rtl8821ae
gets a bit more, but they are simple cleanups; only ath10k seems to be
under any kind of active development.

I have no experience with any of those drivers. I don't expect much
work would need to be done on any of these. If there's work I'd expect
ath10k to be slightly easier to work with.

Any comments?

Best regards,
Pavel

* rtl8821ae (wifi + BT)

CONFIG_RTL8821AE
./drivers/net/wireless/realtek/rtlwifi/rtl8821ae
./drivers/bluetooth/btrtl.c

./4.19.y-cip/x86/plathome_obsvx2_defconfig:CONFIG_RTL8821AE=m
./5.10.y-cip-rt/x86/siemens_i386-rt.config:CONFIG_BT_RTL=m

=> We should be reviewing it. We probably are not testing it at
all. Single change in 5.10-stable. Some developement from 4.19, but
looks mostly like staging-type cleanups.

* ath10k

CONFIG_ATH10K
./drivers/net/wireless/ath/ath10k/

./5.10.y-cip/arm64/qemu_arm64_defconfig:CONFIG_ATH10K=m
./5.10.y-cip/arm64/qemu_arm64_defconfig:CONFIG_ATH10K_PCI=m
./5.10.y-cip/x86/plathome_obsvx2_defconfig:CONFIG_ATH10K=m
./5.10.y-cip/x86/plathome_obsvx2_defconfig:CONFIG_ATH10K_PCI=m
./5.10.y-cip/arm/moxa_mxc_defconfig:CONFIG_ATH10K=m
./5.10.y-cip/arm/moxa_mxc_defconfig:CONFIG_ATH10K_DFS_CERTIFIED=y

=> We should be reviewing it. We probably are not testing it at
all. 19 patches in 5.10-stable. Under active development, changes from 4.19.

* wl18xx

(wl1837 hardware is handled by wl18xx driver.)

CONFIG_WL18XX
CONFIG_BT_HCIUART_LL
./drivers/net/wireless/ti/wl18xx
./drivers/bluetooth/hci_ll.c

./5.10.y-cip/arm64/qemu_arm64_defconfig:CONFIG_WL18XX=m
./5.10.y-cip/arm64/ctj_zynqmp_defconfig:CONFIG_WL18XX=y
./5.10.y-cip/arm/moxa_mxc_defconfig:CONFIG_WL18XX=m

./5.10.y-cip/arm64/qemu_arm64_defconfig:CONFIG_BT_HCIUART_LL=y
./5.10.y-cip/arm64/ctj_zynqmp_defconfig:CONFIG_BT_HCIUART_LL=y

=> We should be reviewing it. We do some minimal testing by compiling
module in ZYNQMP configuration. No changes in 5.10-stable. Very few
changes from 4.19, mostly treewide cleanups.



--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [isar-cip-core][PATCH 2/2] kas/opt/efibootguard: Move setting of IMAGE_TYPE

Quirin Gylstorff
 

On 9/29/21 12:09 AM, Jan Kiszka wrote:
On 28.09.21 20:49, Quirin Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

This seperates the image type from the boot loader.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
kas/opt/efibootguard.yml | 1 -
kas/opt/wic-img.yml | 19 +++++++++++++++++++
2 files changed, 19 insertions(+), 1 deletion(-)
create mode 100644 kas/opt/wic-img.yml

diff --git a/kas/opt/efibootguard.yml b/kas/opt/efibootguard.yml
index 705a76d..4e8be69 100644
--- a/kas/opt/efibootguard.yml
+++ b/kas/opt/efibootguard.yml
@@ -23,6 +23,5 @@ local_conf_header:
efibootguard-wic: |
WDOG_TIMEOUT ?= "60"
WICVARS += "WDOG_TIMEOUT"
- IMAGE_TYPE ?= "wic-img"
WKS_FILE ?= "${MACHINE}-${SWUPDATE_BOOTLOADER}.wks"

diff --git a/kas/opt/wic-img.yml b/kas/opt/wic-img.yml
new file mode 100644
index 0000000..2b02b42
--- /dev/null
+++ b/kas/opt/wic-img.yml
@@ -0,0 +1,19 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Siemens AG, 2021
+#
+# Authors:
+# Quirin Gylstorff <quirin.gylstorff@siemens.com>
+#
+# SPDX-License-Identifier: MIT
+#
+# This kas file set the IMAGE_TYPE to wic-img
+# The device specific WKS_FILE needs to be set seperately.
+
+header:
+ version: 10
+
+local_conf_header:
+ image-type: |
+ IMAGE_TYPE = "wic-img"
What's the purpose of this file? When should a user specify this option?
I think we already have too many option files and rather need to reduce
them than adding more.
My idea was to split the selection of efibootguard from the usage of wic-img so that we can generate other image formats together with efibootguard - in hindsight this is not necessary - you can skip this patch as patch 1 of this set solves the issue alone.


Quirin
Jan
PS: Something is currently off with archiving on lore.kernel.org.
Messages from this thread but also others appear twice there:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fcip-dev%2F20210928184946.GHmZQFBkA_wEzR1iQiB_04frBV52DnaYGHOSYtAdjok%40z%2FT%2F%23t&;data=04%7C01%7C6549bcd2-981c-4c06-8e1b-b5c6cc3441b4%40ad011.siemens.com%7Cc59cf4afa01c4ef24ff208d982ccb240%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637684637933939193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=kNC4hyC3dM8p%2BUVHMpaGjs7O%2BmC76P4UKCXcIHMStO8%3D&amp;reserved=0


Re: [isar-cip-core][PATCH 2/2] kas/opt/efibootguard: Move setting of IMAGE_TYPE

Jan Kiszka <jan.kiszka@...>
 

On 28.09.21 20:49, Quirin Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

This seperates the image type from the boot loader.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
kas/opt/efibootguard.yml | 1 -
kas/opt/wic-img.yml | 19 +++++++++++++++++++
2 files changed, 19 insertions(+), 1 deletion(-)
create mode 100644 kas/opt/wic-img.yml

diff --git a/kas/opt/efibootguard.yml b/kas/opt/efibootguard.yml
index 705a76d..4e8be69 100644
--- a/kas/opt/efibootguard.yml
+++ b/kas/opt/efibootguard.yml
@@ -23,6 +23,5 @@ local_conf_header:
efibootguard-wic: |
WDOG_TIMEOUT ?= "60"
WICVARS += "WDOG_TIMEOUT"
- IMAGE_TYPE ?= "wic-img"
WKS_FILE ?= "${MACHINE}-${SWUPDATE_BOOTLOADER}.wks"

diff --git a/kas/opt/wic-img.yml b/kas/opt/wic-img.yml
new file mode 100644
index 0000000..2b02b42
--- /dev/null
+++ b/kas/opt/wic-img.yml
@@ -0,0 +1,19 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Siemens AG, 2021
+#
+# Authors:
+# Quirin Gylstorff <quirin.gylstorff@siemens.com>
+#
+# SPDX-License-Identifier: MIT
+#
+# This kas file set the IMAGE_TYPE to wic-img
+# The device specific WKS_FILE needs to be set seperately.
+
+header:
+ version: 10
+
+local_conf_header:
+ image-type: |
+ IMAGE_TYPE = "wic-img"
What's the purpose of this file? When should a user specify this option?
I think we already have too many option files and rather need to reduce
them than adding more.

Jan

PS: Something is currently off with archiving on lore.kernel.org.
Messages from this thread but also others appear twice there:
https://lore.kernel.org/cip-dev/20210928184946.GHmZQFBkA_wEzR1iQiB_04frBV52DnaYGHOSYtAdjok@z/T/#t


[isar-cip-core][PATCH 2/2] kas/opt/efibootguard: Move setting of IMAGE_TYPE

Quirin Gylstorff
 

From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

This seperates the image type from the boot loader.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
kas/opt/efibootguard.yml | 1 -
kas/opt/wic-img.yml | 19 +++++++++++++++++++
2 files changed, 19 insertions(+), 1 deletion(-)
create mode 100644 kas/opt/wic-img.yml

diff --git a/kas/opt/efibootguard.yml b/kas/opt/efibootguard.yml
index 705a76d..4e8be69 100644
--- a/kas/opt/efibootguard.yml
+++ b/kas/opt/efibootguard.yml
@@ -23,6 +23,5 @@ local_conf_header:
efibootguard-wic: |
WDOG_TIMEOUT ?= "60"
WICVARS += "WDOG_TIMEOUT"
- IMAGE_TYPE ?= "wic-img"
WKS_FILE ?= "${MACHINE}-${SWUPDATE_BOOTLOADER}.wks"

diff --git a/kas/opt/wic-img.yml b/kas/opt/wic-img.yml
new file mode 100644
index 0000000..2b02b42
--- /dev/null
+++ b/kas/opt/wic-img.yml
@@ -0,0 +1,19 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Siemens AG, 2021
+#
+# Authors:
+# Quirin Gylstorff <quirin.gylstorff@siemens.com>
+#
+# SPDX-License-Identifier: MIT
+#
+# This kas file set the IMAGE_TYPE to wic-img
+# The device specific WKS_FILE needs to be set seperately.
+
+header:
+ version: 10
+
+local_conf_header:
+ image-type: |
+ IMAGE_TYPE = "wic-img"
--
2.30.2


[isar-cip-core][PATCH 1/2] kas/opt/swupdate: Change assignment of IMAGE_TYPE and WKS_FILE

Quirin Gylstorff
 

From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

Replace the default assignment to ensure the generation of the
swu file. As stated in [1]: If multiple `?=` assignments are used
the first of those assignments ends up getting used.

This fixes [2].

[1]: https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#setting-a-default-value
[2]: https://gitlab.com/cip-project/cip-core/isar-cip-core/-/issues/14

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
kas/opt/swupdate.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kas/opt/swupdate.yml b/kas/opt/swupdate.yml
index 7d86ad5..3cc02a3 100644
--- a/kas/opt/swupdate.yml
+++ b/kas/opt/swupdate.yml
@@ -19,5 +19,5 @@ local_conf_header:
IMAGE_INSTALL_append = " swupdate"

wic-swu: |
- IMAGE_TYPE ?= "wic-swu-img"
- WKS_FILE ?= "${MACHINE}-${SWUPDATE_BOOTLOADER}.wks"
+ IMAGE_TYPE = "wic-swu-img"
+ WKS_FILE = "${MACHINE}-${SWUPDATE_BOOTLOADER}.wks"
--
2.30.2


[isar-cip-core][PATCH 0/2] Fix for issue gitlab #14

Quirin Gylstorff
 

From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

This Fixes [1]
.swu file is not getting generated for checking new swupdate handler (#14)

This issue occured due to [1]: If multiple `?=` assignments are used
the first of those assignments ends up getting used.

[1]: https://gitlab.com/cip-project/cip-core/isar-cip-core/-/issues/14
[2]: https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#setting-a-default-value


Quirin Gylstorff (2):
kas/opt/swupdate: Change assignment of IMAGE_TYPE and WKS_FILE
kas/opt/efibootguard: Move setting of IMAGE_TYPE

kas/opt/efibootguard.yml | 1 -
kas/opt/swupdate.yml | 4 ++--
kas/opt/wic-img.yml | 19 +++++++++++++++++++
3 files changed, 21 insertions(+), 3 deletions(-)
create mode 100644 kas/opt/wic-img.yml

--
2.30.2


Re: Coordinating stable reviews

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: cip-dev@lists.cip-project.org [mailto:cip-dev@lists.cip-project.org] On Behalf Of Pavel Machek
Sent: Monday, September 27, 2021 7:10 PM
To: uli@fpond.eu; cip-dev@lists.cip-project.org
Subject: [cip-dev] Coordinating stable reviews

Hi!

It is good to review "stable" patches soon, because such reviews are
more useful for the stable community, and because when bug is spotted,
it is easier to get patch dropped in the 5.10.X-rc phase than waiting
for 5.10.X release and then having patch reverted in 5.10.X+1.

Unfortunately, we don't have good system for coordinating reviews in
-rc phase.
It's different from the current system, but how about using patchwork?
Somehow forward the patch posted to stable@kernel.org as -rc to
cip-dev and review it at patchwork.kernel.org. It doesn't meet all
requests because it can't be operated from the command line.

Also, as Ulrich wrote, I think it's a good idea to use gitlab.
I suggest a way to comment on the commit instead of using the gitlab wiki.
for example, we can comment on the following URL (commit). We need to investigate,
but I think it can be manipulated from the command line using Gitlab's
API or libraries.

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/commit/d25b48d4d3ef1ce75ce5628a8a3ba60a2427090f

There's a script (commit.py) that produces one-line-per-patch output
suitable for review. One possibility would be to have shared place
somewhere reviewers could tag "I'm working on these patches".

I don't believe lts-commit-list.git repository is suitable for that;
format suitable for review is different from what we have in
lts-commit-list, and there is going to be multiple updates per day in
busy periods.

We don't really need commit messages for this. Actually, we don't
really need to keep history, either. It would be good if system could
be controlled from command line for easy scripting.

Any ideas what kind of service could be used for this?
Best regards,
Nobuhiro


Re: Prompt timeouts on ipc227e board -- randomness related?

Chris Paterson
 

Hello Pavel,

From: Pavel Machek <pavel@denx.de>
Sent: 25 September 2021 21:06

Hi!

It is not first time I see this failure:
Thank you for reporting the issue.

Bikram is going to take a look for us (thank you).

Kind regards, Chris


https://lava.ciplatform.org/scheduler/job/444336


[[0;32m OK [0m] Started Login Service.
[[0m[0;31m* [0m] (1 of 2) A start job is running for…ate sshd host keys (7s /
no limit)[K[[0;1;31m*[0m[0;31m* [0m] (1 of 2) A start job is running for…ate
sshd host keys (8s / no limit)[K[[0;31m*[0;1;31m*[0m[0;31m* [0m] (1 of 2)
A start job is running for…ate sshd host keys (9s / no limit)[K[
[0;31m*[0;1;31m*[0m[0;31m* [0m] (2 of 2) A start job is running for…evices-
eth0.device (8s / 1min 30s)[ 19.855328] systemd[1]: apt-daily-
upgrade.timer: Adding 3min 2.027476s random time.
[ 19.864207] systemd[1]: apt-daily.timer: Adding 1h 54min 15.794344s
random time.
[ 21.406490] systemd[1]: apt-daily-upgrade.timer: Adding 55min 47.041488s
random time.
[ 21.415357] systemd[1]: apt-daily.timer: Adding 11h 48min 4.457495s
random time.
[ 22.049807] systemd[1]: apt-daily-upgrade.timer: Adding 3min 54.125406s
random time.
[ 22.058500] systemd[1]: apt-daily.timer: Adding 8h 34min 47.388595s
random time.
[ 22.511646] systemd[1]: apt-daily-upgrade.timer: Adding 25min 13.015405s
random time.
[ 22.520510] systemd[1]: apt-daily.timer: Adding 11h 58min 24.212170s
random time.
[K[[0;32m OK [0m] Started Regenerate sshd host keys.
wait for prompt timed out
end: 2.3.4.1 login-action (duration 00:00:24) [common]
case: login-action
case_id: 9417066
definition: lava
duration: 23.98

Any idea what is going on there? Is it just a test problem, or do we
have kernel regression that only happens sometimes?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: Coordinating stable reviews

Ulrich Hecht
 

On 09/27/2021 12:09 PM Pavel Machek <pavel@denx.de> wrote:
Unfortunately, we don't have good system for coordinating reviews in
-rc phase.

There's a script (commit.py) that produces one-line-per-patch output
suitable for review. One possibility would be to have shared place
somewhere reviewers could tag "I'm working on these patches".

I don't believe lts-commit-list.git repository is suitable for that;
format suitable for review is different from what we have in
lts-commit-list, and there is going to be multiple updates per day in
busy periods.

We don't really need commit messages for this. Actually, we don't
really need to keep history, either. It would be good if system could
be controlled from command line for easy scripting.

Any ideas what kind of service could be used for this?
gitlab comes to mind. IIUC, wiki pages are part of the project, but
contained in a separate git repository.

The output of commit.py is practically markdown already; just add a
table header and some extra "|"'s, and you're good.

There will be a history, but I think that can be safely ignored.

CU
Uli


Re: Coordinating stable reviews

Pavel Machek
 

Hi!

We don't really need commit messages for this. Actually, we don't
really need to keep history, either. It would be good if system could
be controlled from command line for easy scripting.

Any ideas what kind of service could be used for this?
I guess I should mention alternate possibilities. We could try to
somehow "hash" the commits... Perhaps I'd review all the patches where
upstream sha begins with 0-6. But patches in -stable often come in
series that depend on each other, and it would be good if single
person reviewed them.

We could also split based on first character of subject, or on
subsystem patch touches. I guess that would have other disadvantages
like uneven distribution of work when big ammount of btrfs fixes hits
the -stable.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Coordinating stable reviews

Pavel Machek
 

Hi!

It is good to review "stable" patches soon, because such reviews are
more useful for the stable community, and because when bug is spotted,
it is easier to get patch dropped in the 5.10.X-rc phase than waiting
for 5.10.X release and then having patch reverted in 5.10.X+1.

Unfortunately, we don't have good system for coordinating reviews in
-rc phase.

There's a script (commit.py) that produces one-line-per-patch output
suitable for review. One possibility would be to have shared place
somewhere reviewers could tag "I'm working on these patches".

I don't believe lts-commit-list.git repository is suitable for that;
format suitable for review is different from what we have in
lts-commit-list, and there is going to be multiple updates per day in
busy periods.

We don't really need commit messages for this. Actually, we don't
really need to keep history, either. It would be good if system could
be controlled from command line for easy scripting.

Any ideas what kind of service could be used for this?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


[isar-cip-core][PATCH] scripts/wic/efibootguard-boot: Add missing whitespace

Quirin Gylstorff
 

From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

The generated Kernel commandline was incorrect concatenated.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
scripts/lib/wic/plugins/source/efibootguard-boot.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/source/efibootguard-boot.py b/scripts/lib/wic/plugins/source/efibootguard-boot.py
index b85cfca..882729a 100644
--- a/scripts/lib/wic/plugins/source/efibootguard-boot.py
+++ b/scripts/lib/wic/plugins/source/efibootguard-boot.py
@@ -99,7 +99,7 @@ class EfibootguardBootPlugin(SourcePlugin):
exit(1)
root_dev = root_dev.replace(":", "=")

- cmdline += " root=%s rw" % root_dev
+ cmdline += " root=%s rw " % root_dev
boot_files.append(kernel_image)
boot_files.append(initrd_image)
cmdline += "initrd=%s" % initrd_image if initrd_image else ""
--
2.30.2


Prompt timeouts on ipc227e board -- randomness related?

Pavel Machek
 

Hi!

It is not first time I see this failure:

https://lava.ciplatform.org/scheduler/job/444336


[[0;32m OK [0m] Started Login Service.
[[0m[0;31m* [0m] (1 of 2) A start job is running for…ate sshd host keys (7s / no limit)[K[[0;1;31m*[0m[0;31m* [0m] (1 of 2) A start job is running for…ate sshd host keys (8s / no limit)[K[[0;31m*[0;1;31m*[0m[0;31m* [0m] (1 of 2) A start job is running for…ate sshd host keys (9s / no limit)[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] (2 of 2) A start job is running for…evices-eth0.device (8s / 1min 30s)[ 19.855328] systemd[1]: apt-daily-upgrade.timer: Adding 3min 2.027476s random time.
[ 19.864207] systemd[1]: apt-daily.timer: Adding 1h 54min 15.794344s random time.
[ 21.406490] systemd[1]: apt-daily-upgrade.timer: Adding 55min 47.041488s random time.
[ 21.415357] systemd[1]: apt-daily.timer: Adding 11h 48min 4.457495s random time.
[ 22.049807] systemd[1]: apt-daily-upgrade.timer: Adding 3min 54.125406s random time.
[ 22.058500] systemd[1]: apt-daily.timer: Adding 8h 34min 47.388595s random time.
[ 22.511646] systemd[1]: apt-daily-upgrade.timer: Adding 25min 13.015405s random time.
[ 22.520510] systemd[1]: apt-daily.timer: Adding 11h 58min 24.212170s random time.
[K[[0;32m OK [0m] Started Regenerate sshd host keys.
wait for prompt timed out
end: 2.3.4.1 login-action (duration 00:00:24) [common]
case: login-action
case_id: 9417066
definition: lava
duration: 23.98

Any idea what is going on there? Is it just a test problem, or do we
have kernel regression that only happens sometimes?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


cip/linux-4.19.y-cip baseline: 119 runs, 3 regressions (v4.19.207-cip58) #kernelci

kernelci.org bot <bot@...>
 

cip/linux-4.19.y-cip baseline: 119 runs, 3 regressions (v4.19.207-cip58)

Regressions Summary
-------------------

platform | arch | lab | compiler | defconfig | regressions
---------------------+------+--------------+----------+---------------------+------------
qemu_arm-versatilepb | arm | lab-baylibre | gcc-8 | versatile_defconfig | 1
qemu_arm-versatilepb | arm | lab-broonie | gcc-8 | versatile_defconfig | 1
qemu_arm-versatilepb | arm | lab-cip | gcc-8 | versatile_defconfig | 1

Details: https://kernelci.org/test/job/cip/branch/linux-4.19.y-cip/kernel/v4.19.207-cip58/plan/baseline/

Test: baseline
Tree: cip
Branch: linux-4.19.y-cip
Describe: v4.19.207-cip58
URL: https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
SHA: c3737f5637179738a7e899359a490e349ee75d82


Test Regressions
----------------


platform | arch | lab | compiler | defconfig | regressions
---------------------+------+--------------+----------+---------------------+------------
qemu_arm-versatilepb | arm | lab-baylibre | gcc-8 | versatile_defconfig | 1

Details: https://kernelci.org/test/plan/id/614f3db5935b91feb199a310

Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: versatile_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//cip/linux-4.19.y-cip/v4.19.207-cip58/arm/versatile_defconfig/gcc-8/lab-baylibre/baseline-qemu_arm-versatilepb.txt
HTML log: https://storage.kernelci.org//cip/linux-4.19.y-cip/v4.19.207-cip58/arm/versatile_defconfig/gcc-8/lab-baylibre/baseline-qemu_arm-versatilepb.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b738df/armel/baseline/rootfs.cpio.gz


* baseline.login: https://kernelci.org/test/case/id/614f3db5935b91feb199a311
failing since 315 days (last pass: v4.19.152-cip37-37-g18852869b06b, first fail: v4.19.157-cip38)



platform | arch | lab | compiler | defconfig | regressions
---------------------+------+--------------+----------+---------------------+------------
qemu_arm-versatilepb | arm | lab-broonie | gcc-8 | versatile_defconfig | 1

Details: https://kernelci.org/test/plan/id/614f3ed451ee215daa99a2df

Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: versatile_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//cip/linux-4.19.y-cip/v4.19.207-cip58/arm/versatile_defconfig/gcc-8/lab-broonie/baseline-qemu_arm-versatilepb.txt
HTML log: https://storage.kernelci.org//cip/linux-4.19.y-cip/v4.19.207-cip58/arm/versatile_defconfig/gcc-8/lab-broonie/baseline-qemu_arm-versatilepb.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b738df/armel/baseline/rootfs.cpio.gz


* baseline.login: https://kernelci.org/test/case/id/614f3ed451ee215daa99a2e0
failing since 315 days (last pass: v4.19.152-cip37-37-g18852869b06b, first fail: v4.19.157-cip38)



platform | arch | lab | compiler | defconfig | regressions
---------------------+------+--------------+----------+---------------------+------------
qemu_arm-versatilepb | arm | lab-cip | gcc-8 | versatile_defconfig | 1

Details: https://kernelci.org/test/plan/id/614f3d8d3b5bbbb5e499a2e7

Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: versatile_defconfig
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//cip/linux-4.19.y-cip/v4.19.207-cip58/arm/versatile_defconfig/gcc-8/lab-cip/baseline-qemu_arm-versatilepb.txt
HTML log: https://storage.kernelci.org//cip/linux-4.19.y-cip/v4.19.207-cip58/arm/versatile_defconfig/gcc-8/lab-cip/baseline-qemu_arm-versatilepb.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b738df/armel/baseline/rootfs.cpio.gz


* baseline.login: https://kernelci.org/test/case/id/614f3d8d3b5bbbb5e499a2e8
failing since 315 days (last pass: v4.19.152-cip37-37-g18852869b06b, first fail: v4.19.157-cip38)


cip/linux-4.19.y-cip baseline-nfs: 13 runs, 1 regressions (v4.19.207-cip58) #kernelci

kernelci.org bot <bot@...>
 

cip/linux-4.19.y-cip baseline-nfs: 13 runs, 1 regressions (v4.19.207-cip58)

Regressions Summary
-------------------

platform | arch | lab | compiler | defconfig | regressions
-----------+------+---------------+----------+------------------------+------------
odroid-xu3 | arm | lab-collabora | gcc-8 | multi_v7_defconfig+ima | 1

Details: https://kernelci.org/test/job/cip/branch/linux-4.19.y-cip/kernel/v4.19.207-cip58/plan/baseline-nfs/

Test: baseline-nfs
Tree: cip
Branch: linux-4.19.y-cip
Describe: v4.19.207-cip58
URL: https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
SHA: c3737f5637179738a7e899359a490e349ee75d82


Test Regressions
----------------


platform | arch | lab | compiler | defconfig | regressions
-----------+------+---------------+----------+------------------------+------------
odroid-xu3 | arm | lab-collabora | gcc-8 | multi_v7_defconfig+ima | 1

Details: https://kernelci.org/test/plan/id/614f3df8ccab046ad899a2da

Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig+ima
Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0)
Plain log: https://storage.kernelci.org//cip/linux-4.19.y-cip/v4.19.207-cip58/arm/multi_v7_defconfig+ima/gcc-8/lab-collabora/baseline-nfs-odroid-xu3.txt
HTML log: https://storage.kernelci.org//cip/linux-4.19.y-cip/v4.19.207-cip58/arm/multi_v7_defconfig+ima/gcc-8/lab-collabora/baseline-nfs-odroid-xu3.html
Rootfs: http://storage.kernelci.org/images/rootfs/debian/buster/20210913.0/armhf/initrd.cpio.gz


* baseline-nfs.login: https://kernelci.org/test/case/id/614f3df8ccab046ad899a2db
failing since 37 days (last pass: v4.19.198-cip54, first fail: v4.19.204-cip55)


cip/linux-4.19.y-cip build: 83 builds: 0 failed, 83 passed (v4.19.207-cip58) #kernelci

kernelci.org bot <bot@...>
 

cip/linux-4.19.y-cip build: 83 builds: 0 failed, 83 passed (v4.19.207-cip58)

Full Build Summary: https://kernelci.org/build/cip/branch/linux-4.19.y-cip/kernel/v4.19.207-cip58/

Tree: cip
Branch: linux-4.19.y-cip
Git Describe: v4.19.207-cip58
Git Commit: c3737f5637179738a7e899359a490e349ee75d82
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
Built: 3 unique architectures

================================================================================

Detailed per-defconfig build reports:

--------------------------------------------------------------------------------
acs5k_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
am200epdkit_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
aspeed_g5_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
axm55xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
bcm2835_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
cerfcube_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
cip://4.19.y-cip/arm/qemu_arm_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
cip://4.19.y-cip/arm64/qemu_arm64_defconfig (arm64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
cip://4.19.y-cip/x86/cip_qemu_defconfig (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
cm_x300_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
colibri_pxa270_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
collie_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
davinci_all_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
dove_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
ebsa110_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
em_x270_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
ep93xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
gemini_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
h5000_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
hackkit_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
integrator_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
iop13xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
iop32x_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
ixp4xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
jornada720_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
lart_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
lpc32xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
lubbock_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
magician_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
mainstone_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
mini2440_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
mmp2_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
moxart_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
mps2_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
multi_v4t_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
multi_v7_defconfig+crypto (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
multi_v7_defconfig+ima (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
mxs_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
neponset_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
netwinder_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
netx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
nuc910_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
nuc950_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
omap2plus_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
orion5x_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
oxnas_v6_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
pcm027_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
pleb_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
pxa168_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
pxa3xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
pxa910_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
qcom_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
raumfeld_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
rpc_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
s3c2410_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
s3c6400_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
s5pv210_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
sama5_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
shannon_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
simpad_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
socfpga_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
spear3xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
spear6xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
spitz_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
tegra_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
trizeps4_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
u300_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
u8500_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
versatile_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
x86_64_defconfig+crypto (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
x86_64_defconfig+ima (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
xcep_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
zeus_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
zx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches

---
For more info write to <info@kernelci.org>


[ANNOUNCE] Release v4.19.207-cip58

Nobuhiro Iwamatsu
 

[ANNOUNCE] Release v4.19.207-cip58

Hi all,

CIP kernel team has released Linux kernel v4.19.207-cip58.
The linux-4.19.y-cip tree has been updated from v4.19.206 to v4.19.207.
The release information is shown below.

v4.19.207-cip58:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
c3737f5637179738a7e899359a490e349ee75d82
Fixed CVEs:
CVE-2021-34556: bpf: Introduce BPF nospec instruction for mitigating Spectre v4
CVE-2021-35477: bpf: Introduce BPF nospec instruction for mitigating Spectre v4
CVE-2020-16119: dccp: don't duplicate ccid when cloning dccp sock
CVE-2021-40490: ext4: fix race writing to an inline_data file while its xattrs are changing
added commits:
CIP: Bump version suffix to -cip58 after merge from stable

Best regards,
Nobuhiro


New CVE entry this week

Masami Ichikawa
 

Hi !

It's this week's CVE report.

This week reported 2 new CVEs.

* New CVEs

CVE-2021-41073: io_uring: ensure symmetry in handling iter types in
loop_rw_iter()

CVSS v3 score is not provided.

This CVE is affected from 5.10-rc1 to 5.15-rc2. All stable kernels are fixed.

Fixed status

mainline: [16c8d2df7ec0eed31b7d3b61cb13206a7fb930cc]
stable/5.10: [ce8f81b76d3bef7b9fe6c8f84d029ab898b19469]
stable/5.14: [71e32edd2210d0304e93ac110814b5a4b3a81dc0]

CVE-2021-3773: lack of port sanity checking in natd and netfilter
leads to exploit of OpenVPN clients

CVSS v3 score is not provided.

The details of the vulnerability has been published on
https://breakpointingbad.com/2021/09/08/Port-Shadows-via-Network-Alchemy.html
.

Fixed status

Not fixed yet.

* Updated CVEs

CVE-2020-16119: net: dccp: fix structure use-after-free

stable kernels have been fixed this week. All stable kernels are fixed.

Fixed status

mainline: [d9ea761fdd197351890418acd462c51f241014a7]
stable/4.14: [a1bb3c064bf5f2d8c3e9368a9152b1224a9dd64a]
stable/4.19: [dfec82f3e5b8bd93ab65b7417a64886ec8c42f14]
stable/4.4: [1969452d411a73a3125c326c6db0c8433f31dfd5]
stable/4.9: [40ea36ffa7207456c3f155bbab76754d3f37ce04]
stable/5.10: [6c3cb65d561e76fd0398026c023e587fec70e188]
stable/5.14: [51f7b364a2d120cea956b2bb5ccaad29bbf8abce]
stable/5.4: [5ab04a4ffed02f66e8e6310ba8261a43d1572343]

CVE-2020-3702: Specifically timed and handcrafted traffic can cause
internal errors in a WLAN device that lead to improper layer 2 Wi-Fi
encryption with a consequent possibility of information disclosure
over the air for a discrete set of traffic

stable kernel 4.4 and 4.9 have been fixed this week. This
vulnerability has been fixed since 5.12-rc1-dontuse.
All stable kernels are fixed.

Fixed status

mainline: [56c5485c9e444c2e85e11694b6c44f1338fc20fd,
73488cb2fa3bb1ef9f6cf0d757f76958bd4deaca,
d2d3e36498dd8e0c83ea99861fac5cf9e8671226,
144cd24dbc36650a51f7fe3bf1424a1432f1f480,
ca2848022c12789685d3fab3227df02b863f9696]
stable/4.14: [2cbb22fd4b4fb4d0822d185bf5bd6d027107bfda,
20e7de09cbdb76a38f28fb71709fae347123ddb7,
995586a56748c532850870523d3a9080492b3433,
f4d4f4473129e9ee55b8562250adc53217bad529,
61b014a8f8de02bedc56f76620170437f5638588]
stable/4.19: [dd5815f023b89c9a28325d8a2a5f0779b57b7190,
d2fd9d34210f34cd0ff5b33fa94e9fcc2a513cea,
fb924bfcecc90ca63ca76b5a10f192bd0e1bb35d,
7c5a966edd3c6eec4a9bdf698c1f27712d1781f0,
08c613a2cb06c68ef4e7733e052af067b21e5dbb]
stable/4.4: [4d6b4335838fd89419212e1e486c415ec36fb610,
5d97f20dc21f3f4b14105590f729e513b0c4921d,
85d371eb7259c2e6aecd0b77c3f8c193c9593624,
1c8e25862a00a539803fa60eb7a907143688b178,
3fd07178fbf012db0b38488ea2e0069412250dd2]
stable/4.9: [ea3f7df20fc8e0b82ec0e065b0b0d38e55fd7775,
74adc24d162e67d8862edaf701de620f36f98215,
d7d4c3c60342deba706fd76ef09d8af68b9a64d8,
13c51682b07a5db4d9efb514e700407c6da22ff9,
7afed8faf42d8358a165ba554891085e10b1f7a0]
stable/5.10: [8f05076983ddeaae1165457b6aa4eca9fe0e5498,
6566c207e5767deb37d283ed9f77b98439a1de4e,
2925a8385ec746bf09c11dcadb9af13c26091a4d,
609c0cfd07f0ae6c444e064a59b46c5f3090b705,
e2036bc3fc7daa03c15fda27e1818192da817cea]
stable/5.4: [0c049ce432b37a51a0da005314ac32e5d9324ccf,
add283e2517a90468ce223465e0f4360128bb650,
b7d593705eb4f0655a70f0207f573fb1edb80bda,
c6feaf806da6a0deecc2fe41adb3443cdecba347,
23f77ad13f8176314b7c51f71b9ac7c5c6d10b7b]

CVE-2021-40490: ext4: fix race writing to an inline_data file while
its xattrs are changing

4.4, 4.9, 4.14, and 4.19 kernels have been fixed this week. All stable
kernels are fixed.

Fixed status

mainline: [a54c4613dac1500b40e4ab55199f7c51f028e848]
stable/4.14: [9569234645f102025aaf0fc83d3dcbf1b8cbf2dc]
stable/4.19: [c481607ba522e31e6ed01efefc19cc1d0e0a46fa]
stable/4.4: [69d82df68fbc5e368820123200d7b88f6c058350]
stable/4.9: [7067b09fe587cbd47544a3047a40c64e4d636fff]
stable/5.10: [09a379549620f122de3aa4e65df9329976e4cdf5]
stable/5.13: [c764e8fa4491da66780fcb30a0d43bfd3fccd12c]
stable/5.14: [f8ea208b3fbbc0546d71b47e8abaf98b0961dec1]
stable/5.4: [9b3849ba667af99ee99a7853a021a7786851b9fd]

Currently tracking CVEs

CVE-2021-31615: Unencrypted Bluetooth Low Energy baseband links in
Bluetooth Core Specifications 4.0 through 5.2

There is no fix information.

CVE-2021-3640: UAF in sco_send_frame function

There is no fix information.

CVE-2020-26555: BR/EDR pin code pairing broken

No fix information

CVE-2020-26556: kernel: malleable commitment Bluetooth Mesh Provisioning

No fix information.

CVE-2020-26557: kernel: predictable Authvalue in Bluetooth Mesh
Provisioning Leads to MITM

No fix information.

CVE-2020-26559: kernel: Authvalue leak in Bluetooth Mesh Provisioning

No fix information.

CVE-2020-26560: kernel: impersonation attack in Bluetooth Mesh Provisioning

No fix information.


Regards,

--
Masami Ichikawa
Cybertrust Japan Co., Ltd.

Email :masami.ichikawa@cybertrust.co.jp
:masami.ichikawa@miraclelinux.com


CIP IRC weekly meeting today on libera.chat (2021/09/23)

Nobuhiro Iwamatsu
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss
technical topics with CIP kernel today.

Please note that we moved from Freenode to libera.chat. Our channel is
the following:

irc:irc.libera.chat:6667/cip

Furthermore note that the IRC meeting is now scheduled to UTC (GMT) 13:00:

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=9&day=16&hour=13&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
06:00 09:00 14:00 15:00 21:00 22:00

Last meeting minutes:

https://irclogs.baserock.org/meetings/cip/2021/09/cip.2021-09-16-13.01.txt

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu & alicef
2. Document new LAVA domains in wiki - patersonc

* Kernel maintenance updates
* Kernel testing
* AOB

Best regards,
Nobuhiro


Re: CIP IRC weekly meeting today on libera.chat

Chris Paterson
 

Hello Jan, all,

From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On
Behalf Of Jan Kiszka via lists.cip-project.org
Sent: 16 September 2021 07:11

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss
technical topics with CIP kernel today.
There is a chance that I may not make it today. Just in case I've added some notes below.


Please note that we moved from Freenode to libera.chat. Our channel is
the following:

irc:irc.libera.chat:6667/cip

Furthermore note that the IRC meeting is now scheduled to UTC (GMT)
13:00:

https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.timeanddate.com%2Fworldclock%2Fmeetingdetails.html%3Fyear%3D2021%
26month%3D9%26day%3D16%26hour%3D13%26min%3D0%26sec%3D0%26p
1%3D224%26p2%3D179%26p3%3D136%26p4%3D37%26p5%3D241%26p6%3D
248&amp;data=04%7C01%7Cchris.paterson2%40renesas.com%7C7f495232a8
5c44b56ea208d978d8ca45%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C
0%7C637673694777997101%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;
sdata=jITtPWySL7jFizH7hwZkcwtG90KbqftA70TEkBYMCEc%3D&amp;reserve
d=0

USWest USEast UK DE TW JP
06:00 09:00 14:00 15:00 21:00 22:00

Last meeting minutes:

https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Firclog
s.baserock.org%2Fmeetings%2Fcip%2F2021%2F09%2Fcip.2021-09-09-
13.02.log.txt&amp;data=04%7C01%7Cchris.paterson2%40renesas.com%7C7f
495232a85c44b56ea208d978d8ca45%7C53d82571da1947e49cb4625a166a4a2a
%7C0%7C0%7C637673694777997101%7CUnknown%7CTWFpbGZsb3d8eyJWIj
oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
000&amp;sdata=zkeyEhzTKsDWpLFE59PjV9AjBn15GHu%2Fujcy0YxpfeE%3D
&amp;reserved=0

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu & alicef
2. Document new LAVA domains in wiki - patersonc
No updates.


* Kernel maintenance updates
* Kernel testing
I don't have much to update since the TSC on Tuesday.

Kind regards, Chris

* AOB

Jan

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

301 - 320 of 7061