- Linux-stable-mirror - lists.linaro.org

[PATCH] arm64: kprobe: fix an error in single stepping support

by 1534428646＠qq.com

From: "Yiren Xie" <1534428646(a)qq.com> It is obvious a conflict between the code and the comment. The function aarch64_insn_is_steppable is used to check if a mrs instruction can be safe in single-stepping environment, in the comment it says only reading DAIF bits by mrs is safe in single-stepping environment, and other mrs instructions are not. So aarch64_insn_is_steppable should returen "TRUE" if the mrs instruction being single stepped is reading DAIF bits. And have verified using a kprobe kernel module which reads the DAIF bits by function arch_local_irq_save with offset setting to 0x4, confirmed that without this modification, it encounters "kprobe_init: register_kprobe failed, returned -22" error while inserting the kprobe kernel module. and with this modification, it can read the DAIF bits in single-stepping environment. Fixes: 2dd0e8d2d2a1 ("arm64: Kprobes with single stepping support") Cc: stable(a)vger.kernel.org Signed-off-by: Yiren Xie <1534428646(a)qq.com> --- arch/arm64/kernel/probes/decode-insn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/probes/decode-insn.c b/arch/arm64/kernel/probes/decode-insn.c index 6438bf62e753..22383eb1c22c 100644 --- a/arch/arm64/kernel/probes/decode-insn.c +++ b/arch/arm64/kernel/probes/decode-insn.c @@ -40,7 +40,7 @@ static bool __kprobes aarch64_insn_is_steppable(u32 insn) */ if (aarch64_insn_is_mrs(insn)) return aarch64_insn_extract_system_reg(insn) - != AARCH64_INSN_SPCLREG_DAIF; + == AARCH64_INSN_SPCLREG_DAIF; /* * The HINT instruction is steppable only if it is in whitelist -- 2.34.1

3 weeks, 2 days

3
2
0 0

Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219 sge_count (-12) is out of range

by Harshvardhan Jha

Hi All, +stable There seems to be some formatting issues in my log output. I have attached it as a file. Thanks & Regards, Harshvardhan On 29/01/25 1:57 PM, Harshvardhan Jha wrote: > Hello there, > > The stable tag v5.4.289 seems to fail to boot with following trace: > > [ OK ] Created slice system-serial\x2dgetty.slice. [ OK ] Listening on > udev Control Socket. [ OK ] Reached target Local Encrypted Volumes. [ OK > ] Listening on /dev/initctl Compatibility Named Pipe. [ OK ] Listening > on Delayed Shutdown Socket. [ OK ] Created slice > system-selinux\x2dpol...grate\x2dlocal\x2dchanges.slice. [ OK ] Stopped > target Initrd File Systems. [ OK ] Listening on LVM2 metadata daemon > socket. Mounting Debug File System... [ OK ] Listening on networkd > rtnetlink socket. [ OK ] Listening on Device-mapper event daemon FIFOs. > Starting Monitoring of LVM2 mirrors... dmeventd or progress polling... [ > OK ] Created slice User and Session Slice. Starting Read and set NIS > domainname from /etc/sysconfig/network... Starting Load legacy module > configuration... [ OK ] Set up automount Arbitrary Executab...ats File > System Automount Point. [ OK ] Created slice > system-rdma\x2dload\x2dmodules.slice. [ OK ] Started Forward Password > Requests to Wall Directory Watch. [ OK ] Reached target Paths. Starting > Remount Root and Kernel File Systems... [ OK ] Created slice > system-getty.slice. Starting Create list of required st... nodes for the > current kernel... Starting Set Up Additional Binary Formats... [ OK ] > Stopped target Initrd Root File System. [ OK ] Reached target Slices. [ > OK ] Created slice system-systemd\x2dfsck.slice. [ OK ] Mounted POSIX > Message Queue File System. [ OK ] Mounted Debug File System. [ OK ] > Started Read and set NIS domainname from /etc/sysconfig/network. > Mounting Arbitrary Executable File Formats File System... [ OK ] Started > Journal Service. [ OK ] Started Create list of required sta...ce nodes > for the current kernel. Starting Create Static Device Nodes in /dev... [ > OK ] Started LVM2 metadata daemon. [ OK ] Started Remount Root and > Kernel File Systems. Starting Load/Save Random Seed... Starting udev > Coldplug all Devices... Starting Flush Journal to Persistent Storage... > [FAILED] Failed to start Load Kernel Modules. See 'systemctl status > systemd-modules-load.service' for details. Starting Apply Kernel > Variables... [ OK ] Started Load/Save Random Seed. [ OK ] Mounted > Arbitrary Executable File Formats File System. [ OK ] Started Set Up > Additional Binary Formats. [ OK ] Started Create Static Device Nodes in > /dev. Starting udev Kernel Device Manager... [ OK ] Started Apply Kernel > Variables. [ OK ] Started Load legacy module configuration. [ OK ] > Started udev Coldplug all Devices. Starting udev Wait for Complete > Device Initialization... [ 24.427217] megaraid_sas 0000:65:00.0: > megasas_build_io_fusion 3273 sge_count (-12) is out of range. Range is: > 0-256 > > [ 24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion 3273 > sge_count (-12) is out of range. Range is: 0-256 kept showing > infinitely. It kept popping until I reset the system. > > Reverting the following patch seems to fix the issue: > > commit 07c9cccc4c3fecba175a7e5aafba6370758f5ce2 > Author: Juergen Gross <jgross(a)suse.com> > Date: Fri Sep 13 12:05:02 2024 +0200 > > xen/swiotlb: add alignment check for dma buffers > > [ Upstream commit 9f40ec84a7976d95c34e7cc070939deb103652b0 ] > > When checking a memory buffer to be consecutive in machine memory, > the alignment needs to be checked, too. Failing to do so might result > in DMA memory not being aligned according to its requested size, > leading to error messages like: > > 4xxx 0000:2b:00.0: enabling device (0140 -> 0142) > 4xxx 0000:2b:00.0: Ring address not aligned > 4xxx 0000:2b:00.0: Failed to initialise service qat_crypto > 4xxx 0000:2b:00.0: Resetting device qat_dev0 > 4xxx: probe of 0000:2b:00.0 failed with error -14 > > Fixes: 9435cce87950 ("xen/swiotlb: Add support for 64KB page > granularity") > Signed-off-by: Juergen Gross <jgross(a)suse.com> > Reviewed-by: Stefano Stabellini <sstabellini(a)kernel.org> > Signed-off-by: Juergen Gross <jgross(a)suse.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > I tried changing swiotlb grub command line arguments but that didn't > seem to help much unfortunately and the error was seen again. > > Thanks & Regards, > Harshvardhan >

3 weeks, 2 days

5
18
0 0

[PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

by Stefan Eichenberger

From: Stefan Eichenberger <stefan.eichenberger(a)toradex.com> When usb_control_msg is used in the get_bMaxPacketSize0 function, the USB pipe does not include the endpoint device number. This can cause failures when a usb hub port is reinitialized after encountering a bad cable connection. As a result, the system logs the following error messages: usb usb2-port1: cannot reset (err = -32) usb usb2-port1: Cannot enable. Maybe the USB cable is bad? usb usb2-port1: attempt power cycle usb 2-1: new high-speed USB device number 5 using ci_hdrc usb 2-1: device descriptor read/8, error -71 The problem began after commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads"). There usb_get_device_descriptor was replaced with get_bMaxPacketSize0. Unlike usb_get_device_descriptor, the get_bMaxPacketSize0 function uses the macro usb_rcvaddr0pipe, which does not include the endpoint device number. usb_get_device_descriptor, on the other hand, used the macro usb_rcvctrlpipe, which includes the endpoint device number. By modifying the get_bMaxPacketSize0 function to use usb_rcvctrlpipe instead of usb_rcvaddr0pipe, the issue can be resolved. This change will ensure that the endpoint device number is included in the USB pipe, preventing reinitialization failures. If the endpoint has not set the device number yet, it will still work because the device number is 0 in udev. Cc: stable(a)vger.kernel.org Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") Signed-off-by: Stefan Eichenberger <stefan.eichenberger(a)toradex.com> --- Before commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") usb_rcvaddr0pipe was used in hub_port_init. With this proposed change, usb_rcvctrlpipe will be used which includes devnum for the pipe. I'm not sure if this might have some side effects. However, my understanding is that devnum is set to the right value (might also be 0 if not initialised) before get_bMaxPacketSize0 is called. Therefore, this should work but please let me know if I'm wrong on this. --- drivers/usb/core/hub.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index c3f839637cb5..59e38780f76d 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -4698,7 +4698,6 @@ void usb_ep0_reinit(struct usb_device *udev) EXPORT_SYMBOL_GPL(usb_ep0_reinit); #define usb_sndaddr0pipe() (PIPE_CONTROL << 30) -#define usb_rcvaddr0pipe() ((PIPE_CONTROL << 30) | USB_DIR_IN) static int hub_set_address(struct usb_device *udev, int devnum) { @@ -4804,7 +4803,7 @@ static int get_bMaxPacketSize0(struct usb_device *udev, for (i = 0; i < GET_MAXPACKET0_TRIES; ++i) { /* Start with invalid values in case the transfer fails */ buf->bDescriptorType = buf->bMaxPacketSize0 = 0; - rc = usb_control_msg(udev, usb_rcvaddr0pipe(), + rc = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), USB_REQ_GET_DESCRIPTOR, USB_DIR_IN, USB_DT_DEVICE << 8, 0, buf, size, -- 2.45.2

