lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 15 Jul 2020 09:46:33 +0200 From: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de> To: Geert Uytterhoeven <geert@...ux-m68k.org> Cc: Rich Felker <dalias@...c.org>, Christoph Hellwig <hch@....de>, Yoshinori Sato <ysato@...rs.sourceforge.jp>, Linux-sh list <linux-sh@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: ioremap and dma cleanups and fixes for superh (2nd resend) On 7/15/20 9:27 AM, Geert Uytterhoeven wrote: >> [ 5.464000] WARNING: CPU: 0 PID: 1 at mm/slab.c:2589 cache_alloc_refill+0x216/0x6a0 >> [ 5.464000] Modules linked in: >> [ 5.464000] >> [ 5.464000] CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc5-00026-g22b7a96ece82 #3 >> [ 5.464000] PC is at cache_alloc_refill+0x216/0x6a0 >> [ 5.464000] PR is at kmem_cache_alloc+0xd6/0x128 >> [ 5.464000] PC : 800ec0d2 SP : 9f445e68 SR : 400080f0 >> [ 5.464000] TEA : c00c30d0 >> [ 5.464000] R0 : 8062724c R1 : 8000fee8 R2 : 9f403540 R3 : 00000100 >> [ 5.464000] R4 : 9f403500 R5 : 00000000 R6 : 8068d5b0 R7 : 007fffff >> [ 5.464000] R8 : 0000000c R9 : 9f403500 R10 : 8096fc0c R11 : 80044410 >> [ 5.464000] R12 : 9f405060 R13 : 00000dc0 R14 : 9f445e68 >> [ 5.464000] MACH: 10623bba MACL: 00000cc0 GBR : 2957bd58 PR : 800ec80a >> [ 5.464000] >> [ 5.464000] Call trace: >> [ 5.464000] [<(ptrval)>] _raw_spin_unlock_irqrestore+0x0/0x54 >> [ 5.464000] [<(ptrval)>] _raw_spin_lock_irqsave+0x0/0x44 >> [ 5.464000] [<(ptrval)>] kmem_cache_alloc+0xd6/0x128 >> [ 5.464000] [<(ptrval)>] arch_local_irq_restore+0x0/0x2c >> [ 5.464000] [<(ptrval)>] __raw_spin_lock_init+0x0/0x1c >> [ 5.464000] [<(ptrval)>] pgd_alloc+0x10/0x24 > > Does commit 73c348f31b63d28d ("sh: Fix unneeded constructor in page > table allocation") in next-20200710 and later fix that? Indeed, it does. This patch should be picked up as well. Kernel boots without any errors now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@...ian.org `. `' Freie Universitaet Berlin - glaubitz@...sik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Powered by blists - more mailing lists