Date   

Re: [isar-cip-dev][PATCH 2/2] swupdate: Add option to use swupdate-handler-roundrobin

Jan Kiszka
 

On 11.06.21 16:30, Jan Kiszka wrote:
On 11.06.21 16:21, Q. Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

The new SWUpdate round-robin handler is available under[1].
Add the Option `SWUPDATE_HANDLER_BOOT_HANDLER_CONFIG` to
set the source of the swupdate-handler-roundrobin configuration.

If another Lua handler should be used, set the variable
`SWUPDATE_USE_ROUND_ROBIN_HANDLER_REPO` to `0`. Add the alternative
handler to the repository and use the variable
`SWUPDATE_LUASCRIPT` to add the handler to the build.

[1]:https://gitlab.com/cip-playground/swupdate-handler-roundrobin/
What's still missing to get the script repo out of its playground? I
would obviously prefer already referencing the final URL if that is in
sight (I know there will be forwarding as well).
FYI: Handler repo has been moved to

https://gitlab.com/cip-project/cip-sw-updates/swupdate-handler-roundrobin.

Jan

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


Re: [isar-cip-dev][PATCH] linux-cip-common.inc: Uprev the cip-kernel-config

Jan Kiszka
 

On 14.06.21 09:36, Srinuvasan A wrote:
From: Srinuvasan A <srinuvasan_a@mentor.com>

Bump the cip-kernel-config revision for brings the Message Queue
support.

Signed-off-by: Srinuvasan A <srinuvasan_a@mentor.com>
---
recipes-kernel/linux/linux-cip-common.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-cip-common.inc b/recipes-kernel/linux/linux-cip-common.inc
index 464144c..021efcd 100644
--- a/recipes-kernel/linux/linux-cip-common.inc
+++ b/recipes-kernel/linux/linux-cip-common.inc
@@ -25,6 +25,6 @@ SRC_URI_append = " ${@ "git://gitlab.com/cip-project/cip-kernel/cip-kernel-confi

SRC_URI_append_bbb = "file://${KERNEL_DEFCONFIG}"

-SRCREV_cip-kernel-config ?= "f6ca8092aeafe22463bcaca17f26c284b15038d0"
+SRCREV_cip-kernel-config ?= "9fa9154c77ee8eeca534aa436c23582c0c59c39f"

S = "${WORKDIR}/linux-cip-v${PV}"


Thanks, applied.

Jan

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


[isar-cip-core][PATCH] efibootguard: Set a non-zero default timeout

Jan Kiszka
 

From: Jan Kiszka <jan.kiszka@siemens.com>

This was zero by default because of problems with the iTCO support for
QEMU. Those are fixed now with v0.8.

Also permit overriding WDOG_TIMEOUT from now on.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
kas/opt/efibootguard.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kas/opt/efibootguard.yml b/kas/opt/efibootguard.yml
index d5a0e39..705a76d 100644
--- a/kas/opt/efibootguard.yml
+++ b/kas/opt/efibootguard.yml
@@ -21,7 +21,7 @@ local_conf_header:
SWUPDATE_BOOTLOADER = "efibootguard"

efibootguard-wic: |
- WDOG_TIMEOUT = "0"
+ WDOG_TIMEOUT ?= "60"
WICVARS += "WDOG_TIMEOUT"
IMAGE_TYPE ?= "wic-img"
WKS_FILE ?= "${MACHINE}-${SWUPDATE_BOOTLOADER}.wks"
--
2.26.2


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


Re: [isar-cip-dev][PATCH] efibootguard: Update to latest release 0.8

Jan Kiszka
 

On 14.06.21 09:14, Srinuvasan A wrote:
From: Srinuvasan A <srinuvasan_a@mentor.com>

Uprevision the latest revision and tag.

Signed-off-by: Srinuvasan A <srinuvasan_a@mentor.com>
---
...fibootguard_0.7-git+isar.bb => efibootguard_0.8-git+isar.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename recipes-bsp/efibootguard/{efibootguard_0.7-git+isar.bb => efibootguard_0.8-git+isar.bb} (95%)

diff --git a/recipes-bsp/efibootguard/efibootguard_0.7-git+isar.bb b/recipes-bsp/efibootguard/efibootguard_0.8-git+isar.bb
similarity index 95%
rename from recipes-bsp/efibootguard/efibootguard_0.7-git+isar.bb
rename to recipes-bsp/efibootguard/efibootguard_0.8-git+isar.bb
index 4bdf76a..ebd848d 100644
--- a/recipes-bsp/efibootguard/efibootguard_0.7-git+isar.bb
+++ b/recipes-bsp/efibootguard/efibootguard_0.8-git+isar.bb
@@ -22,7 +22,7 @@ SRC_URI = "git://github.com/siemens/efibootguard.git;branch=master;protocol=http

S = "${WORKDIR}/git"

-SRCREV = "442e87bafb480ada2b9074f02350a30408d4cf9c"
+SRCREV = "ac1685aea75fb3e3d16c0c0e4f8261a2edb63536"

PROVIDES = "${PN}"
PROVIDES += "${PN}-dev"

Thanks, applied.

Jan

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


[isar-cip-dev][PATCH] linux-cip-common.inc: Uprev the cip-kernel-config

Srinuvasan A
 

From: Srinuvasan A <srinuvasan_a@mentor.com>

Bump the cip-kernel-config revision for brings the Message Queue
support.

Signed-off-by: Srinuvasan A <srinuvasan_a@mentor.com>
---
recipes-kernel/linux/linux-cip-common.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-cip-common.inc b/recipes-kernel/linux/linux-cip-common.inc
index 464144c..021efcd 100644
--- a/recipes-kernel/linux/linux-cip-common.inc
+++ b/recipes-kernel/linux/linux-cip-common.inc
@@ -25,6 +25,6 @@ SRC_URI_append = " ${@ "git://gitlab.com/cip-project/cip-kernel/cip-kernel-confi

SRC_URI_append_bbb = "file://${KERNEL_DEFCONFIG}"

-SRCREV_cip-kernel-config ?= "f6ca8092aeafe22463bcaca17f26c284b15038d0"
+SRCREV_cip-kernel-config ?= "9fa9154c77ee8eeca534aa436c23582c0c59c39f"

S = "${WORKDIR}/linux-cip-v${PV}"
--
2.25.1


[isar-cip-dev][PATCH] efibootguard: Update to latest release 0.8

Srinuvasan A
 

From: Srinuvasan A <srinuvasan_a@mentor.com>

Uprevision the latest revision and tag.

Signed-off-by: Srinuvasan A <srinuvasan_a@mentor.com>
---
...fibootguard_0.7-git+isar.bb => efibootguard_0.8-git+isar.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename recipes-bsp/efibootguard/{efibootguard_0.7-git+isar.bb => efibootguard_0.8-git+isar.bb} (95%)

diff --git a/recipes-bsp/efibootguard/efibootguard_0.7-git+isar.bb b/recipes-bsp/efibootguard/efibootguard_0.8-git+isar.bb
similarity index 95%
rename from recipes-bsp/efibootguard/efibootguard_0.7-git+isar.bb
rename to recipes-bsp/efibootguard/efibootguard_0.8-git+isar.bb
index 4bdf76a..ebd848d 100644
--- a/recipes-bsp/efibootguard/efibootguard_0.7-git+isar.bb
+++ b/recipes-bsp/efibootguard/efibootguard_0.8-git+isar.bb
@@ -22,7 +22,7 @@ SRC_URI = "git://github.com/siemens/efibootguard.git;branch=master;protocol=http

S = "${WORKDIR}/git"