3 weeks, 2 days

2
2
0 0

stable-rc/linux-5.10.y: new build regression: passing 'const struct net *' to parameter of type 'struc...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: passing 'const struct net *' to parameter of type 'struct net *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] in net/ipv4/udp.o (net/ipv4/udp.c) [logspec:kbuild,kbuild.compiler.error] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:841ec27ef8554e3fd… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:841ec27ef8554e3fd… Log excerpt: net/ipv4/udp.c:447:29: error: passing 'const struct net *' to parameter of type 'struct net *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] 447 | score = compute_score(sk, net, | ^~~ net/ipv4/udp.c:359:55: note: passing argument to parameter 'net' here 359 | static int compute_score(struct sock *sk, struct net *net, | ^ 1 error generated. # Builds where the incident occurred: ## i386_defconfig+allmodconfig(clang-17): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a6a661a7bc87… ## x86_64_defconfig+allmodconfig(clang-17): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a3d661a7bc87… ## defconfig+allmodconfig(clang-17): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a31661a7bc87… ## x86_64_defconfig(clang-17): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a39661a7bc87… ## defconfig+allmodconfig(clang-17): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a11a35661a7bc87… #kernelci issue maestro:841ec27ef8554e3fda7cfd5babc4831387ac9e8e -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 weeks, 3 days

