- May 15, 2021
-
-
Peter Zijlstra authored
This came up in the discussion of the requirements of qspinlock on an architecture. OpenRISC uses qspinlock, but it was noticed that the memmory barrier was not defined. Peter defined it in the mail thread writing: As near as I can tell this should do. The arch spec only lists this one instruction and the text makes it sound like a completion barrier. This is correct so applying this patch. Signed-off-by:
Peter Zijlstra <peterz@infradead.org> [shorne@gmail.com:Turned the mail into a patch] Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
- May 09, 2021
-
-
Mike Rapoport authored
A build with W=1 enabled produces the following warning: CC arch/openrisc/mm/init.o arch/openrisc/mm/init.c: In function 'paging_init': arch/openrisc/mm/init.c:131:16: warning: variable 'end' set but not used [-Wunused-but-set-variable] 131 | unsigned long end; | ^~~ Remove the unused variable 'end'. Signed-off-by:
Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
Mike Rapoport authored
Kernel test robot reports: cppcheck possible warnings: (new ones prefixed by >>, may not real problems) >> arch/openrisc/mm/init.c:125:10: warning: Uninitialized variable: region [uninitvar] region->base, region->base + region->size); ^ Replace usage of memblock_region fields with 'start' and 'end' variables that are initialized in for_each_mem_range() and remove the declaration of region. Fixes: b10d6bca ("arch, drivers: replace for_each_membock() with for_each_mem_range()") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
- May 07, 2021
-
-
David Hildenbrand authored
Patch series "drivers/char: remove /dev/kmem for good". Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug and memory ballooning, I started questioning the existence of /dev/kmem. Comparing it with the /proc/kcore implementation, it does not seem to be able to deal with things like a) Pages unmapped from the direct mapping (e.g., to be used by secretmem) -> kern_addr_valid(). virt_addr_valid() is not sufficient. b) Special cases like gart aperture memory that is not to be touched -> mem_pfn_is_ram() Unless I am missing something, it's at least broken in some cases and might fault/crash the machine. Looks like its existence has been questioned before in 2005 and 2010 [1], after ~11 additional years, it might make sense to revive the discussion. CONFIG_DEVKMEM is only enabled in a single defconfig (on purpose or by mistake?). All distributions disable it: in Ubuntu it has been disabled for more than 10 years, in Debian since 2.6.31, in Fedora at least starting with FC3, in RHEL starting with RHEL4, in SUSE starting from 15sp2, and OpenSUSE has it disabled as well. 1) /dev/kmem was popular for rootkits [2] before it got disabled basically everywhere. Ubuntu documents [3] "There is no modern user of /dev/kmem any more beyond attackers using it to load kernel rootkits.". RHEL documents in a BZ [5] "it served no practical purpose other than to serve as a potential security problem or to enable binary module drivers to access structures/functions they shouldn't be touching" 2) /proc/kcore is a decent interface to have a controlled way to read kernel memory for debugging puposes. (will need some extensions to deal with memory offlining/unplug, memory ballooning, and poisoned pages, though) 3) It might be useful for corner case debugging [1]. KDB/KGDB might be a better fit, especially, to write random memory; harder to shoot yourself into the foot. 4) "Kernel Memory Editor" [4] hasn't seen any updates since 2000 and seems to be incompatible with 64bit [1]. For educational purposes, /proc/kcore might be used to monitor value updates -- or older kernels can be used. 5) It's broken on arm64, and therefore, completely disabled there. Looks like it's essentially unused and has been replaced by better suited interfaces for individual tasks (/proc/kcore, KDB/KGDB). Let's just remove it. [1] https://lwn.net/Articles/147901/ [2] https://www.linuxjournal.com/article/10505 [3] https://wiki.ubuntu.com/Security/Features#A.2Fdev.2Fkmem_disabled [4] https://sourceforge.net/projects/kme/ [5] https://bugzilla.redhat.com/show_bug.cgi?id=154796 Link: https://lkml.kernel.org/r/20210324102351.6932-1-david@redhat.com Link: https://lkml.kernel.org/r/20210324102351.6932-2-david@redhat.com Signed-off-by:
David Hildenbrand <david@redhat.com> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Alexander A. Klimov" <grandmaster@al2klimov.de> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Brian Cain <bcain@codeaurora.org> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Chris Zankel <chris@zankel.net> Cc: Corentin Labbe <clabbe@baylibre.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: Greentime Hu <green.hu@gmail.com> Cc: Gregory Clement <gregory.clement@bootlin.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Helge Deller <deller@gmx.de> Cc: Hillf Danton <hdanton@sina.com> Cc: huang ying <huang.ying.caritas@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: James Troup <james.troup@canonical.com> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Jonas Bonn <jonas@southpole.se> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Kairui Song <kasong@redhat.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Matt Turner <mattst88@gmail.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Mike Rapoport <rppt@kernel.org> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Niklas Schnelle <schnelle@linux.ibm.com> Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com> Cc: openrisc@lists.librecores.org Cc: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Paul Mackerras <paulus@samba.org> Cc: "Pavel Machek (CIP)" <pavel@denx.de> Cc: Pavel Machek <pavel@ucw.cz> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> Cc: Pierre Morel <pmorel@linux.ibm.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Rich Felker <dalias@libc.org> Cc: Robert Richter <rric@kernel.org> Cc: Rob Herring <robh@kernel.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: sparclinux@vger.kernel.org Cc: Stafford Horne <shorne@gmail.com> Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Theodore Dubois <tblodt@icloud.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: William Cohen <wcohen@redhat.com> Cc: Xiaoming Ni <nixiaoming@huawei.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Apr 30, 2021
-
-
Kefeng Wang authored
mem_init_print_info() is called in mem_init() on each architecture, and pass NULL argument, so using void argument and move it into mm_init(). Link: https://lkml.kernel.org/r/20210317015210.33641-1-wangkefeng.wang@huawei.com Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> [x86] Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr> [powerpc] Acked-by:
David Hildenbrand <david@redhat.com> Tested-by: Anatoly Pugachev <matorola@gmail.com> [sparc64] Acked-by: Russell King <rmk+kernel@armlinux.org.uk> [arm] Acked-by:
Mike Rapoport <rppt@linux.ibm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Guo Ren <guoren@kernel.org> Cc: Yoshinori Sato <ysato@users.osdn.me> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: Jonas Bonn <jonas@southpole.se> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: "Peter Zijlstra" <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Apr 28, 2021
-
-
Christophe JAILLET authored
'setup_find_cpu_node()' take a reference on the node it returns. This reference must be decremented when not needed anymore, or there will be a leak. Add the missing 'of_node_put(cpu)'. Note that 'setup_cpuinfo()' that also calls this function already has a correct 'of_node_put(cpu)' at its end. Fixes: 9d02a428 ("OpenRISC: Boot code") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
- Feb 22, 2021
-
-
Jens Axboe authored
PF_IO_WORKER are kernel threads too, but they aren't PF_KTHREAD in the sense that we don't assign ->set_child_tid with our own structure. Just ensure that every arch sets up the PF_IO_WORKER threads like kthreads in the arch implementation of copy_thread(). Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- Feb 08, 2021
-
-
Jan Henrik Weinstock authored
Use the device tree to determine the present cpus instead of assuming all CONFIG_NRCPUS are actually present in the system. Signed-off-by:
Jan Henrik Weinstock <jan.weinstock@rwth-aachen.de> [shorne: Squashed 2 email commits and added summary from email] Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
- Jan 19, 2021
-
-
Geert Uytterhoeven authored
With C=1: drivers/soc/renesas/rmobile-sysc.c:330:33: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void *addr @@ got void [noderef] __iomem *[assigned] base @@ drivers/soc/renesas/rmobile-sysc.c:330:33: sparse: expected void *addr drivers/soc/renesas/rmobile-sysc.c:330:33: sparse: got void [noderef] __iomem *[assigned] base Fix this by adding the missing __iomem annotation to iounmap(). Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
- Jan 18, 2021
-
-
Masahiro Yamada authored
Describe the subdirectories under arch/openrisc/ in arch/openrisc/Kbuild so you can use the standard obj-y syntax. I removed the CONFIG_OPENRISC_BUILTIN_DTB conditional because it is already controlled by arch/openrisc/boot/dts/Makefile. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
- Jan 01, 2021
-
-
Joel Stanley authored
Currently openrisc will print a message and then hang in an infinite loop when rebooting. This patch adopts some code from ARM, which calls the common restart infrastructure and hangs after a small delay if the restart infra doesn't do anything. Signed-off-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
Joel Stanley authored
Build it by default. This is commonly used by fpga targets. Signed-off-by:
Joel Stanley <joel@jms.id.au> Reviewed-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
- Dec 29, 2020
-
-
Randy Dunlap authored
Make <asm-generic/local64.h> mandatory in include/asm-generic/Kbuild and remove all arch/*/include/asm/local64.h arch-specific files since they only #include <asm-generic/local64.h>. This fixes build errors on arch/c6x/ and arch/nios2/ for block/blk-iocost.c. Build-tested on 21 of 25 arch-es. (tools problems on the others) Yes, we could even rename <asm-generic/local64.h> to <linux/local64.h> and change all #includes to use <linux/local64.h> instead. Link: https://lkml.kernel.org/r/20201227024446.17018-1-rdunlap@infradead.org Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Suggested-by:
Christoph Hellwig <hch@infradead.org> Reviewed-by:
Masahiro Yamada <masahiroy@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Ley Foon Tan <ley.foon.tan@intel.com> Cc: Mark Salter <msalter@redhat.com> Cc: Aurelien Jacquiot <jacquiot.aurelien@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Nov 24, 2020
-
-
Peter Zijlstra authored
We call arch_cpu_idle() with RCU disabled, but then use local_irq_{en,dis}able(), which invokes tracing, which relies on RCU. Switch all arch_cpu_idle() implementations to use raw_local_irq_{en,dis}able() and carefully manage the lockdep,rcu,tracing state like we do in entry. (XXX: we really should change arch_cpu_idle() to not return with interrupts enabled) Reported-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Tested-by:
Mark Rutland <mark.rutland@arm.com> Link: https://lkml.kernel.org/r/20201120114925.594122626@infradead.org
-
- Nov 20, 2020
-
-
Stafford Horne authored
As of 5.10 OpenRISC allyesconfig builds fail with the following error. $ make ARCH=openrisc CROSS_COMPILE=or1k-elf- block/blk-iocost.o CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh CC block/blk-iocost.o block/blk-iocost.c:183:10: fatal error: asm/local64.h: No such file or directory 183 | #include <asm/local64.h> | ^~~~~~~~~~~~~~~ compilation terminated. The new include of local64.h was added in commit 5e124f74 ("blk-iocost: use local[64]_t for percpu stat") by Tejun. Adding the generic version of local64.h to OpenRISC fixes the build issue. Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
- Nov 11, 2020
-
-
Stafford Horne authored
I have been working on getting native Linux GDB support working for the OpenRISC port. The trap signal handler here was wrong in a few ways. During trap handling address (from the EEAR register) is not set by the CPU, so it is not correct to use here. We want to use trap as a break-point so use TRAP_BRKPT. Adding 4 to the pc was incorrect and causing GDB to think the breakpoint was not hit. Fixing these allows GDB to work now. Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
Filip Kokosinski authored
This adds support for a basic LiteX-based SoC with a mor1kx soft CPU. Signed-off-by:
Filip Kokosinski <fkokosinski@antmicro.com> Signed-off-by:
Mateusz Holenko <mholenko@antmicro.com> [shorne: Merged in soc-cntl patch, removed CROSS_COMPILE, sort MAINT.] Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
- Nov 09, 2020
-
-
Jens Axboe authored
Wire up TIF_NOTIFY_SIGNAL handling for openrisc. Cc: openrisc@lists.librecores.org Acked-by:
Stafford Horne <shorne@gmail.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- Nov 06, 2020
-
-
Thomas Gleixner authored
The header is not longer used and on alpha, ia64, openrisc, parisc and um it was completely unused anyway as these architectures have no highmem support. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Christoph Hellwig <hch@lst.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20201103095858.422094352@linutronix.de
-
- Oct 30, 2020
-
-
Arnd Bergmann authored
Almost all machines use GENERIC_CLOCKEVENTS, so it feels wrong to require each one to select that symbol manually. Instead, enable it whenever CONFIG_LEGACY_TIMER_TICK is disabled as a simplification. It should be possible to select both GENERIC_CLOCKEVENTS and LEGACY_TIMER_TICK from an architecture now and decide at runtime between the two. For the clockevents arch-support.txt file, this means that additional architectures are marked as TODO when they have at least one machine that still uses LEGACY_TIMER_TICK, rather than being marked 'ok' when at least one machine has been converted. This means that both m68k and arm (for riscpc) revert to TODO. At this point, we could just always enable CONFIG_GENERIC_CLOCKEVENTS rather than leaving it off when not needed. I built an m68k defconfig kernel (using gcc-10.1.0) and found that this would add around 5.5KB in kernel image size: text data bss dec hex filename 3861936 1092236 196656 5150828 4e986c obj-m68k/vmlinux-no-clockevent 3866201 1093832 196184 5156217 4ead79 obj-m68k/vmlinux-clockevent On Arm (MACH_RPC), that difference appears to be twice as large, around 11KB on top of an 6MB vmlinux. Reviewed-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Tested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
- Oct 27, 2020
-
-
Nicholas Piggin authored
Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Cc: Jonas Bonn <jonas@southpole.se> Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Cc: Stafford Horne <shorne@gmail.com> Cc: openrisc@lists.librecores.org Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
- Oct 17, 2020
-
-
Jens Axboe authored
All the callers currently do this, clean it up and move the clearing into tracehook_notify_resume() instead. Reviewed-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- Oct 14, 2020
-
-
Mike Rapoport authored
There are several occurrences of the following pattern: for_each_memblock(memory, reg) { start = __pfn_to_phys(memblock_region_memory_base_pfn(reg); end = __pfn_to_phys(memblock_region_memory_end_pfn(reg)); /* do something with start and end */ } Using for_each_mem_range() iterator is more appropriate in such cases and allows simpler and cleaner code. [akpm@linux-foundation.org: fix arch/arm/mm/pmsa-v7.c build] [rppt@linux.ibm.com: mips: fix cavium-octeon build caused by memblock refactoring] Link: http://lkml.kernel.org/r/20200827124549.GD167163@linux.ibm.com Signed-off-by:
Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Baoquan He <bhe@redhat.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Daniel Axtens <dja@axtens.net> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Emil Renner Berthing <kernel@esmil.dk> Cc: Hari Bathini <hbathini@linux.ibm.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Simek <monstr@monstr.eu> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Stafford Horne <shorne@gmail.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Link: https://lkml.kernel.org/r/20200818151634.14343-13-rppt@kernel.org Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Mike Rapoport authored
Instead of traversing memblock.memory regions to find memory_start and memory_end, simply query memblock_{start,end}_of_DRAM(). Signed-off-by:
Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Stafford Horne <shorne@gmail.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Baoquan He <bhe@redhat.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Daniel Axtens <dja@axtens.net> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Emil Renner Berthing <kernel@esmil.dk> Cc: Hari Bathini <hbathini@linux.ibm.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Simek <monstr@monstr.eu> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Link: https://lkml.kernel.org/r/20200818151634.14343-6-rppt@kernel.org Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Oct 06, 2020
-
-
Christoph Hellwig authored
Move more nitty gritty DMA implementation details into the common internal header. Signed-off-by:
Christoph Hellwig <hch@lst.de>
-
- Sep 12, 2020
-
-
Stafford Horne authored
A build failure was raised by kbuild with the following error. drivers/android/binder.c: Assembler messages: drivers/android/binder.c:3861: Error: unrecognized keyword/register name `l.lwz ?ap,4(r24)' drivers/android/binder.c:3866: Error: unrecognized keyword/register name `l.addi ?ap,r0,0' The issue is with 64-bit get_user() calls on openrisc. I traced this to a problem where in the internally in the get_user macros there is a cast to long __gu_val this causes GCC to think the get_user call is 32-bit. This binder code is really long and GCC allocates register r30, which triggers the issue. The 64-bit get_user asm tries to get the 64-bit pair register, which for r30 overflows the general register names and returns the dummy register ?ap. The fix here is to move the temporary variables into the asm macros. We use a 32-bit __gu_tmp for 32-bit and smaller macro and a 64-bit tmp in the 64-bit macro. The cast in the 64-bit macro has a trick of casting through __typeof__((x)-(x)) which avoids the below warning. This was barrowed from riscv. arch/openrisc/include/asm/uaccess.h:240:8: warning: cast to pointer from integer of different size I tested this in a small unit test to check reading between 64-bit and 32-bit pointers to 64-bit and 32-bit values in all combinations. Also I ran make C=1 to confirm no new sparse warnings came up. It all looks clean to me. Link: https://lore.kernel.org/lkml/202008200453.ohnhqkjQ%25lkp@intel.com/ Signed-off-by:
Stafford Horne <shorne@gmail.com> Reviewed-by:
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
-
- Sep 09, 2020
-
-
Christoph Hellwig authored
Add a CONFIG_SET_FS option that is selected by architecturess that implement set_fs, which is all of them initially. If the option is not set stubs for routines related to overriding the address space are provided so that architectures can start to opt out of providing set_fs. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
- Sep 07, 2020
-
-
Stafford Horne authored
I found this when compiling a kbuild random config with GCC 11. The config enables CONFIG_DEBUG_SECTION_MISMATCH, which sets CFLAGS -fno-inline-functions-called-once. This causes the call to cache_loop in cache.c to not be inlined causing the below compile error. In file included from arch/openrisc/mm/cache.c:13: arch/openrisc/mm/cache.c: In function 'cache_loop': ./arch/openrisc/include/asm/spr.h:16:27: warning: 'asm' operand 0 probably does not match constraints 16 | #define mtspr(_spr, _val) __asm__ __volatile__ ( \ | ^~~~~~~ arch/openrisc/mm/cache.c:25:3: note: in expansion of macro 'mtspr' 25 | mtspr(reg, line); | ^~~~~ ./arch/openrisc/include/asm/spr.h:16:27: error: impossible constraint in 'asm' 16 | #define mtspr(_spr, _val) __asm__ __volatile__ ( \ | ^~~~~~~ arch/openrisc/mm/cache.c:25:3: note: in expansion of macro 'mtspr' 25 | mtspr(reg, line); | ^~~~~ make[1]: *** [scripts/Makefile.build:283: arch/openrisc/mm/cache.o] Error 1 The asm constraint "K" requires a immediate constant argument to mtspr, however because of no inlining a register argument is passed causing a failure. Fix this by using __always_inline. Link: https://lore.kernel.org/lkml/202008200453.ohnhqkjQ%25lkp@intel.com/ Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
Stafford Horne authored
Recently OpenRISC added support for external initrd images, but I found some instability when using larger buildroot initrd images. It turned out that I forgot to reserve the memblock space for the initrd image. This patch fixes the instability issue by reserving memblock space. Fixes: ff6c923d ("openrisc: Add support for external initrd images") Signed-off-by:
Stafford Horne <shorne@gmail.com> Reviewed-by:
Mike Rapoport <rppt@linux.ibm.com>
-
- Sep 01, 2020
-
-
Kees Cook authored
The .comment section doesn't belong in STABS_DEBUG. Split it out into a new macro named ELF_DETAILS. This will gain other non-debug sections that need to be accounted for when linking with --orphan-handling=warn. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: linux-arch@vger.kernel.org Link: https://lore.kernel.org/r/20200821194310.3089815-5-keescook@chromium.org
-
- Aug 23, 2020
-
-
Gustavo A. R. Silva authored
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org>
-
- Aug 12, 2020
-
-
Peter Xu authored
Use the general page fault accounting by passing regs into handle_mm_fault(). It naturally solve the issue of multiple page fault accounting when page fault retry happened. Add the missing PERF_COUNT_SW_PAGE_FAULTS perf events too. Note, the other two perf events (PERF_COUNT_SW_PAGE_FAULTS_[MAJ|MIN]) were done in handle_mm_fault(). Signed-off-by:
Peter Xu <peterx@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Stafford Horne <shorne@gmail.com> Cc: Jonas Bonn <jonas@southpole.se> Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Link: http://lkml.kernel.org/r/20200707225021.200906-15-peterx@redhat.com Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Peter Xu authored
Patch series "mm: Page fault accounting cleanups", v5. This is v5 of the pf accounting cleanup series. It originates from Gerald Schaefer's report on an issue a week ago regarding to incorrect page fault accountings for retried page fault after commit 4064b982 ("mm: allow VM_FAULT_RETRY for multiple times"): https://lore.kernel.org/lkml/20200610174811.44b94525@thinkpad/ What this series did: - Correct page fault accounting: we do accounting for a page fault (no matter whether it's from #PF handling, or gup, or anything else) only with the one that completed the fault. For example, page fault retries should not be counted in page fault counters. Same to the perf events. - Unify definition of PERF_COUNT_SW_PAGE_FAULTS: currently this perf event is used in an adhoc way across different archs. Case (1): for many archs it's done at the entry of a page fault handler, so that it will also cover e.g. errornous faults. ...
-
Christoph Hellwig authored
segment_eq is only used to implement uaccess_kernel. Just open code uaccess_kernel in the arch uaccess headers and remove one layer of indirection. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Acked-by:
Greentime Hu <green.hu@gmail.com> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Nick Hu <nickhu@andestech.com> Cc: Vincent Chen <deanbo422@gmail.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Link: http://lkml.kernel.org/r/20200710135706.537715-5-hch@lst.de Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Aug 08, 2020
-
-
Stafford Horne authored
Now that __user annotations are fixed for openrisc uaccess api's we can add checking to the access_ok macro. This patch adds the __chk_user_ptr check, on normal builds the added check is a nop. Signed-off-by:
Stafford Horne <shorne@gmail.com> Reviewed-by:
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
-
Stafford Horne authored
The __user annotations in signal.c were mostly missing. The missing annotations caused the warnings listed below. This patch fixes them up by adding the __user annotations. arch/openrisc/kernel/signal.c:71:38: warning: incorrect type in initializer (different address spaces) arch/openrisc/kernel/signal.c:71:38: expected struct rt_sigframe *frame arch/openrisc/kernel/signal.c:71:38: got struct rt_sigframe [noderef] __user * arch/openrisc/kernel/signal.c:82:14: warning: incorrect type in argument 1 (different address spaces) arch/openrisc/kernel/signal.c:82:14: expected void const volatile [noderef] __user * arch/openrisc/kernel/signal.c:82:14: got struct rt_sigframe *frame arch/openrisc/kernel/signal.c:84:37: warning: incorrect type in argument 2 (different address spaces) arch/openrisc/kernel/signal.c:84:37: expected void const [noderef] __user *from arch/openrisc/kernel/signal.c:84:37: got struct sigset_t * arch/openrisc/kernel/signal.c:89:39: warning: incorrect type in argument 2 (different address spaces) arch/openrisc/kernel/signal.c:89:39: expected struct sigcontext [noderef] __user *sc arch/openrisc/kernel/signal.c:89:39: got struct sigcontext * arch/openrisc/kernel/signal.c:92:31: warning: incorrect type in argument 1 (different address spaces) arch/openrisc/kernel/signal.c:92:31: expected struct sigaltstack const [noderef] [usertype] __user * arch/openrisc/kernel/signal.c:92:31: got struct sigaltstack * arch/openrisc/kernel/signal.c:158:15: warning: incorrect type in assignment (different address spaces) arch/openrisc/kernel/signal.c:158:15: expected struct rt_sigframe *frame arch/openrisc/kernel/signal.c:158:15: got void [noderef] __user * arch/openrisc/kernel/signal.c:160:14: warning: incorrect type in argument 1 (different address spaces) arch/openrisc/kernel/signal.c:160:14: expected void const volatile [noderef] __user * arch/openrisc/kernel/signal.c:160:14: got struct rt_sigframe *frame arch/openrisc/kernel/signal.c:165:46: warning: incorrect type in argument 1 (different address spaces) arch/openrisc/kernel/signal.c:165:46: expected struct siginfo [noderef] [usertype] __user *to arch/openrisc/kernel/signal.c:165:46: got struct siginfo * arch/openrisc/kernel/signal.c:170:33: warning: incorrect type in argument 1 (different address spaces) arch/openrisc/kernel/signal.c:170:33: expected struct sigaltstack [noderef] [usertype] __user * arch/openrisc/kernel/signal.c:170:33: got struct sigaltstack * arch/openrisc/kernel/signal.c:171:40: warning: incorrect type in argument 2 (different address spaces) arch/openrisc/kernel/signal.c:171:40: expected struct sigcontext [noderef] __user *sc arch/openrisc/kernel/signal.c:171:40: got struct sigcontext * arch/openrisc/kernel/signal.c:173:32: warning: incorrect type in argument 1 (different address spaces) arch/openrisc/kernel/signal.c:173:32: expected void [noderef] __user *to arch/openrisc/kernel/signal.c:173:32: got struct sigset_t * Signed-off-by:
Stafford Horne <shorne@gmail.com> Reviewed-by:
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
-
Stafford Horne authored
Since commit b48b2c3e ("openrisc: use generic strnlen_user() function") the macro __addr_ok is no longer used. It is safe to remove so this patch removes it. Signed-off-by:
Stafford Horne <shorne@gmail.com>
-
Stafford Horne authored
As suggested by Linus when reviewing commit 9cb2feb4 ("arch/openrisc: Fix issues with access_ok()") last year; making __range_ok an inline function also fixes the used twice issue that the commit was fixing. I agree it's a good cleanup. This patch addresses that as I am currently working on the access_ok macro to fixup sparse annotations in OpenRISC. Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Stafford Horne <shorne@gmail.com> Reviewed-by:
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
-
Stafford Horne authored
The OpenRISC user access functions put_user(), get_user() and clear_user() were missing proper sparse annotations. This generated warnings like the below. This patch adds the annotations to fix the warnings. Example warnings: net/ipv4/ip_sockglue.c:759:29: warning: incorrect type in argument 1 (different address spaces) net/ipv4/ip_sockglue.c:759:29: expected void const volatile [noderef] __user * net/ipv4/ip_sockglue.c:759:29: got int const *__gu_addr net/ipv4/ip_sockglue.c:764:29: warning: incorrect type in initializer (different address spaces) net/ipv4/ip_sockglue.c:764:29: expected unsigned char const *__gu_addr net/ipv4/ip_sockglue.c:764:29: got unsigned char [noderef] __user * Signed-off-by:
Stafford Horne <shorne@gmail.com> Reviewed-by:
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
-
- Aug 07, 2020
-
-
Mike Rapoport authored
Replace pte_alloc_one(), pte_free() and pte_free_kernel() with the generic implementation. The only actual functional change is the addition of __GFP_ACCOUT for the allocation of the user page tables. The pte_alloc_one_kernel() is kept back because its implementation on openrisc is different than the generic one. Signed-off-by:
Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Reviewed-by:
Pekka Enberg <penberg@kernel.org> Acked-by:
Stafford Horne <shorne@gmail.com> Cc: Abdul Haleem <abdhalee@linux.vnet.ibm.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Joerg Roedel <joro@8bytes.org> Cc: Joerg Roedel <jroedel@suse.de> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Matthew Wilcox <willy@infradead.org> Link: http://lkml.kernel.org/r/20200627143453.31835-3-rppt@kernel.org Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-