-SRCREV = "442e87bafb480ada2b9074f02350a30408d4cf9c"
+SRCREV = "ac1685aea75fb3e3d16c0c0e4f8261a2edb63536"

PROVIDES = "${PN}"
PROVIDES += "${PN}-dev"
--
2.25.1


Re: BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809

Pavel Machek
 

Hi!

I notice you are using -rt kernel. Do you actually need realtime
features?
Yes, I actually need the realtime feature. I have one task which
needs to run periodically in realtime (triggered every 10ms by an
external IRQ).
How fast response do you need to the external IRQ?

Can you try to reproduce the problem on 4.19.193?
This is only a problem with the realtime patch. The patch
introduces migrate_enable which is part of the callstack:

Jun 1 09:11:46 sicam kernel: [46802.944165] BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809
Jun 1 09:11:46 sicam kernel: [46802.944210] caller is
migrate_enable+0x40/0x488
Fun :-(. As Jan mentioned, testing if it can be reproduced with
4.19.193-rt81 would be useful.

Best regards,
Pavel

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


Re: [isar-cip-dev][PATCH 2/2] swupdate: Add option to use swupdate-handler-roundrobin

Jan Kiszka
 

On 11.06.21 16:21, Q. Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

The new SWUpdate round-robin handler is available under[1].
Add the Option `SWUPDATE_HANDLER_BOOT_HANDLER_CONFIG` to
set the source of the swupdate-handler-roundrobin configuration.

If another Lua handler should be used, set the variable
`SWUPDATE_USE_ROUND_ROBIN_HANDLER_REPO` to `0`. Add the alternative
handler to the repository and use the variable
`SWUPDATE_LUASCRIPT` to add the handler to the build.

[1]:https://gitlab.com/cip-playground/swupdate-handler-roundrobin/
What's still missing to get the script repo out of its playground? I
would obviously prefer already referencing the final URL if that is in
sight (I know there will be forwarding as well).

Jan

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


[isar-cip-dev][PATCH 2/2] swupdate: Add option to use swupdate-handler-roundrobin

Quirin Gylstorff
 

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

The new SWUpdate round-robin handler is available under[1].
Add the Option `SWUPDATE_HANDLER_BOOT_HANDLER_CONFIG` to
set the source of the swupdate-handler-roundrobin configuration.

If another Lua handler should be used, set the variable
`SWUPDATE_USE_ROUND_ROBIN_HANDLER_REPO` to `0`. Add the alternative
handler to the repository and use the variable
`SWUPDATE_LUASCRIPT` to add the handler to the build.

[1]:https://gitlab.com/cip-playground/swupdate-handler-roundrobin/

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
classes/swupdate-config.bbclass | 14 +-
kas/opt/ebg-secure-boot-base.yml | 1 +
.../files/secure-boot/sw-description.tmpl | 14 +-
recipes-core/images/files/sw-description.tmpl | 21 +-
.../swupdate.handler.efibootguard.ini | 20 +
.../files/swupdate.handler.efibootguard.ini | 26 +
.../swupdate/files/swupdate_handlers.lua | 453 ------------------
recipes-core/swupdate/swupdate.bb | 14 +-
8 files changed, 95 insertions(+), 468 deletions(-)
create mode 100644 recipes-core/swupdate/files/secureboot/swupdate.handler.efibootguard.ini
create mode 100644 recipes-core/swupdate/files/swupdate.handler.efibootguard.ini
delete mode 100644 recipes-core/swupdate/files/swupdate_handlers.lua

diff --git a/classes/swupdate-config.bbclass b/classes/swupdate-config.bbclass
index f67ca4f..f94fd82 100644
--- a/classes/swupdate-config.bbclass
+++ b/classes/swupdate-config.bbclass
@@ -17,14 +17,22 @@ BUILD_DEB_DEPENDS = " \
zlib1g-dev, debhelper, libconfig-dev, libarchive-dev, \
python-sphinx:native, dh-systemd, libsystemd-dev, libssl-dev, pkg-config"

+SRC_URI += " ${@ 'git://gitlab.com/cip-playground/swupdate-handler-roundrobin.git;protocol=https;destsuffix=swupdate-handler-roundrobin;name=swupdate-handler-roundrobin;nobranch=1' \
+ if d.getVar('SWUPDATE_USE_ROUND_ROBIN_HANDLER_REPO') == '1' else '' \
+ }"
+SRCREV_swupdate-handler-roundrobin ?= "6f561f136fdbe51d2e9066b934dfcb06b94c6624"
+
+SWUPDATE_USE_ROUND_ROBIN_HANDLER_REPO ?= "1"
+SWUPDATE_LUASCRIPT ?= "swupdate-handler-roundrobin/swupdate_handlers_roundrobin.lua"
+
KFEATURE_lua = ""
KFEATURE_lua[BUILD_DEB_DEPENDS] = "liblua5.3-dev"
KFEATURE_lua[KCONFIG_SNIPPETS] = "file://swupdate_defconfig_lua.snippet"

KFEATURE_luahandler = ""
KFEATURE_luahandler[KCONFIG_SNIPPETS] = "file://swupdate_defconfig_luahandler.snippet"
-KFEATURE_luahandler[SRC_URI] = "file://${SWUPDATE_LUASCRIPT}"
-
+KFEATURE_luahandler[SRC_URI] = "${@ 'file://${SWUPDATE_LUASCRIPT}' \
+ if d.getVar('SWUPDATE_USE_ROUND_ROBIN_HANDLER_REPO') == '0' else '' }"
KFEATURE_DEPS = ""
KFEATURE_DEPS[luahandler] = "lua"

@@ -59,8 +67,6 @@ KFEATURE_u-boot[DEPENDS] = "${@ 'libubootenv u-boot-${MACHINE}-config' \
else 'libubootenv'}"
KFEATURE_u-boot[KCONFIG_SNIPPETS] = "file://swupdate_defconfig_u-boot.snippet"

-SWUPDATE_LUASCRIPT ?= "swupdate_handlers.lua"
-
def get_bootloader_featureset(d):
bootloader = d.getVar("SWUPDATE_BOOTLOADER", True) or ""
if bootloader == "efibootguard":
diff --git a/kas/opt/ebg-secure-boot-base.yml b/kas/opt/ebg-secure-boot-base.yml
index 35fb42e..8182bd8 100644
--- a/kas/opt/ebg-secure-boot-base.yml
+++ b/kas/opt/ebg-secure-boot-base.yml
@@ -18,3 +18,4 @@ local_conf_header:
initramfs: |
IMAGE_INSTALL += "initramfs-abrootfs-secureboot"
SWU_DESCRIPTION = "secureboot"
+ SWUPDATE_ROUND_ROBIN_HANDLER_CONFIG = "secureboot/swupdate.handler.${SWUPDATE_BOOTLOADER}.ini"
diff --git a/recipes-core/images/files/secure-boot/sw-description.tmpl b/recipes-core/images/files/secure-boot/sw-description.tmpl
index bce97d0..34a58a3 100644
--- a/recipes-core/images/files/secure-boot/sw-description.tmpl
+++ b/recipes-core/images/files/secure-boot/sw-description.tmpl
@@ -14,16 +14,22 @@ software =
name = "secure boot update"
images: ({
filename = "${ROOTFS_PARTITION_NAME}";
- device = "fedcba98-7654-3210-cafe-5e0710000001,fedcba98-7654-3210-cafe-5e0710000002";
+ device = "sda4,sda5";
type = "roundrobin";
- compressed = "true";
+ compressed = "zlib";
filesystem = "ext4";
+ properties: {
+ subtype = "image";
+ };
});
files: ({
filename = "linux.signed.efi";
path = "linux.signed.efi";
- type = "kernelfile";
- device = "sda2,sda3";
+ type = "roundrobin";
+ device = "sda4->sda2,sda5->sda3";
filesystem = "vfat";
+ properties: {
+ subtype = "kernel";
+ };
})
}
diff --git a/recipes-core/images/files/sw-description.tmpl b/recipes-core/images/files/sw-description.tmpl
index bb34088..3309271 100644
--- a/recipes-core/images/files/sw-description.tmpl
+++ b/recipes-core/images/files/sw-description.tmpl
@@ -16,21 +16,30 @@ software =
filename = "${ROOTFS_PARTITION_NAME}";
device = "fedcba98-7654-3210-cafe-5e0710000001,fedcba98-7654-3210-cafe-5e0710000002";
type = "roundrobin";
- compressed = "true";
+ compressed = "zlib";
filesystem = "ext4";
+ properties: {
+ subtype = "image";
+ };
});
files: ({
filename = "${KERNEL_IMAGE}";
path = "vmlinuz";
- type = "kernelfile";
- device = "sda2,sda3";
+ type = "roundrobin";
+ device = "fedcba98-7654-3210-cafe-5e0710000001->sda2,fedcba98-7654-3210-cafe-5e0710000002->sda3";
filesystem = "vfat";
+ properties: {
+ subtype = "kernel";
+ };
},
{
filename = "${INITRD_IMAGE}";
- path = "initrd.img";
- type = "kernelfile";
- device = "sda2,sda3";
+ path = "${INITRD_IMAGE}";
+ type = "roundrobin";
+ device = "fedcba98-7654-3210-cafe-5e0710000001->sda2,fedcba98-7654-3210-cafe-5e0710000002->sda3";
filesystem = "vfat";
+ properties: {
+ subtype = "initrd";
+ };
});
}
diff --git a/recipes-core/swupdate/files/secureboot/swupdate.handler.efibootguard.ini b/recipes-core/swupdate/files/secureboot/swupdate.handler.efibootguard.ini
new file mode 100644
index 0000000..be69b60
--- /dev/null
+++ b/recipes-core/swupdate/files/secureboot/swupdate.handler.efibootguard.ini
@@ -0,0 +1,20 @@
+[image]
+chainhandler=raw
+
+[image.selector]
+method=getroot_rr
+key=root
+
+[image.bootenv]
+ustate=1
+
+[kernel]
+chainhandler=rawfile
+
+[kernel.selector]
+method=getroot_rrmap
+key=root
+
+[kernel.bootenv]
+kernelfile=C:BOOT${rrindex}:linux.signed.efi
+
diff --git a/recipes-core/swupdate/files/swupdate.handler.efibootguard.ini b/recipes-core/swupdate/files/swupdate.handler.efibootguard.ini
new file mode 100644
index 0000000..3aee76c
--- /dev/null
+++ b/recipes-core/swupdate/files/swupdate.handler.efibootguard.ini
@@ -0,0 +1,26 @@
+[image]
+chainhandler=raw
+
+[image.selector]
+method=cmdline_rr
+key=root
+
+[image.bootenv]
+kernelparams=root=PARTUUID=${rrtarget} ${cmdline_root}
+
+[kernel]
+chainhandler=rawfile
+
+[kernel.selector]
+method=cmdline_rrmap
+key=root
+
+[kernel.bootenv]
+kernelfile=C:BOOT${rrindex}:vmlinuz
+
+[initrd]
+chainhandler=rawfile
+
+[initrd.selector]
+method=cmdline_rrmap
+key=root
diff --git a/recipes-core/swupdate/files/swupdate_handlers.lua b/recipes-core/swupdate/files/swupdate_handlers.lua
deleted file mode 100644
index f2ecc54..0000000
--- a/recipes-core/swupdate/files/swupdate_handlers.lua
+++ /dev/null
@@ -1,453 +0,0 @@
---[[
-
- Round-robin Image and File Handler.
-
- Copyright (C) 2019, Siemens AG
-
- Author: Christian Storm <christian.storm@siemens.com>
-
- SPDX-License-Identifier: GPL-2.0-or-later
-
- An `sw-description` file using these handlers may look like:
- software =
- {
- version = "0.1.0";
- images: ({
- filename = "rootfs.ext4";
- device = "sda4,sda5";
- type = "roundrobin";
- compressed = false;
- });
- files: ({
- filename = "vmlinuz";
- path = "vmlinuz";
- type = "kernelfile";
- device = "sda2,sda3";
- filesystem = "vfat";
- },
- {
- filename = "initrd.img";
- path = "initrd.img";
- type = "kernelfile";
- device = "sda2,sda3";
- filesystem = "vfat";
- });
- }
-
- The semantics is as follows: Instead of having a fixed target device,
- the 'roundrobin' image handler calculates the target device by parsing
- /proc/cmdline, matching the root=<device> kernel parameter against its
- 'device' attribute's list of devices, and sets the actual target
- device to the next 'device' attribute list entry in a round-robin
- manner. The actual flashing is done via chain-calling another handler,
- defaulting to the "raw" handler.
-
- The 'kernelfile' file handler reuses the 'roundrobin' handler's target
- device calculation by reading the actual target device from the same
- index into its 'device' attribute's list of devices. The actual placing
- of files into this partition is done via chain-calling another handler,
- defaulting to the "rawfile" handler.
-
- In the above example, if /dev/sda4 is currently booted according to
- /proc/cmdline, /dev/sda5 will be flashed and the vmlinuz and initrd.img
- files will be placed on /dev/sda3. If /dev/sda5 is booted, /dev/sda4
- will be flashed and the vmlinuz and initrd.img files are placed on
- /dev/sda2.
- In addition to "classical" device nodes as in this example, partition
- UUIDs as reported, e.g., by `blkid -s PARTUUID` are also supported.
- UBI volumes are supported as well by specifying a CSV list of
- ubi<number>:<label> items.
-
- Configuration is done via an INI-style configuration file located at
- /etc/swupdate.handler.ini or via compiled-in configuration (by
- embedding the Lua handler script into the SWUpdate binary via using
- CONFIG_EMBEDDED_LUA_HANDLER), the latter having precedence over the
- former. See the example configuration below.
- If uncommenting this example block, it will take precedence over any
- /etc/swupdate.handler.ini configuration file.
-
- The chain-called handlers can either be specified in the configuration,
- i.e., a static run-time setting, or via the 'chainhandler' property of
- an 'image' or 'file' section in the sw-description, with the latter
- taking precedence over the former, e.g.,
- ...
- images: ({
- filename = "rootfs.ext4";
- device = "sda4,sda5";
- type = "roundrobin";
- properties: {
- chainhandler = "myraw";
- };
- });
- ...
- Such a sw-description fragment will chain-call the imaginary "myraw"
- handler regardless of what's been configured in the compiled-in or the
- configuration file.
- When chain-calling the "rdiff_image" handler, its 'rdiffbase' property
- is subject to round-robin as well, i.e., the 'rdiffbase' property is
- expected to be a CSV list as for the 'device' property, and the actual
- 'rdiffbase' property value is calculated following the same round-robin
- calculation mechanism stated above prior to chain-calling the actual
- "rdiff_image" handler, e.g.,
- images: ({
- filename = "rootfs.ext4";
- type = "roundrobin";
- device = "sda4,sda5";
- properties: {
- chainhandler = "rdiff_image";
- rdiffbase="sda1,sda2";
- };
- });
- will set the 'rdiffbase' property to /dev/sda2 (/dev/sda1) if /dev/sda4
- (/dev/sda5) is the currently booted root file system according to
- /proc/cmdline parsing.
-
-]]
-
-
-local configuration = [[
-[bootloader]
-# Required: bootloader name, uboot and ebg currently supported.
-name=ebg
-# Required: bootloader-specific key-value pairs, e.g., for ebg:
-kernelname=linux.signed.efi
-# For relying on FAT labels, prefix bootlabels with 'L:', e.g., L:BOOT0.
-# For using custom labels, i.e., relying on the contents of an EFILABEL
-# file within the partition, prefix it with 'C:', e.g., C:BOOT0.
-bootlabel={ "C:BOOT0:", "C:BOOT1:" }
-
-# Optional: handler to chain-call for the 'roundrobin' handler,
-# defaulting to 'raw'
-[roundrobin]
-chainhandler=raw
-
-# Optional: handler to chain-call for the 'kernelfile' handler,
-# defaulting to 'rawfile'
-[kernelfile]
-chainhandler=rawfile
-]]
-
--- Default configuration file, tried if no compiled-in config is available.
-local cfgfile = "/etc/swupdate.handler.ini"
-
--- Table holding the configuration.
-local config = {}
-
--- Mandatory configuration [section] and keys
-local BOOTLOADERCFG = {
- ebg = {
- bootloader = {"name", "bootlabel", "kernelname"}
- },
- -- TODO fill with mandatory U-Boot configuration
- uboot = {
- bootloader = {"name"}
- }
-}
-
--- enum-alikes to make code more readable
-local BOOTLOADER = { EBG = "ebg", UBOOT = "uboot" }
-local PARTTYPE = { UUID = 1, PLAIN = 2, UBI = 3 }
-
--- Target table describing the target device the image is to be/has been flashed to.
-local rrtarget = {
- size = function(self)
- local _size = 0
- for index in pairs(self) do _size = _size + 1 end
- return _size - 1
- end
-}
-
--- Helper function parsing CSV fields of a struct img_type such as
--- the "device" fields or the "rdiffbase" property.
-local get_device_list = function(device_node_csv_list)
- local device_list = {}
- for item in device_node_csv_list:gmatch("([^,]+)") do
- local device_node = item:gsub("/dev/", "")
- device_list[#device_list+1] = device_node
- device_list[device_node] = #device_list
- end
- return device_list
-end
-
--- Helper function to determine device node location.
-local get_device_path = function(device_node)
- if device_node:match("ubi%d+:%S+") then
- return 0, device_node, PARTTYPE.UBI
- end
- local device_path = string.format("/dev/disk/by-partuuid/%s", device_node)
- local file = io.open(device_path, "rb" )
- if file then
- file:close()
- return 0, device_path, PARTTYPE.UUID
- end
- device_path = string.format("/dev/%s", device_node)
- file = io.open(device_path, "rb" )
- if file then
- file:close()
- return 0, device_path, PARTTYPE.PLAIN
- end
- swupdate.error(string.format("Cannot access target device node /dev/{,disk/by-partuuid}/%s", device_node))
- return 1, nil, nil
-end
-
--- Helper function parsing the INI-style configuration.
-local get_config = function()
- -- Return configuration right away if it's already parsed.
- if config ~= nil and #config > 0 then
- return config
- end
-
- -- Get configuration INI-style string.
- if not configuration then
- swupdate.trace(string.format("No compiled-in config found, trying %s", cfgfile))
- local file = io.open(cfgfile, "r" )
- if not file then
- swupdate.error(string.format("Cannot open config file %s", cfgfile))
- return nil
- end
- configuration = file:read("*a")
- file:close()
- end
- if configuration:sub(-1) ~= "\n" then
- configuration=configuration.."\n"
- end
-
- -- Parse INI-style contents into config table.
- local sec, key, value
- for line in configuration:gmatch("(.-)\n") do
- if line:match("^%[([%w%p]+)%][%s]*") then
- sec = line:match("^%[([%w%p]+)%][%s]*")
- config[sec] = {}
- elseif sec then
- key, value = line:match("^([%w%p]-)=(.*)$")
- if key and value then
- if tonumber(value) then value = tonumber(value) end
- if value == "true" then value = true end
- if value == "false" then value = false end
- if value:sub(1,1) == "{" then
- local _value = {}
- for _key, _ in value:gmatch("\"(%S+)\"") do
- table.insert(_value, _key)
- end
- value = _value
- end
- config[sec][key] = value
- else
- if not line:match("^$") and not line:match("^#") then
- swupdate.warn(string.format("Syntax error, skipping '%s'", line))
- end
- end
- else
- swupdate.error(string.format("Syntax error. no [section] encountered."))
- return nil
- end
- end
-
- -- Check config table for mandatory key existence.
- if config["bootloader"] == nil or config["bootloader"]["name"] == nil then
- swupdate.error(string.format("Syntax error. no [bootloader] encountered or name= missing therein."))
- return nil
- end
- local bcfg = BOOTLOADERCFG[config.bootloader.name]
- if not bcfg then
- swupdate.error(string.format("Bootloader unsupported, name=uboot|ebg missing in [bootloader]?."))
- return nil
- end
- for sec, _ in pairs(bcfg) do
- for _, key in pairs(bcfg[sec]) do
- if config[sec] == nil or config[sec][key] == nil then
- swupdate.error(string.format("Mandatory config key %s= in [%s] not found.", key, sec))
- end
- end
- end
-
- return config
-end
-
--- Round-robin image handler for updating the root partition.
-function handler_roundrobin(image)
- -- Read configuration.
- if not get_config() then
- swupdate.error("Cannot read configuration.")
- return 1
- end
-
- -- Check if we can chain-call the handler.
- local chained_handler = "raw"
- if image.properties ~= nil and image.properties["chainhandler"] ~= nil then
- chained_handler = image.properties["chainhandler"]
- elseif config["roundrobin"] ~= nil and config["roundrobin"]["chainhandler"] ~= nil then
- chained_handler = config["roundrobin"]["chainhandler"]
- end
- if not swupdate.handler[chained_handler] then
- swupdate.error(string.format("'%s' handler not available in SWUpdate distribution.", chained_handler))
- return 1
- end
-
- -- Get device list for round-robin.
- local devices = get_device_list(image.device)
- if #devices < 2 then
- swupdate.error("Specify at least 2 devices in the device= property for 'roundrobin'.")
- return 1
- end
-
- -- Check that rrtarget is unset, else a reboot may be pending.
- if rrtarget:size() > 0 then
- swupdate.warn("The 'roundrobin' handler has been run. Is a reboot pending?")
- end
-
- -- Determine current root device.
- local file = io.open("/proc/cmdline", "r")
- if not file then
- swupdate.error("Cannot open /proc/cmdline.")
- return 1
- end
- local cmdline = file:read("*l")
- file:close()
-
- local rootparam, rootdevice
- for item in cmdline:gmatch("%S+") do
- rootparam, rootdevice = item:match("(root=[%u=]*[/dev/]*(%S+))")
- if rootparam and rootdevice then break end
- end
- if not rootdevice then
- -- Use findmnt to get the rootdev
- rootdevice = io.popen('findmnt -nl / -o PARTUUID'):read("*l")
- if not rootdevice then
- swupdate.error("Cannot determine current root device.")
- return 1
- end
- end
- swupdate.info(string.format("Current root device is: %s", rootdevice))
-
- if not devices[rootdevice] then
- swupdate.error(string.format("Current root device '%s' is not in round-robin root devices list: %s", rootdevice, image.device:gsub("/dev/", "")))
- return 1
- end
-
- -- Perform round-robin calculation for target.
- local err
- rrtarget.index = devices[rootdevice] % #devices + 1
- rrtarget.device_node = devices[rrtarget.index]
- err, rrtarget.device_path, rrtarget.parttype = get_device_path(devices[rrtarget.index])
- if err ~= 0 then
- return 1
- end
- swupdate.info(string.format("Using '%s' as 'roundrobin' target via '%s' handler.", rrtarget.device_path, chained_handler))
-
- -- If the chain-called handler is rdiff_image, adapt the rdiffbase property
- if chained_handler == "rdiff_image" then
- if image.properties ~= nil and image.properties["rdiffbase"] ~= nil then
- local rdiffbase_devices = get_device_list(image.properties["rdiffbase"])
- if #rdiffbase_devices < 2 then
- swupdate.error("Specify at least 2 devices in the rdiffbase= property for 'roundrobin'.")
- return 1
- end
- err, image.propierties["rdiffbase"], _ = get_device_path(rdiffbase_devices[rrtarget.index])
- if err ~= 0 then
- return 1
- end
- swupdate.info(string.format("Using device %s as rdiffbase.", image.properties["rdiffbase"]))
- else
- swupdate.error("Property 'rdiffbase' is missing in sw-description.")
- return 1
- end
- end
-
- -- Actually flash the partition.
- local msg
- image.type = chained_handler
- image.device = rrtarget.device_path
- err, msg = swupdate.call_handler(chained_handler, image)
- if err ~= 0 then
- swupdate.error(string.format("Error chain-calling '%s' handler: %s", chained_handler, (msg or "")))
- return 1
- end
-
- if config.bootloader.name == BOOTLOADER.EBG then
- if rootparam then
- local value = cmdline:gsub(
- rootparam:gsub("%-", "%%-"),
- string.format("root=%s%s",
- (rrtarget.parttype == PARTTYPE.PLAIN and "") or (rrtarget.parttype == PARTTYPE.UBI and "") or "PARTUUID=",
- rrtarget.parttype == PARTTYPE.PLAIN and rrtarget.device_path or devices[rrtarget.index]
- )
- )
- swupdate.info(string.format("Setting EFI Bootguard environment: kernelparams=%s", value))
- swupdate.set_bootenv("kernelparams", value)
- end
- elseif config.bootloader.name == BOOTLOADER.UBOOT then
- -- Update U-Boot environment.
- swupdate.info(string.format("Setting U-Boot environment"))
- local value = rrtarget.index
- swupdate.set_bootenv("swupdpart", value);
- end
-
- return 0
-end
-
--- File handler for updating kernel files.
-function handler_kernelfile(image)
- -- Check if we can chain-call the handler.
- local chained_handler = "rawfile"
- if image.properties ~= nil and image.properties["chainhandler"] ~= nil then
- chained_handler = image.properties["chainhandler"]
- elseif config["kernelfile"] ~= nil and config["kernelfile"]["chainhandler"] ~= nil then
- chained_handler = config["kernelfile"]["chainhandler"]
- end
- if not swupdate.handler[chained_handler] then
- swupdate.error(string.format("'%s' handler not available in SWUpdate distribution."), chained_handler)
- return 1
- end
-
- -- Check that rrtarget is set, else the 'roundrobin' handler hasn't been run.
- if rrtarget:size() == 0 then
- swupdate.error("The 'roundrobin' handler hasn't been run.")
- swupdate.info("Place 'roundrobin' above 'kernelfile' in sw-description.")
- return 1
- end
-
- -- Get device list for round-robin.
- local devices = get_device_list(image.device)
- if #devices < 2 then
- swupdate.error("Specify at least 2 devices in the device= property for 'kernelfile'.")
- return 1
- end
- if rrtarget.index > #devices then
- swupdate.error("Cannot map kernel partition to root partition.")
- return 1
- end
-
- -- Perform round-robin indexing for target.
- local err
- err, image.device, _ = get_device_path(devices[rrtarget.index])
- if err ~= 0 then
- return 1
- end
- swupdate.info(string.format("Using '%s' as 'kernelfile' target via '%s' handler.", image.device, chained_handler))
-
- -- Actually copy the 'kernelfile' files.
- local msg
- image.type = chained_handler
- err, msg = swupdate.call_handler(chained_handler, image)
- if err ~= 0 then
- swupdate.error(string.format("Error chain-calling '%s' handler: %s", chained_handler, (msg or "")))
- return 1
- end
-
- if config.bootloader.name == BOOTLOADER.EBG then
- -- Update EFI Boot Guard environment: kernelfile
- local value = string.format("%s%s", config.bootloader.bootlabel[rrtarget.index], config.bootloader.kernelname)
- swupdate.info(string.format("Setting EFI Bootguard environment: kernelfile=%s", value))
- swupdate.set_bootenv("kernelfile", value)
- elseif config.bootloader.name == BOOTLOADER.UBOOT then
- -- Update U-Boot environment.
- swupdate.info(string.format("Setting U-Boot environment"))
- -- TODO
- end
-
- return 0
-end
-
-swupdate.register_handler("roundrobin", handler_roundrobin, swupdate.HANDLER_MASK.IMAGE_HANDLER)
-swupdate.register_handler("kernelfile", handler_kernelfile, swupdate.HANDLER_MASK.FILE_HANDLER)
diff --git a/recipes-core/swupdate/swupdate.bb b/recipes-core/swupdate/swupdate.bb
index 75eaf8d..f75d014 100644
--- a/recipes-core/swupdate/swupdate.bb
+++ b/recipes-core/swupdate/swupdate.bb
@@ -29,6 +29,9 @@ DEBIAN_DEPENDS = "${shlibs:Depends}, ${misc:Depends}"
inherit dpkg
inherit swupdate-config

+SWUPDATE_ROUND_ROBIN_HANDLER_CONFIG ??= ""
+SRC_URI += "${@ 'file://${SWUPDATE_ROUND_ROBIN_HANDLER_CONFIG}' \
+ if d.getVar('SWUPDATE_ROUND_ROBIN_HANDLER_CONFIG') else 'file://swupdate.handler.${SWUPDATE_BOOTLOADER}.ini' }"
KFEATURES += "luahandler"

S = "${WORKDIR}/git"
@@ -46,5 +49,14 @@ do_prepare_build() {
echo "configs/${DEFCONFIG}" >> ${S}/.gitignore
fi
# luahandler
- install -m 0644 ${WORKDIR}/${SWUPDATE_LUASCRIPT} ${S}
+ if [ -e ${WORKDIR}/${SWUPDATE_LUASCRIPT} ]; then
+ install -m 0644 ${WORKDIR}/${SWUPDATE_LUASCRIPT} ${S}/swupdate_handlers.lua
+ fi
+ if [ -e ${WORKDIR}/swupdate.handler.${SWUPDATE_BOOTLOADER}.ini ]; then
+ install -m 0644 ${WORKDIR}/swupdate.handler.${SWUPDATE_BOOTLOADER}.ini ${S}/swupdate.handler.ini
+ echo "swupdate.handler.ini etc/" >> ${S}/debian/swupdate.install
+ elif [ -e ${WORKDIR}/${SWUPDATE_ROUND_ROBIN_HANDLER_CONFIG} ]; then
+ install -m 0644 ${WORKDIR}/${SWUPDATE_ROUND_ROBIN_HANDLER_CONFIG} ${S}/swupdate.handler.ini
+ echo "swupdate.handler.ini etc/" >> ${S}/debian/swupdate.install
+ fi
}
--
2.20.1


[isar-cip-dev][PATCH 1/2] swupdate: Update to 2021.04

Quirin Gylstorff
 

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

The new round robin handler requires SWUpdate 2021.04
for the function `getroot`.

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

diff --git a/recipes-core/swupdate/swupdate.bb b/recipes-core/swupdate/swupdate.bb
index 526c72f..75eaf8d 100644
--- a/recipes-core/swupdate/swupdate.bb
+++ b/recipes-core/swupdate/swupdate.bb
@@ -15,8 +15,8 @@ LIC_FILES_CHKSUM = "file://${LAYERDIR_isar}/licenses/COPYING.GPLv2;md5=751419260

SRC_URI = "git://github.com/sbabic/swupdate.git;branch=master;protocol=https"

-SRCREV = "1a6dfbb5a0be978ac1a159758e278ab4d44167e2"
-PV = "2020.4-git+isar"
+SRCREV = "47a1246435fdb78fba15cc969596994130412956"
+PV = "2021.4-git+isar"

DEFCONFIG := "swupdate_defconfig"

--
2.20.1


[isar-cip-dev][PATCH 0/2] swupdate add new round robin handler

Quirin Gylstorff
 

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

Add the SWUpdate round-robin Lua handler from [1].
Also update swupdate to 2021.04 for dependencies of the lua handler.

[1]: https://gitlab.com/cip-playground/swupdate-handler-roundrobin

Quirin Gylstorff (2):
swupdate: Update to 2021.04
swupdate: Add option to use swupdate-handler-roundrobin

classes/swupdate-config.bbclass | 14 +-
kas/opt/ebg-secure-boot-base.yml | 1 +
.../files/secure-boot/sw-description.tmpl | 14 +-
recipes-core/images/files/sw-description.tmpl | 21 +-
.../swupdate.handler.efibootguard.ini | 20 +
.../files/swupdate.handler.efibootguard.ini | 26 +
.../swupdate/files/swupdate_handlers.lua | 453 ------------------
recipes-core/swupdate/swupdate.bb | 18 +-
8 files changed, 97 insertions(+), 470 deletions(-)
create mode 100644 recipes-core/swupdate/files/secureboot/swupdate.handler.efibootguard.ini
create mode 100644 recipes-core/swupdate/files/swupdate.handler.efibootguard.ini
delete mode 100644 recipes-core/swupdate/files/swupdate_handlers.lua

--
2.20.1


New CVE entries this week

Pavel Machek
 

Hi!

These are the new issues this week:

Best regards,
Pavel

* 2021-06-04

CVE-2021-33200 -- BPF fix turned out to be buggy.

* 2021-06-09

CVE-2021-0606 -- EoP in GPU DRM Driver / reported by android, probably upstream commit e7cdf5c82f1773c3386b93bbcf13b9bfff29fa31 ... may be interesting?

CVE-2021-3587 -- redhat Bugzilla 1968057: CVE-2021-3587 kernel: nfc: Null pointer dereference in llcp_sock_getname

CVE-2020-36385 -- An issue was discovered in the Linux kernel before 5.8.1. net/bluetooth/hci_event.c has a slab out-of-bounds read in hci_extended_inquiry_result_evt, aka CID-51c19bf3d5cf.

CVE-2020-36387 -- An issue was discovered in the Linux kernel before 5.8.2. fs/io_uring.c has a use-after-free related to io_async_task_func and ctx reference holding, aka CID-6d816e088c35.








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


Re: BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809

Jan Kiszka
 

On 07.06.21 12:18, Rainer Kloud wrote:
Hi,
 
I notice you are using -rt kernel. Do you actually need realtime
features?
Yes, I actually need the realtime feature. I have one task which
needs to run periodically in realtime (triggered every 10ms by an
external IRQ).
Please don't forget to share your kernel config with us so that we can
make sure your use case is covered subsystem-wise in CIP. From Siemens
side, we still have room for improvements in this regard, even more on -rt.
Attached you can find my kernel config. 
 
Would you propose it as patch to
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config?

Jun 1 09:11:46 sicam kernel: [46802.944299] [<c062f854>] (dump_stack) from [<c03a57ec>] (check_preemption_disabled+0x110/0x114)
Jun 1 09:11:46 sicam kernel: [46802.944316] [<c03a57ec>] (check_preemption_disabled) from [<c014163c>] (migrate_enable+0x40/0x488)
Jun 1 09:11:46 sicam kernel: [46802.944338] [<c014163c>] (migrate_enable) from [<c053ff0c>] (ip_finish_output2+0x21c/0x460)
Migration should be on across migration-disabled sections, that's their
whole purpose. But maybe the check that preemption needs to be off when
using smp_processor_id needs relaxing to at least migration must be off.
Sorry, but I can not follow your words. What do you mean with 'needs relaxing to
at least migration must be off'?
Strike it, that case is too generic to be a reason for something that
long in the field by now.

From looking at the code of migrate_enable(), I suspect that we cause
the call to smp_processor_id() via "struct rq *rq = this_rq();". That
comes fairly at the beginning of migrated_enable(), which matches the
small offset in your backtrace (you can confirm that better). That would
complain about "preemptible code" if the caller does not have preemption
or at least migration off. So my suspect would be a
migration_disable/enable imbalance in the code path you triggered,
likely somewhere in the TCP code.

Did you already try more recent RT kernels, both in the 4.19 series as
well as maybe 5.10 or even latest -rt? Possibly, this issue has been
fixed by now. If you can even reproduce with latest -rt, the issue is
better reported to linux-rt-users.

Jan

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


CIP IRC weekly meeting today (libera.chat)

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi all,

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

Please note that we already moved from Freenode to libera.chat, and our channel is the following:
irc:irc.libera.chat:6667/cip

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=6&day=10&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00


Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2021/06/cip.2021-06-03-09.00.log.html

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Do some experiment to lower burdens on CI - patersonc
3. Monitor the status of CVE-2021-3444 and CVE-2021-20292 (3/25) - Kernel Team
4. Update Testing table below with 5.10 info - patersonc
https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/centalisedtesting/cioverview


* Kernel maintenance updates
* Kernel testing
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Re: BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809

rainer.kloud@...
 

Hello Pavel,
 
I notice you are using -rt kernel. Do you actually need realtime
features?
Yes, I actually need the realtime feature. I have one task which
needts to run periodically in realtime (every 10ms).

Can you try to reproduce the problem on 4.19.193?
This is only a problem with the realtime patch. The patch
introduces migrate_enable which is part of the callstack:

Jun 1 09:11:46 sicam kernel: [46802.944165] BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809
Jun 1 09:11:46 sicam kernel: [46802.944210] caller is migrate_enable+0x40/0x488
Jun 1 09:11:46 sicam kernel: [46802.944221] CPU: 0 PID: 1809 Comm: TI4SDTSK#135 Tainted: G W 4.19.165-cip41-rt18 #1
Jun 1 09:11:46 sicam kernel: [46802.944225] Hardware name: Altera SOCFPGA
Jun 1 09:11:46 sicam kernel: [46802.944252] [<c010e9d4>] (unwind_backtrace) from [<c010b9f4>] (show_stack+0x10/0x14)
Jun 1 09:11:46 sicam kernel: [46802.944272] [<c010b9f4>] (show_stack) from [<c062f854>] (dump_stack+0x94/0xa8)
Jun 1 09:11:46 sicam kernel: [46802.944299] [<c062f854>] (dump_stack) from [<c03a57ec>] (check_preemption_disabled+0x110/0x114)
Jun 1 09:11:46 sicam kernel: [46802.944316] [<c03a57ec>] (check_preemption_disabled) from [<c014163c>] (migrate_enable+0x40/0x488)
Jun 1 09:11:46 sicam kernel: [46802.944338] [<c014163c>] (migrate_enable) from [<c053ff0c>] (ip_finish_output2+0x21c/0x460)
Jun 1 09:11:46 sicam kernel: [46802.944353] [<c053ff0c>] (ip_finish_output2) from [<c0542854>] (ip_output+0x140/0x184)
Jun 1 09:11:46 sicam kernel: [46802.944364] [<c0542854>] (ip_output) from [<c0542128>] (__ip_queue_xmit+0x134/0x40c)
Jun 1 09:11:46 sicam kernel: [46802.944381] [<c0542128>] (__ip_queue_xmit) from [<c055cf70>] (__tcp_transmit_skb+0x53c/0xb20)
Jun 1 09:11:46 sicam kernel: [46802.944392] [<c055cf70>] (__tcp_transmit_skb) from [<c055e188>] (tcp_write_xmit+0x27c/0xfd0)
Jun 1 09:11:46 sicam kernel: [46802.944403] [<c055e188>] (tcp_write_xmit) from [<c055ef10>] (__tcp_push_pending_frames+0x34/0xa8)
Jun 1 09:11:46 sicam kernel: [46802.944413] [<c055ef10>] (__tcp_push_pending_frames) from [<c054f5cc>] (tcp_sendmsg_locked+0x66c/0xc40)
Jun 1 09:11:46 sicam kernel: [46802.944422] [<c054f5cc>] (tcp_sendmsg_locked) from [<c054fbc8>] (tcp_sendmsg+0x28/0x3c)
Jun 1 09:11:46 sicam kernel: [46802.944441] [<c054fbc8>] (tcp_sendmsg) from [<c04cb3f4>] (sock_sendmsg+0x14/0x24)
Jun 1 09:11:46 sicam kernel: [46802.944455] [<c04cb3f4>] (sock_sendmsg) from [<c04cc6d0>] (__sys_sendto+0xc4/0x104)
Jun 1 09:11:46 sicam kernel: [46802.944467] [<c04cc6d0>] (__sys_sendto) from [<c04cc72c>] (sys_send+0x18/0x20)
Jun 1 09:11:46 sicam kernel: [46802.944479] [<c04cc72c>] (sys_send) from [<c0101000>] (ret_fast_syscall+0x0/0x5c)
Jun 1 09:11:46 sicam kernel: [46802.944484] Exception stack(0xda337fa8 to 0xda337ff0)
Jun 1 09:11:46 sicam kernel: [46802.944493] 7fa0: 001c6f2c 00000001 00000037 0020ae40 00000006 00000000
Jun 1 09:11:46 sicam kernel: [46802.944502] 7fc0: 001c6f2c 00000001 00000001 00000121 001651c8 001ea378 ffff0000 00000006
Jun 1 09:11:46 sicam kernel: [46802.944508] 7fe0: 00000000 b3efea18 00000000 b6a2ff40

Best Regards,
Rainer


Re: BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809

Rainer Kloud
 

Hi,
 
I notice you are using -rt kernel. Do you actually need realtime
features?
Yes, I actually need the realtime feature. I have one task which
needs to run periodically in realtime (triggered every 10ms by an
external IRQ).
Please don't forget to share your kernel config with us so that we can
make sure your use case is covered subsystem-wise in CIP. From Siemens
side, we still have room for improvements in this regard, even more on -rt.
Attached you can find my kernel config. 
 
Jun 1 09:11:46 sicam kernel: [46802.944299] [<c062f854>] (dump_stack) from [<c03a57ec>] (check_preemption_disabled+0x110/0x114)
Jun 1 09:11:46 sicam kernel: [46802.944316] [<c03a57ec>] (check_preemption_disabled) from [<c014163c>] (migrate_enable+0x40/0x488)
Jun 1 09:11:46 sicam kernel: [46802.944338] [<c014163c>] (migrate_enable) from [<c053ff0c>] (ip_finish_output2+0x21c/0x460)
Migration should be on across migration-disabled sections, that's their
whole purpose. But maybe the check that preemption needs to be off when
using smp_processor_id needs relaxing to at least migration must be off.
Sorry, but I can not follow your words. What do you mean with 'needs relaxing to
at least migration must be off'?

Thanx,
Rainer


Re: BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809

Jan Kiszka
 

Hi Rainer,

On 07.06.21 07:23, Rainer Kloud wrote:
Hello Pavel,

I notice you are using -rt kernel. Do you actually need realtime
features?
Yes, I actually need the realtime feature. I have one task which
needs to run periodically in realtime (triggered every 10ms by an
external IRQ).
Please don't forget to share your kernel config with us so that we can
make sure your use case is covered subsystem-wise in CIP. From Siemens
side, we still have room for improvements in this regard, even more on -rt.

Jun 1 09:11:46 sicam kernel: [46802.944299] [<c062f854>] (dump_stack) from [<c03a57ec>] (check_preemption_disabled+0x110/0x114)
Jun 1 09:11:46 sicam kernel: [46802.944316] [<c03a57ec>] (check_preemption_disabled) from [<c014163c>] (migrate_enable+0x40/0x488)
Jun 1 09:11:46 sicam kernel: [46802.944338] [<c014163c>] (migrate_enable) from [<c053ff0c>] (ip_finish_output2+0x21c/0x460)
Migration should be on across migration-disabled sections, that's their
whole purpose. But maybe the check that preemption needs to be off when
using smp_processor_id needs relaxing to at least migration must be off.

Jan

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


Re: BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809

Rainer Kloud
 

Hello Pavel,

I notice you are using -rt kernel. Do you actually need realtime
features?
Yes, I actually need the realtime feature. I have one task which
needs to run periodically in realtime (triggered every 10ms by an
external IRQ).

Can you try to reproduce the problem on 4.19.193?
This is only a problem with the realtime patch. The patch
introduces migrate_enable which is part of the callstack:

Jun 1 09:11:46 sicam kernel: [46802.944165] BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809
Jun 1 09:11:46 sicam kernel: [46802.944210] caller is migrate_enable+0x40/0x488
Jun 1 09:11:46 sicam kernel: [46802.944221] CPU: 0 PID: 1809 Comm: TI4SDTSK#135 Tainted: G W 4.19.165-cip41-rt18 #1
Jun 1 09:11:46 sicam kernel: [46802.944225] Hardware name: Altera SOCFPGA
Jun 1 09:11:46 sicam kernel: [46802.944252] [<c010e9d4>] (unwind_backtrace) from [<c010b9f4>] (show_stack+0x10/0x14)
Jun 1 09:11:46 sicam kernel: [46802.944272] [<c010b9f4>] (show_stack) from [<c062f854>] (dump_stack+0x94/0xa8)
Jun 1 09:11:46 sicam kernel: [46802.944299] [<c062f854>] (dump_stack) from [<c03a57ec>] (check_preemption_disabled+0x110/0x114)
Jun 1 09:11:46 sicam kernel: [46802.944316] [<c03a57ec>] (check_preemption_disabled) from [<c014163c>] (migrate_enable+0x40/0x488)
Jun 1 09:11:46 sicam kernel: [46802.944338] [<c014163c>] (migrate_enable) from [<c053ff0c>] (ip_finish_output2+0x21c/0x460)
Jun 1 09:11:46 sicam kernel: [46802.944353] [<c053ff0c>] (ip_finish_output2) from [<c0542854>] (ip_output+0x140/0x184)
Jun 1 09:11:46 sicam kernel: [46802.944364] [<c0542854>] (ip_output) from [<c0542128>] (__ip_queue_xmit+0x134/0x40c)
Jun 1 09:11:46 sicam kernel: [46802.944381] [<c0542128>] (__ip_queue_xmit) from [<c055cf70>] (__tcp_transmit_skb+0x53c/0xb20)
Jun 1 09:11:46 sicam kernel: [46802.944392] [<c055cf70>] (__tcp_transmit_skb) from [<c055e188>] (tcp_write_xmit+0x27c/0xfd0)
Jun 1 09:11:46 sicam kernel: [46802.944403] [<c055e188>] (tcp_write_xmit) from [<c055ef10>] (__tcp_push_pending_frames+0x34/0xa8)
Jun 1 09:11:46 sicam kernel: [46802.944413] [<c055ef10>] (__tcp_push_pending_frames) from [<c054f5cc>] (tcp_sendmsg_locked+0x66c/0xc40)
Jun 1 09:11:46 sicam kernel: [46802.944422] [<c054f5cc>] (tcp_sendmsg_locked) from [<c054fbc8>] (tcp_sendmsg+0x28/0x3c)
Jun 1 09:11:46 sicam kernel: [46802.944441] [<c054fbc8>] (tcp_sendmsg) from [<c04cb3f4>] (sock_sendmsg+0x14/0x24)
Jun 1 09:11:46 sicam kernel: [46802.944455] [<c04cb3f4>] (sock_sendmsg) from [<c04cc6d0>] (__sys_sendto+0xc4/0x104)
Jun 1 09:11:46 sicam kernel: [46802.944467] [<c04cc6d0>] (__sys_sendto) from [<c04cc72c>] (sys_send+0x18/0x20)
Jun 1 09:11:46 sicam kernel: [46802.944479] [<c04cc72c>] (sys_send) from [<c0101000>] (ret_fast_syscall+0x0/0x5c)
Jun 1 09:11:46 sicam kernel: [46802.944484] Exception stack(0xda337fa8 to 0xda337ff0)
Jun 1 09:11:46 sicam kernel: [46802.944493] 7fa0: 001c6f2c 00000001 00000037 0020ae40 00000006 00000000
Jun 1 09:11:46 sicam kernel: [46802.944502] 7fc0: 001c6f2c 00000001 00000001 00000121 001651c8 001ea378 ffff0000 00000006
Jun 1 09:11:46 sicam kernel: [46802.944508] 7fe0: 00000000 b3efea18 00000000 b6a2ff40

Best Regards,
Rainer


Re: BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809

Pavel Machek
 

Hi!

<html><head></head><body>
Please avoid html on mailing lists.

I&#39;m useing the kernel&nbsp;4.19.165-cip41-rt18 on the Altera
SOCkit and I encountered an problem with high TCP traffic.
I notice you are using -rt kernel. Do you actually need realtime
features?

Can you try to reproduce the problem on 4.19.193?

Can anybody tell me what problem this message triggers?

The check_preemption_disabled function is called when
smp_processor_id() is used. This function should be called with
preemtion disabled, but I think migrate_enable will allways enable
preemption ...
I believe you got your analysis mostly right, I'd have to study the
code some more to see what is going on.

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


BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809

Rainer Kloud
 

Hi,
 
I'm useing the kernel 4.19.165-cip41-rt18 on the Altera SOCkit and I encountered an problem with high TCP traffic.
I get the following kernel message over and over: 
 
Jun  1 09:11:46 sicam kernel: [46802.944165] BUG: using smp_processor_id() in preemptible [00000000] code: TCPTSK/1809
Jun  1 09:11:46 sicam kernel: [46802.944210] caller is migrate_enable+0x40/0x488
Jun  1 09:11:46 sicam kernel: [46802.944221] CPU: 0 PID: 1809 Comm: TI4SDTSK#135 Tainted: G        W         4.19.165-cip41-rt18 #1
Jun  1 09:11:46 sicam kernel: [46802.944225] Hardware name: Altera SOCFPGA
Jun  1 09:11:46 sicam kernel: [46802.944252] [<c010e9d4>] (unwind_backtrace) from [<c010b9f4>] (show_stack+0x10/0x14)
Jun  1 09:11:46 sicam kernel: [46802.944272] [<c010b9f4>] (show_stack) from [<c062f854>] (dump_stack+0x94/0xa8)
Jun  1 09:11:46 sicam kernel: [46802.944299] [<c062f854>] (dump_stack) from [<c03a57ec>] (check_preemption_disabled+0x110/0x114)
Jun  1 09:11:46 sicam kernel: [46802.944316] [<c03a57ec>] (check_preemption_disabled) from [<c014163c>] (migrate_enable+0x40/0x488)
Jun  1 09:11:46 sicam kernel: [46802.944338] [<c014163c>] (migrate_enable) from [<c053ff0c>] (ip_finish_output2+0x21c/0x460)
Jun  1 09:11:46 sicam kernel: [46802.944353] [<c053ff0c>] (ip_finish_output2) from [<c0542854>] (ip_output+0x140/0x184)
Jun  1 09:11:46 sicam kernel: [46802.944364] [<c0542854>] (ip_output) from [<c0542128>] (__ip_queue_xmit+0x134/0x40c)
Jun  1 09:11:46 sicam kernel: [46802.944381] [<c0542128>] (__ip_queue_xmit) from [<c055cf70>] (__tcp_transmit_skb+0x53c/0xb20)
Jun  1 09:11:46 sicam kernel: [46802.944392] [<c055cf70>] (__tcp_transmit_skb) from [<c055e188>] (tcp_write_xmit+0x27c/0xfd0)
Jun  1 09:11:46 sicam kernel: [46802.944403] [<c055e188>] (tcp_write_xmit) from [<c055ef10>] (__tcp_push_pending_frames+0x34/0xa8)
Jun  1 09:11:46 sicam kernel: [46802.944413] [<c055ef10>] (__tcp_push_pending_frames) from [<c054f5cc>] (tcp_sendmsg_locked+0x66c/0xc40)
Jun  1 09:11:46 sicam kernel: [46802.944422] [<c054f5cc>] (tcp_sendmsg_locked) from [<c054fbc8>] (tcp_sendmsg+0x28/0x3c)
Jun  1 09:11:46 sicam kernel: [46802.944441] [<c054fbc8>] (tcp_sendmsg) from [<c04cb3f4>] (sock_sendmsg+0x14/0x24)
Jun  1 09:11:46 sicam kernel: [46802.944455] [<c04cb3f4>] (sock_sendmsg) from [<c04cc6d0>] (__sys_sendto+0xc4/0x104)
Jun  1 09:11:46 sicam kernel: [46802.944467] [<c04cc6d0>] (__sys_sendto) from [<c04cc72c>] (sys_send+0x18/0x20)
Jun  1 09:11:46 sicam kernel: [46802.944479] [<c04cc72c>] (sys_send) from [<c0101000>] (ret_fast_syscall+0x0/0x5c)
Jun  1 09:11:46 sicam kernel: [46802.944484] Exception stack(0xda337fa8 to 0xda337ff0)
Jun  1 09:11:46 sicam kernel: [46802.944493] 7fa0:                   001c6f2c 00000001 00000037 0020ae40 00000006 00000000
Jun  1 09:11:46 sicam kernel: [46802.944502] 7fc0: 001c6f2c 00000001 00000001 00000121 001651c8 001ea378 ffff0000 00000006
Jun  1 09:11:46 sicam kernel: [46802.944508] 7fe0: 00000000 b3efea18 00000000 b6a2ff40
 
After some time (normally 10 - 18 hours) the kernel stucks completelly. The TCPTSK is a custom task which has 20 TCP connections to different communication parners running on other hardware (PC, RaspberryPI, ...).
 
Can anybody tell me what problem this message triggers?
The check_preemption_disabled function is called when smp_processor_id() is used. This function should be called with preemtion disabled, but I think migrate_enable will allways enable preemption ...
 
Thanx for your response!
Rainer
 

1901 - 1920 of 8412