2
1
0 0

stable-rc/linux-5.4.y: new build regression: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__free’ in drivers/soc/atmel/soc.o (drivers/soc/atmel/soc.c) [logspec:kbuild,kbuild.compiler.error] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:040dcc33328a47e52… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:040dcc33328a47e52… Log excerpt: drivers/soc/atmel/soc.c:277:32: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__free’ 277 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~ drivers/soc/atmel/soc.c:277:32: error: implicit declaration of function ‘__free’; did you mean ‘kzfree’? [-Werror=implicit-function-declaration] 277 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~ | kzfree drivers/soc/atmel/soc.c:277:39: error: ‘device_node’ undeclared (first use in this function) 277 | struct device_node *np __free(device_node) = of_find_node_by_path("/"); | ^~~~~~~~~~~ drivers/soc/atmel/soc.c:277:39: note: each undeclared identifier is reported only once for each function it appears in drivers/soc/atmel/soc.c:279:51: error: ‘np’ undeclared (first use in this function); did you mean ‘nop’? 279 | if (!of_match_node(at91_soc_allowed_list, np)) | ^~ | nop CC drivers/spi/spidev.o cc1: some warnings being treated as errors # Builds where the incident occurred: ## multi_v7_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a119e4661a7bc87… ## multi_v5_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a119e0661a7bc87… ## multi_v7_defconfig(gcc-12): - Dashboard: https://staging.dashboard.kernelci.org:9000/build/maestro:67a119d8661a7bc87… #kernelci issue maestro:040dcc33328a47e528c393a656a52b340b4ccc8b -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 weeks, 3 days

2
1
0 0

stable-rc/linux-6.6.y: new boot regression: WARNING at drivers/base/core.c:2515 device_release+0x80/...

by KernelCI bot

Hello, New boot regression found on stable-rc/linux-6.6.y: WARNING at drivers/base/core.c:2515 device_release+0x80/0x90 [logspec:generic_linux_boot,linux.kernel.warning] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:18a6cd3bd705698b4… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:18a6cd3bd705698b4… Log excerpt: [ 10.292722] mtk-wdt 10007000.watchdog: Watchdog enabled (timeout=31 sec, nowayout=0) [ 10.300525] Device 'conn' does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst. [ 10.300855] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.312539] WARNING: CPU: 4 PID: 76 at drivers/base/core.c:2515 device_release+0x80/0x90 [ 10.320803] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.328862] Modules linked in: videodev(+) [ 10.337116] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.337122] ecdh_generic [ 10.344606] videodev: Linux video capture interface: v2.00 [ 10.344795] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344808] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344813] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344820] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344825] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344829] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344862] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344867] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.349449] ecc mtk_mutex cfg80211(+) cros_ec_typec(+) pwm_bl videobuf2_common mtk_rpmsg mtk_mmsys mc rfkill elan_i2c auxadc_thermal sbs_battery mtk_pmic_keys mtk_wdt(+) pwm_mediatek mtk_scp_ipi mt6577_auxadc backlight [ 10.443014] CPU: 4 PID: 76 Comm: kworker/u18:7 Tainted: G W 6.6.76-rc1 #1 [ 10.451183] Hardware name: Google juniper sku16 board (DT) [ 10.456659] Workqueue: events_unbound deferred_probe_work_func [ 10.462491] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 10.469443] pc : device_release+0x80/0x90 [ 10.473443] lr : device_release+0x80/0x90 [ 10.477441] sp : ffff8000806a3a80 [ 10.480744] x29: ffff8000806a3a80 x28: 0000000000000000 x27: 0000000000000000 [ 10.487871] x26: 0000000000000000 x25: 0000000000000000 x24: ffffb3a8b7360500 [ 10.494998] x23: 0000000000000000 x22: 0000000000000000 x21: ffffb3a8b735db90 [ 10.502124] x20: 0000000000000000 x19: ffff514146120880 x18: 0000000000000006 [ 10.509250] x17: 61206e656b6f7262 x16: 207369207469202c x15: 6e6f6974636e7566 [ 10.516376] x14: 202928657361656c x13: 2e7473722e746365 x12: 6a626f6b2f697061 [ 10.523502] x11: 2d65726f632f6e6f x10: 697461746e656d75 x9 : 6572206120657661 [ 10.530628] x8 : 6820746f6e207365 x7 : 205d353235303033 x6 : 332e30312020205b [ 10.537754] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff [ 10.544880] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff514140e28f00 [ 10.552007] Call trace: [ 10.554442] device_release+0x80/0x90 [ 10.558095] kobject_put+0xa4/0x120 [ 10.561577] put_device+0x14/0x24 [ 10.564881] genpd_remove+0x118/0x1bc [ 10.568534] pm_genpd_remove+0x2c/0x50 [ 10.572274] scpsys_probe+0x13c/0x218 [ 10.575927] platform_probe+0x68/0xc4 [ 10.579579] really_probe+0x148/0x2ac [ 10.583232] __driver_probe_device+0x78/0x12c [ 10.587579] driver_probe_device+0xd8/0x15c [ 10.591754] __device_attach_driver+0xb8/0x134 [ 10.596188] bus_for_each_drv+0x84/0xe0 [ 10.600015] __device_attach+0x9c/0x188 [ 10.603841] device_initial_probe+0x14/0x20 [ 10.608015] bus_probe_device+0xac/0xb0 [ 10.611841] deferred_probe_work_func+0x88/0xc0 [ 10.616361] process_one_work+0x148/0x2a0 [ 10.620364] worker_thread+0x324/0x43c [ 10.624104] kthread+0x114/0x118 [ 10.627323] ret_from_fork+0x10/0x20 # Hardware platforms affected: ## mt8183-kukui-jacuzzi-juniper-sku16 - Compatibles: google,juniper-sku16 | google,juniper | mediatek,mt8183 - Dashboard: https://staging.dashboard.kernelci.org:9000/test/maestro:67a173d8661a7bc874… #kernelci issue maestro:18a6cd3bd705698b41106eef2a1d7f2e411c7aab Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 weeks, 3 days

1
0
0 0

stable-rc/linux-6.6.y: new boot regression: NULL pointer dereference at virtual address 000000000000...

by KernelCI bot

Hello, New boot regression found on stable-rc/linux-6.6.y: NULL pointer dereference at virtual address 0000000000000030 [logspec:generic_linux_boot,linux.kernel.null_pointer_dereference] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:295973ea60dd4385e… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:295973ea60dd4385e… Log excerpt: [ 4.896353] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 4.896354] Mem abort info: [ 4.896355] ESR = 0x0000000096000004 [ 4.896356] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.896357] SET = 0, FnV = 0 [ 4.896358] EA = 0, S1PTW = 0 [ 4.896358] FSC = 0x04: level 0 translation fault [ 4.896360] Data abort info: [ 4.896366] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.896367] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.896368] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.896369] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001089d9000 [ 4.896370] [0000000000000030] pgd=0000000000000000, p4d=0000000000000000 [ 4.896374] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.896376] Modules linked in: mtk_mdp3(+) v4l2_mem2mem joydev ecc pcie_mediatek_gen3(+) videobuf2_dma_contig elan_i2c mtk_svs lvts_thermal r8152(+) mii cros_ec_rpmsg snd_sof_mt8195 mtk_adsp_common snd_sof_xtensa_dsp mtk_scp snd_sof_of cros_ec_sensorhub cros_kbd_led_backlight mtk_rpmsg snd_sof rpmsg_core mt6359_auxadc snd_soc_mt8195_afe mt6577_auxadc snd_sof_utils mtk_scp_ipi mtk_wdt mt8195_mt6359 uvcvideo videobuf2_vmalloc uvc videobuf2_v4l2 videobuf2_memops videobuf2_common [ 4.896396] CPU: 7 UID: 0 PID: 207 Comm: (udev-worker) Not tainted 6.13.2-rc1 #1 8f7a24f5cbfa3d4f7c9dce5f7e52657669893a6c [ 4.896399] Hardware name: Acer Tomato (rev2) board (DT) [ 4.896400] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.896402] pc : klist_put+0x28/0xf0 [ 4.896410] lr : klist_iter_exit+0x24/0x38 [ 4.896412] sp : ffff800080cab810 [ 4.896412] x29: ffff800080cab810 x28: ffffc4e77c077518 x27: 0000000000000001 [ 4.896415] x26: ffff800080cabb10 x25: ffffc4e79fb98a50 x24: ffff1beb48832bb8 [ 4.896417] x23: ffffc4e79dedd540 x22: 0000000000000000 x21: ffffc4e79d6f8f00 [ 4.896418] x20: 0000000000000000 x19: ffff1beb41095178 x18: ffffffffffffffff [ 4.896420] x17: 656469762f766564 x16: ffffc4e79d6fb3f0 x15: 2d35393138746d2c [ 4.896422] x14: ffffc4e79fe0e750 x13: 616964656d43746f x12: 0000000000000000 [ 4.896424] x11: 00353639333d4d55 x10: 0000a8fc3b570378 x9 : ffffc4e79dd32458 [ 4.896426] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 5c175b1c0b544003 [ 4.896427] x5 : 0340540b1c5b175c x4 : 0000000000000000 x3 : 0000000014f08001 [ 4.896429] x2 : 00000000dead4ead x1 : 0000000000000000 x0 : 0000000000000000 [ 4.896431] Call trace: [ 4.896432] klist_put+0x28/0xf0 (P) [ 4.896435] klist_iter_exit+0x24/0x38 [ 4.896436] bus_for_each_dev+0x90/0xe8 [ 4.896440] driver_attach+0x2c/0x40 [ 4.896442] bus_add_driver+0xec/0x218 [ 4.896443] driver_register+0x68/0x138 [ 4.896445] __platform_driver_register+0x2c/0x40 [ 4.896447] mdp_driver_init+0x28/0xff8 [mtk_mdp3 368282916f4a555c99cbc06147f8cea6ac3d5634] [ 4.896452] do_one_initcall+0x60/0x320 [ 4.896455] do_init_module+0x60/0x238 [ 4.896458] load_module+0x1cf8/0x1de8 [ 4.896460] init_module_from_file+0x8c/0xd8 [ 4.896461] __arm64_sys_finit_module+0x150/0x338 [ 4.896463] invoke_syscall+0x70/0x100 [ 4.896466] el0_svc_common.constprop.0+0x48/0xf0 [ 4.896469] do_el0_svc+0x24/0x38 [ 4.896471] el0_svc+0x34/0xf0 [ 4.896473] el0t_64_sync_handler+0x10c/0x138 [ 4.896474] el0t_64_sync+0x1b0/0x1b8 [ 4.896477] Code: 12001c36 f9400014 927ffa94 aa1403e0 (f9401a95) # Hardware platforms affected: ## mt8195-cherry-tomato-r2 - Compatibles: google,tomato-rev2 | google,tomato | mediatek,mt8195 - Dashboard: https://staging.dashboard.kernelci.org:9000/test/maestro:67a12193661a7bc874… #kernelci issue maestro:295973ea60dd4385ec6b04faa6ddce9707f879a4 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 weeks, 3 days

1
0
0 0

[PATCH v3] tee: optee: Fix supplicant wait loop

by Sumit Garg

OP-TEE supplicant is a user-space daemon and it's possible for it be hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitely waiting in an unkillable state. Also, a normal uninterruptible wait should not have resulted in the hung-task watchdog getting triggered, but the endless loop would. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover. Fixes: 4fb0a5eb364d ("tee: add OP-TEE driver") Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- Changes in v3: - Use mutex_lock() instead of mutex_lock_killable(). - Update commit message to incorporate Arnd's feedback. Changes in v2: - Switch to killable wait instead as suggested by Arnd instead of supplicant timeout. It atleast allow the client to wait for supplicant in killable state which in turn allows system to reboot or shutdown gracefully. drivers/tee/optee/supp.c | 35 ++++++++--------------------------- 1 file changed, 8 insertions(+), 27 deletions(-) diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c index 322a543b8c27..d0f397c90242 100644 --- a/drivers/tee/optee/supp.c +++ b/drivers/tee/optee/supp.c @@ -80,7 +80,6 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, struct optee *optee = tee_get_drvdata(ctx->teedev); struct optee_supp *supp = &optee->supp; struct optee_supp_req *req; - bool interruptable; u32 ret; /* @@ -111,36 +110,18 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, /* * Wait for supplicant to process and return result, once we've * returned from wait_for_completion(&req->c) successfully we have - * exclusive access again. + * exclusive access again. Allow the wait to be killable such that + * the wait doesn't turn into an indefinite state if the supplicant + * gets hung for some reason. */ - while (wait_for_completion_interruptible(&req->c)) { + if (wait_for_completion_killable(&req->c)) { mutex_lock(&supp->mutex); - interruptable = !supp->ctx; - if (interruptable) { - /* - * There's no supplicant available and since the - * supp->mutex currently is held none can - * become available until the mutex released - * again. - * - * Interrupting an RPC to supplicant is only - * allowed as a way of slightly improving the user - * experience in case the supplicant hasn't been - * started yet. During normal operation the supplicant - * will serve all requests in a timely manner and - * interrupting then wouldn't make sense. - */ - if (req->in_queue) { - list_del(&req->link); - req->in_queue = false; - } + if (req->in_queue) { + list_del(&req->link); + req->in_queue = false; } mutex_unlock(&supp->mutex); - - if (interruptable) { - req->ret = TEEC_ERROR_COMMUNICATION; - break; - } + req->ret = TEEC_ERROR_COMMUNICATION; } ret = req->ret; -- 2.43.0

3 weeks, 3 days

3
2
0 0

[PATCH] arm64: dts: exynos: gs101: disable pinctrl_gsacore node

by Peter Griffin

gsacore registers are not accessible from normal world. Disable this node, so that the suspend/resume callbacks in the pinctrl driver don't cause a Serror attempting to access the registers. Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") Signed-off-by: Peter Griffin <peter.griffin(a)linaro.org> To: Rob Herring <robh(a)kernel.org> To: Krzysztof Kozlowski <krzk+dt(a)kernel.org> To: Conor Dooley <conor+dt(a)kernel.org> To: Alim Akhtar <alim.akhtar(a)samsung.com> Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-samsung-soc(a)vger.kernel.org Cc: devicetree(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: tudor.ambarus(a)linaro.org Cc: andre.draszik(a)linaro.org Cc: kernel-team(a)android.com Cc: willmcvicker(a)google.com Cc: stable(a)vger.kernel.org --- arch/arm64/boot/dts/exynos/google/gs101.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi index 302c5beb224a..b8f8255f840b 100644 --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi @@ -1451,6 +1451,7 @@ pinctrl_gsacore: pinctrl@17a80000 { /* TODO: update once support for this CMU exists */ clocks = <0>; clock-names = "pclk"; + status = "disabled"; }; cmu_top: clock-controller@1e080000 { --- base-commit: ed9a4ad6e5bd3a443e81446476718abebee47e82 change-id: 20241213-contrib-pg-pinctrl_gsacore_disable-3457c942b0fe Best regards, -- Peter Griffin <peter.griffin(a)linaro.org>

3 weeks, 3 days

2
1
0 0

Linux 6.6.76-rc1 regression due to crypto-api-fix-boot-up-self-test-race

by Barry K. Nathan

Compared to 6.6.75, 6.6.76-rc1 freezes up for roughly one minute during boot, and I think the log messages are indicating a crypto self-test failure afterward. I have tried it on two different computers (a Core 2 Duo-based PC and a Haswell-based 2015 15" MacBook Pro) and it happens 100% of the time on both. I bisected it down to crypto-api-fix-boot-up-self-test-race ("crypto: api - Fix boot-up self-test race"). Reverting that one patch from 6.6.76-rc1 fixes the regression for me. By the way, I also tested 6.13.2-rc1 and 6.12.13-rc1, and this bug did not reproduce on either. Log excerpt: [ 4.523861] ima: No TPM chip found, activating TPM-bypass! [ 4.534858] ima: Allocated hash algorithm: sha256 [ 4.544294] ima: No architecture policies found [ 4.553384] evm: Initialising EVM extended attributes: [ 4.563682] evm: security.selinux [ 4.570339] evm: security.SMACK64 (disabled) [ 4.578900] evm: security.SMACK64EXEC (disabled) [ 4.588156] evm: security.SMACK64TRANSMUTE (disabled) [ 4.598279] evm: security.SMACK64MMAP (disabled) [ 4.607534] evm: security.apparmor [ 4.614363] evm: security.ima [ 4.620326] evm: security.capability [ 4.627502] evm: HMAC attrs: 0x1 [ 65.685967] random: crng init done [ 68.452968] DRBG: could not allocate digest TFM handle: hmac(sha512) [ 68.465701] alg: drbg: Failed to reset rng [ 68.473914] alg: drbg: Test 0 failed for drbg_nopr_hmac_sha512 [ 68.485595] alg: self-tests for stdrng using drbg_nopr_hmac_sha512 failed (rc=-22) [ 68.485597] ------------[ cut here ]------------ [ 68.510017] alg: self-tests for stdrng using drbg_nopr_hmac_sha512 failed (rc=-22) [ 68.510035] WARNING: CPU: 1 PID: 78 at crypto/testmgr.c:5936 alg_test+0x49e/0x610 [ 68.540198] Modules linked in: [ 68.546332] CPU: 1 PID: 78 Comm: cryptomgr_test Not tainted 6.6.76-rc1 #1 [ 68.559920] Hardware name: Gigabyte Technology Co., Ltd. G41MT-S2PT/G41MT-S2PT, BIOS F2 12/06/2011 [ 68.579005] RIP: 0010:alg_test+0x49e/0x610 [ 68.587220] Code: de 48 89 df 89 04 24 e8 70 ed fe ff 44 8b 0c 24 e9 bc fc ff ff 44 89 c9 48 89 ea 4c 89 ee 48 c7 c7 80 9a ed ad e8 f2 74 b2 ff <0f> 0b 44 8b 0c 24 e9 a1 fe ff ff 8b 05 21 04 c2 01 85 c0 74 56 83 [ 68.624782] RSP: 0018:ffffbc8380307e10 EFLAGS: 00010286 [ 68.635252] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: c0000000ffffefff [ 68.649534] RDX: 0000000000000000 RSI: 00000000ffffefff RDI: 0000000000000001 [ 68.663816] RBP: ffffa01c47be0200 R08: 0000000000000000 R09: ffffbc8380307c98 [ 68.678100] R10: 0000000000000003 R11: ffffffffae0d1368 R12: 0000000000000058 [ 68.692384] R13: ffffa01c47be0280 R14: 0000000000000058 R15: 0000000000000058 [ 68.706665] FS: 0000000000000000(0000) GS:ffffa01d37c80000(0000) knlGS:0000000000000000 [ 68.722871] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 68.734381] CR2: 00007ff2f64622e0 CR3: 0000000146c20000 CR4: 00000000000406e0 [ 68.748664] Call Trace: [ 68.753588] <TASK> [ 68.757817] ? alg_test+0x49e/0x610 [ 68.764817] ? __warn+0x81/0x130 [ 68.771301] ? alg_test+0x49e/0x610 [ 68.778304] ? report_bug+0x171/0x1a0 [ 68.785652] ? console_unlock+0x78/0x120 [ 68.793521] ? handle_bug+0x58/0x90 [ 68.800525] ? exc_invalid_op+0x17/0x70 [ 68.808221] ? asm_exc_invalid_op+0x1a/0x20 [ 68.816611] ? alg_test+0x49e/0x610 [ 68.823614] ? finish_task_switch.isra.0+0x90/0x2d0 [ 68.833390] ? __schedule+0x3c8/0xb00 [ 68.840739] ? __pfx_cryptomgr_test+0x10/0x10 [ 68.849473] cryptomgr_test+0x24/0x40 [ 68.856824] kthread+0xe5/0x120 [ 68.863133] ? __pfx_kthread+0x10/0x10 [ 68.870656] ret_from_fork+0x31/0x50 [ 68.877832] ? __pfx_kthread+0x10/0x10 [ 68.885354] ret_from_fork_asm+0x1b/0x30 [ 68.893226] </TASK> [ 68.897626] ---[ end trace 0000000000000000 ]--- -- -Barry K. Nathan <barryn(a)pobox.com>

3 weeks, 3 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror