- 06 11月, 2017 2 次提交
-
-
由 Mark Rutland 提交于
When CONFIG_DEBUG_USER is enabled, it's possible for a user to deliberately trigger dump_instr() with a chosen kernel address. Let's avoid problems resulting from this by using get_user() rather than __get_user(), ensuring that we don't erroneously access kernel memory. So that we can use the same code to dump user instructions and kernel instructions, the common dumping code is factored out to __dump_instr(), with the fs manipulated appropriately in dump_instr() around calls to this. Signed-off-by: NMark Rutland <mark.rutland@arm.com> Cc: stable@vger.kernel.org Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
由 Nicolas Pitre 提交于
Some terminals apparently have issues with "\n\r" and mess up the display. Let's use the traditional "\r\n" ordering. Signed-off-by: NNicolas Pitre <nico@linaro.org> Reported-by: NChris Brandt <Chris.Brandt@renesas.com> Tested-by: NChris Brandt <Chris.Brandt@renesas.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
- 02 11月, 2017 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 23 10月, 2017 3 次提交
-
-
由 Vladimir Murzin 提交于
Currently, there is assumption in early MPU setup code that kernel image is located in RAM, which is obviously not true for XIP. To run code from ROM we need to make sure that it is covered by MPU. However, due to we allocate regions (semi-)dynamically we can run into issue of trimming region we are running from in case ROM spawns several MPU regions. To help deal with that we enforce minimum alignments for start end end of XIP address space as 1MB and 128Kb correspondingly. Tested-by: NAlexandre TORGUE <alexandre.torgue@st.com> Tested-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
由 Vladimir Murzin 提交于
This patch makes it possible to use MPU with v7M cores. Tested-by: NSzemző András <sza@esh.hu> Tested-by: NAlexandre TORGUE <alexandre.torgue@st.com> Tested-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
由 Vladimir Murzin 提交于
Currently, there are several issues with how MPU is setup: 1. We won't boot if MPU is missing 2. We won't boot if use XIP 3. Further extension of MPU setup requires asm skills The 1st point can be relaxed, so we can continue with boot CPU even if MPU is missed and fail boot for secondaries only. To address the 2nd point we could create region covering CONFIG_XIP_PHYS_ADDR - _end and that might work for the first stage of MPU enable, but due to MPU's alignment requirement we could cover too much, IOW we need more flexibility in how we're partitioning memory regions... and it'd be hardly possible to archive because of the 3rd point. This patch is trying to address 1st and 3rd issues and paves the path for 2nd and further improvements. The most visible change introduced with this patch is that we start using mpu_rgn_info array (as it was supposed?), so change in MPU setup done by boot CPU is recorded there and feed to secondaries. It allows us to keep minimal region setup for boot CPU and do the rest in C. Since we start programming MPU regions in C evaluation of MPU constrains (number of regions supported and minimal region order) can be done once, which in turn open possibility to free-up "probe" region early. Tested-by: NSzemző András <sza@esh.hu> Tested-by: NAlexandre TORGUE <alexandre.torgue@st.com> Tested-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
- 14 10月, 2017 1 次提交
-
-
由 Geert Uytterhoeven 提交于
If CONFIG_DEBUG_LOCK_ALLOC=y, the kernel log is spammed with a few hundred identical messages: unwind: Unknown symbol address c0800300 unwind: Index not found c0800300 c0800300 is the return address from the last subroutine call (to __memzero()) in __mmap_switched(). Apparently having this address in the link register confuses the unwinder. To fix this, reset the link register to zero before jumping to start_kernel(). Fixes: 9520b1a1 ("ARM: head-common.S: speed up startup code") Suggested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
- 12 10月, 2017 3 次提交
-
-
由 Nicolas Pitre 提交于
With printch() the console messages are sent out one character at a time which is agonizingly slow especially with semihosting as the whole trap intercept, remote byte access, and system resume danse is performed for every single character across a relatively slow remote debug connection. Let's use printascii() to send a whole string at once. This is also going to be more efficient, albeit to a quite lesser extent, with serial ports as well. Signed-off-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
由 Nicolas Pitre 提交于
The svc instruction doesn't exist on v7m processors. Semihosting ops are invoked with the bkpt instruction instead. Signed-off-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
由 Nicolas Pitre 提交于
This was located in .text which is meant to be read-only. And in the XIP case this shortcut simply doesn't work and may trigger a Flash controller mode switch and crash the kernel. Move it to the .bss area. Signed-off-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
- 29 9月, 2017 1 次提交
-
-
由 Russell King 提交于
With a kernel containing both DT and atag support, the diagnostics output when the dtb is missing or corrupt assume that we're trying to boot using atags and the machine ID, and only print the machine ID. This is not useful for diagnosing a missing or corrupt dtb. Move the message into arch/arm/kernel/setup.c, and print the address of the dtb/atag list, and the first 16 bytes of memory of the dtb or atag list. This allows us to see whether the dtb was corrupted in some way, causing the fallback to the machine ID / atag list. Tested-by: NKeerthy <j-keerthy@ti.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
- 28 9月, 2017 1 次提交
-
-
由 Vladimir Murzin 提交于
We support page size of 4K only, remove dead code. Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
- 18 9月, 2017 2 次提交
-
-
由 Thomas Garnier 提交于
Disable the generic address limit check in favor of an architecture specific optimized implementation. The generic implementation using pending work flags did not work well with ARM and alignment faults. The address limit is checked on each syscall return path to user-mode path as well as the irq user-mode return function. If the address limit was changed, a function is called to report data corruption (stopping the kernel or process based on configuration). The address limit check has to be done before any pending work because they can reset the address limit and the process is killed using a SIGKILL signal. For example the lkdtm address limit check does not work because the signal to kill the process will reset the user-mode address limit. Signed-off-by: NThomas Garnier <thgarnie@google.com> Signed-off-by: NKees Cook <keescook@chromium.org> Tested-by: NKees Cook <keescook@chromium.org> Tested-by: NLeonard Crestez <leonard.crestez@nxp.com> Reviewed-by: NKees Cook <keescook@chromium.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: Pratyush Anand <panand@redhat.com> Cc: Dave Martin <Dave.Martin@arm.com> Cc: Will Drewry <wad@chromium.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Andy Lutomirski <luto@amacapital.net> Cc: David Howells <dhowells@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: linux-api@vger.kernel.org Cc: Yonghong Song <yhs@fb.com> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1504798247-48833-4-git-send-email-keescook@chromium.org
-
由 Thomas Garnier 提交于
This reverts commit 73ac5d6a. The work pending loop can call set_fs after addr_limit_user_check removed the _TIF_FSCHECK flag. This may happen at anytime based on how ARM handles alignment exceptions. It leads to an infinite loop condition. After discussion, it has been agreed that the generic approach is not tailored to the ARM architecture and any fix might not be complete. This patch will be replaced by an architecture specific implementation. The work flag approach will be kept for other architectures. Reported-by: NLeonard Crestez <leonard.crestez@nxp.com> Signed-off-by: NThomas Garnier <thgarnie@google.com> Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: Pratyush Anand <panand@redhat.com> Cc: Dave Martin <Dave.Martin@arm.com> Cc: Will Drewry <wad@chromium.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Andy Lutomirski <luto@amacapital.net> Cc: David Howells <dhowells@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: linux-api@vger.kernel.org Cc: Yonghong Song <yhs@fb.com> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1504798247-48833-3-git-send-email-keescook@chromium.org
-
- 11 9月, 2017 9 次提交
-
-
由 Nicolas Pitre 提交于
The .data segment stored in ROM is only copied to RAM once at boot time and never referenced afterwards. This is arguably a suboptimal usage of ROM resources. This patch allows for compressing the .data segment before storing it into ROM and decompressing it to RAM rather than simply copying it, saving on precious ROM space. Because global data is not available yet (obviously) we must allocate decompressor workspace memory on the stack. The .bss area is used as a stack area for that purpose before it is cleared. The required stack frame is 9568 bytes for __inflate_kernel_data() alone, so make sure the .bss is large enough to cope with that plus extra room for called functions or fail the build. Those numbers were picked arbitrarily based on the above 9568 byte stack frame: 10240 (2.5 * PAGE_SIZE): used to override -Wframe-larger-than whose default value is 1024. 12288 (3 * PAGE_SIZE): minimum .bss size to contain the stack. Signed-off-by: NNicolas Pitre <nico@linaro.org> Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: NChris Brandt <Chris.Brandt@renesas.com>
-
由 Nicolas Pitre 提交于
The XIP linker script has several problems: - PAGE_ALIGNED_DATA is missing and is likely to end up somewhere with the wrong LMA. - BUG_TABLE definitely has the wrong LMA, it is not copied to RAM, and its VMA is unaccounted for and likely to clash with dynamic memory usage. - TCM usage is similarly broken. - PERCPU_SECTION is left in ROM despite being written to. Let's use generic macros for those things and locate them appropriately. Incidentally, those macros are usable with a LMA != VMA already by properly defining LOAD_OFFSET. TCM is not fixed here. It never worked in a XIP configuration anyway, so that can wait until another round of cleanups. Signed-off-by: NNicolas Pitre <nico@linaro.org> Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: NChris Brandt <Chris.Brandt@renesas.com>
-
由 Nicolas Pitre 提交于
Our .data section is missing PAGE_ALIGNED_DATA() which contains, amongst other things, the vdso page. This creates a System.map that looks like this: c15769a8 D _edata c1577000 d vdso_data_store c1578000 D __start___bug_table c1580544 D __stop___bug_table c1580544 B __bss_start By using RW_DATA_SECTION() we pick whatever generic sections might be added in the future and have page-aligned data next to other strongly aligned data. Furthermore we now include the entire thing, including the bug table, in the data accounting surrounded by _sdata/_edata. While at it let's also remplace the open coded .init.data by its equivalent INIT_DATA_SECTION(). Signed-off-by: NNicolas Pitre <nico@linaro.org> Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: NChris Brandt <Chris.Brandt@renesas.com>
-
由 Nicolas Pitre 提交于
Remove stuff from vmlinux.lds.S that is relevant only to the XIP build, and stuff from vmlinux-xip.lds.S related to self-modifying code that makes no sense in the XIP case. Signed-off-by: NNicolas Pitre <nico@linaro.org> Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: NChris Brandt <Chris.Brandt@renesas.com>
-
由 Nicolas Pitre 提交于
Let's use optimized routines such as memcpy to copy .data and memzero to clear .bss in the startup code instead of doing it one word at a time. Those routines don't use any global data so they're safe to use even if .data and .bss segments are not initialized. In the .data copy case a temporary stack is installed in the .bss area as the actual kernel stack is located within the copied data area. The XIP kernel linker script ensures a 8 byte alignment for that purpose. Finally, make the .data copy and related pointers surrounded by CONFIG_XIP_KERNEL to make it obvious what it is all about. This will allow for further cleanups in the non-XIP linker script. Signed-off-by: NNicolas Pitre <nico@linaro.org> Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: NChris Brandt <Chris.Brandt@renesas.com>
-
由 Nicolas Pitre 提交于
Provide the necessary changes to be able to execute ELF-FDPIC binaries on ARM systems with an MMU. The default for CONFIG_BINFMT_ELF_FDPIC is also set to n if the regular ELF loader is already configured so not to force FDPIC support on everyone. Given that CONFIG_BINFMT_ELF depends on CONFIG_MMU, this means CONFIG_BINFMT_ELF_FDPIC will still default to y when !MMU. Signed-off-by: NNicolas Pitre <nico@linaro.org> Acked-by: NMickael GUENE <mickael.guene@st.com> Tested-by: NVincent Abriou <vincent.abriou@st.com> Tested-by: NAndras Szemzo <szemzo.andras@gmail.com>
-
由 Nicolas Pitre 提交于
Signal handlers are not direct function pointers but pointers to function descriptor in that case. Therefore we must retrieve the actual function address and load the GOT value into r9 from the descriptor before branching to the actual handler. If a restorer is provided, we also have to load its address and GOT from its descriptor. That descriptor address and the code to load it is pushed onto the stack to be executed as soon as the signal handler returns. However, to be compatible with NX stacks, the FDPIC bounce code is also copied to the signal page along with the other code stubs. Therefore this code must get at the descriptor address whether it executes from the stack or the signal page. To do so we use the stack pointer which points at the signal stack frame where the descriptor address was stored. Because the rt signal frame is different from the simpler frame, two versions of the bounce code are needed, and two variants (ARM and Thumb) as well. The asm-offsets facility is used to determine the actual offset in the signal frame for each version, meaning that struct sigframe and rt_sigframe had to be moved to a separate file. Signed-off-by: NNicolas Pitre <nico@linaro.org> Acked-by: NMickael GUENE <mickael.guene@st.com> Tested-by: NVincent Abriou <vincent.abriou@st.com> Tested-by: NAndras Szemzo <szemzo.andras@gmail.com>
-
由 Nicolas Pitre 提交于
The first argument to elf_read_implies_exec() is either the actual header structure or a pointer to that structure whether one looks at fs/binfmt_elf.c or fs/binfmt_elf_fdpic.c. This ought to be fixed of course, but in the mean time let's sidestep the issue by removing that first argument from arm_elf_read_implies_exec() as it is unused anyway. Signed-off-by: NNicolas Pitre <nico@linaro.org> Acked-by: NMickael GUENE <mickael.guene@st.com> Tested-by: NVincent Abriou <vincent.abriou@st.com> Tested-by: NAndras Szemzo <szemzo.andras@gmail.com>
-
由 Nicolas Pitre 提交于
When there is no dedicated register to hold the tp value and no MMU to provide a fixed address kuser helper entry point, all that is left as fallback is a syscall. Signed-off-by: NNicolas Pitre <nico@linaro.org> Acked-by: NMickael GUENE <mickael.guene@st.com> Tested-by: NVincent Abriou <vincent.abriou@st.com> Tested-by: NAndras Szemzo <szemzo.andras@gmail.com>
-
- 09 9月, 2017 2 次提交
-
-
由 Dustin Brown 提交于
The kernel watchdog is a great debugging tool for finding tasks that consume a disproportionate amount of CPU time in contiguous chunks. One can imagine building a similar watchdog for arbitrary driver threads using save_stack_trace_tsk() and print_stack_trace(). However, this is not viable for dynamically loaded driver modules on ARM platforms because save_stack_trace_tsk() is not exported for those architectures. Export save_stack_trace_tsk() for the ARM architecture to align with x86 and support various debugging use cases such as arbitrary driver thread watchdog timers. Signed-off-by: NDustin Brown <dustinb@codeaurora.org> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
由 Matthew Wilcox 提交于
Reuse the existing optimised memset implementation to implement an optimised memset32 and memset64. Link: http://lkml.kernel.org/r/20170720184539.31609-5-willy@infradead.orgSigned-off-by: NMatthew Wilcox <mawilcox@microsoft.com> Reviewed-by: NRussell King <rmk+kernel@armlinux.org.uk> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: David Miller <davem@davemloft.net> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Minchan Kim <minchan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 8月, 2017 1 次提交
-
-
由 Rob Herring 提交于
Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: NRob Herring <robh@kernel.org> Acked-by: NKrzysztof Kozlowski <krzk@kernel.org> Acked-by: NHeiko Stuebner <heiko@sntech.de> Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be> Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: NShawn Guo <shawnguo@kernel.org> Acked-by: NSimon Horman <horms+renesas@verge.net.au> Cc: Russell King <linux@armlinux.org.uk> Cc: Kukjin Kim <kgene@kernel.org> Cc: Javier Martinez Canillas <javier@osg.samsung.com> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Tony Lindgren <tony@atomide.com> Cc: "Benoît Cousson" <bcousson@baylibre.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Magnus Damm <magnus.damm@gmail.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 14 8月, 2017 1 次提交
-
-
由 Russell King 提交于
Robert Jarzmik reports that his PXA25x system fails to boot with 4.12, failing at __flush_whole_cache in arch/arm/mm/proc-xscale.S:215: 0xc0019e20 <+0>: ldr r1, [pc, #788] 0xc0019e24 <+4>: ldr r0, [r1] <== here with r1 containing 0xc06f82cd, which is the address of "clean_addr". Examination of the System.map shows: c06f22c8 D user_pmd_table c06f22cc d __warned.19178 c06f22cd d clean_addr indicating that a .data.unlikely section has appeared just before the .data section from proc-xscale.S. According to objdump -h, it appears that our assembly files default their .data alignment to 2**0, which is bad news if the preceding .data section size is not power-of-2 aligned at link time. Add the appropriate .align directives to all assembly files in arch/arm that are missing them where we require an appropriate alignment. Reported-by: NRobert Jarzmik <robert.jarzmik@free.fr> Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
- 02 8月, 2017 4 次提交
-
-
由 Russell King 提交于
Avoid repeatedly saving and restoring registers around the calls to trace_hardirqs_on() and context_tracking_user_exit(). With the previous changes, we no longer need to preserve "lr" across these calls, and if we re-load r0-r3 later, we can avoid preserving these regsiters too. Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
由 Russell King 提交于
Move the saved PC value into r9, thereby moving it into a caller-saved register for functions that we may call during the entry to a syscall. Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
由 Russell King 提交于
Obtain the thread info structure later in the syscall processing, so that we free up a register for earlier code. Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
由 Russell King 提交于
Use aliases for the saved (and preserved) PSR and PC values so that we can control which registers are used. Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
- 24 7月, 2017 2 次提交
-
-
由 Dave Martin 提交于
In kernels with CONFIG_IWMMXT=y running on non-iWMMXt hardware, the signal frame can be left partially uninitialised in such a way that userspace cannot parse uc_regspace[] safely. In particular, this means that the VFP registers cannot be located reliably in the signal frame when a multi_v7_defconfig kernel is run on the majority of platforms. The cause is that the uc_regspace[] is laid out statically based on the kernel config, but the decision of whether to save/restore the iWMMXt registers must be a runtime decision. To minimise breakage of software that may assume a fixed layout, this patch emits a dummy block of the same size as iwmmxt_sigframe, for non-iWMMXt threads. However, the magic and size of this block are now filled in to help parsers skip over it. A new DUMMY_MAGIC is defined for this purpose. It is probably legitimate (if non-portable) for userspace to manufacture its own sigframe for sigreturn, and there is no obvious reason why userspace should be required to insert a DUMMY_MAGIC block when running on non-iWMMXt hardware, when omitting it has worked just fine forever in other configurations. So in this case, sigreturn does not require this block to be present. Reported-by: NEdmund Grimley-Evans <Edmund.Grimley-Evans@arm.com> Signed-off-by: NDave Martin <Dave.Martin@arm.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
由 Dave Martin 提交于
preserve_iwmmxt_context() and restore_iwmmxt_context() lack __user accessors on their arguments pointing to the user signal frame. There does not be appear to be a bug here, but this omission is inconsistent with the crunch and vfp sigframe access functions. This patch adds the annotations, for consistency. Signed-off-by: NDave Martin <Dave.Martin@arm.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
- 20 7月, 2017 2 次提交
-
-
由 Russell King 提交于
When kexec was converted to DTB, the dtb address was passed between machine_kexec_prepare() and machine_kexec() using a static variable. This is bad news if you load a crash kernel followed by a normal kernel or vice versa - the last loaded kernel overwrites the dtb address. This can result in kexec failures, as (eg) we try to boot the crash kernel with the last loaded dtb. For example, with: the crash kernel fails to find the dtb. Avoid this by defining a kimage architecture structure, and store the address to be passed in r2 there, which will either be the ATAGs or the dtb blob. Fixes: 4cabd1d9 ("ARM: 7539/1: kexec: scan for dtb magic in segments") Fixes: 42d720d1 ("ARM: kexec: Make .text R/W in machine_kexec") Reported-by: NKeerthy <j-keerthy@ti.com> Tested-by: NKeerthy <j-keerthy@ti.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
由 Russell King 提交于
Allocating the crashkernel region outside lowmem causes the kernel to oops while trying to kexec into the new kernel: Loading crashdump kernel... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = edd70000 [00000000] *pgd=de19e835 Internal error: Oops: 817 [#2] SMP ARM Modules linked in: ... CPU: 0 PID: 689 Comm: sh Not tainted 4.12.0-rc3-next-20170601-04015-gc3a5a20 Hardware name: Generic DRA74X (Flattened Device Tree) task: edb32f00 task.stack: edf18000 PC is at memcpy+0x50/0x330 LR is at 0xe3c34001 pc : [<c04baf30>] lr : [<e3c34001>] psr: 800c0193 sp : edf19c2c ip : 0a000001 fp : c0553170 r10: c055316e r9 : 00000001 r8 : e3130001 r7 : e4903004 r6 : 0a000014 r5 : e3500000 r4 : e59f106c r3 : e59f0074 r2 : ffffffe8 r1 : c010fb88 r0 : 00000000 Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: add7006a DAC: 00000051 Process sh (pid: 689, stack limit = 0xedf18218) Stack: (0xedf19c2c to 0xedf1a000) ... [<c04baf30>] (memcpy) from [<c010fae0>] (machine_kexec+0xa8/0x12c) [<c010fae0>] (machine_kexec) from [<c01e4104>] (__crash_kexec+0x5c/0x98) [<c01e4104>] (__crash_kexec) from [<c01e419c>] (crash_kexec+0x5c/0x68) [<c01e419c>] (crash_kexec) from [<c010c5c0>] (die+0x228/0x490) [<c010c5c0>] (die) from [<c011e520>] (__do_kernel_fault.part.0+0x54/0x1e4) [<c011e520>] (__do_kernel_fault.part.0) from [<c082412c>] (do_page_fault+0x1e8/0x400) [<c082412c>] (do_page_fault) from [<c010135c>] (do_DataAbort+0x38/0xb8) [<c010135c>] (do_DataAbort) from [<c0823584>] (__dabt_svc+0x64/0xa0) This is caused by image->control_code_page being a highmem page, so page_address(image->control_code_page) returns NULL. In any case, we don't want the control page to be a highmem page. We already limit the crash kernel region to the top of 32-bit physical memory space. Also limit it to the top of lowmem in physical space. Reported-by: NKeerthy <j-keerthy@ti.com> Tested-by: NKeerthy <j-keerthy@ti.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
- 11 7月, 2017 1 次提交
-
-
由 Bart Van Assche 提交于
The global variable 'rd_size' is declared as 'int' in source file arch/arm/kernel/atags_parse.c and as 'unsigned long' in drivers/block/brd.c. Fix this inconsistency. Additionally, remove the declarations of rd_image_start, rd_prompt and rd_doload from parse_tag_ramdisk() since these duplicate existing declarations in <linux/initrd.h>. Link: http://lkml.kernel.org/r/20170627065024.12347-1-bart.vanassche@wdc.comSigned-off-by: NBart Van Assche <bart.vanassche@sandisk.com> Acked-by: NRussell King <rmk+kernel@armlinux.org.uk> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jan Kara <jack@suse.cz> Cc: Jason Yan <yanaijie@huawei.com> Cc: Zhaohongjiang <zhaohongjiang@huawei.com> Cc: Miao Xie <miaoxie@huawei.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 10 7月, 2017 1 次提交
-
-
由 Lorenzo Pieralisi 提交于
Since commit 97ad2bdc ("ARM/PCI: Convert PCI scan API to pci_scan_root_bus_bridge()") the space for struct pci_sys_data is allocated by pci_alloc_host_bridge() as part of the struct pci_host_bridge. Therefore, failure paths must deallocate the entire pci_host_bridge by using pci_free_host_bridge(). Fixes: 97ad2bdc ("ARM/PCI: Convert PCI scan API to pci_scan_root_bus_bridge()") Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> [bhelgaas: changelog] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Russell King <linux@armlinux.org.uk> Cc: Andrew Lunn <andrew@lunn.ch>
-
- 08 7月, 2017 1 次提交
-
-
由 Thomas Garnier 提交于
Ensure the address limit is a user-mode segment before returning to user-mode. Otherwise a process can corrupt kernel-mode memory and elevate privileges [1]. The set_fs function sets the TIF_SETFS flag to force a slow path on return. In the slow path, the address limit is checked to be USER_DS if needed. The TIF_SETFS flag is added to _TIF_WORK_MASK shifting _TIF_SYSCALL_WORK for arm instruction immediate support. The global work mask is too big to used on a single instruction so adapt ret_fast_syscall. [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=990Signed-off-by: NThomas Garnier <thgarnie@google.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: Mark Rutland <mark.rutland@arm.com> Cc: kernel-hardening@lists.openwall.com Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: David Howells <dhowells@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Miroslav Benes <mbenes@suse.cz> Cc: Chris Metcalf <cmetcalf@mellanox.com> Cc: Pratyush Anand <panand@redhat.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Petr Mladek <pmladek@suse.com> Cc: Rik van Riel <riel@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andy Lutomirski <luto@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Will Drewry <wad@chromium.org> Cc: linux-api@vger.kernel.org Cc: Oleg Nesterov <oleg@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Paolo Bonzini <pbonzini@redhat.com> Link: http://lkml.kernel.org/r/20170615011203.144108-2-thgarnie@google.com
-
- 03 7月, 2017 1 次提交
-
-
由 Lorenzo Pieralisi 提交于
Legacy PCI host controllers (ie host controllers that set-up the PCI bus through the ARM pci_common_init() API) are currently relying on pci_fixup_irqs() to assign legacy PCI irqs to devices. This is not ideal in that pci_fixup_irqs() assigns IRQs for all PCI devices present in a given system some of which may well be enabled by the time pci_fixup_irqs() is called (ie a system with multiple host controllers). With the introduction of struct pci_host_bridge.(*map_irq) pointer it is possible to assign IRQs for all devices originating from a PCI host bridge at probe time; this is implemented through pci_assign_irq() that relies on the struct pci_host_bridge.map_irq pointer to map IRQ for a given device. The benefits this brings are twofold: - the IRQ for a device is assigned once at probe time - the IRQ assignment works also for hotplugged devices Remove pci_fixup_irqs() call from bios32 code and rely on pci_assign_irq() to carry out the IRQ mapping at device probe time. The map_irq() and swizzle_irq() struct pci_host_bridge callbacks are set-up in the struct pci_host_bridge created in the bios32 pcibios_init_hw() function and mach-* code paths (for PCI mach implementations that require a specific struct hw_pci.(*scan) function callback). Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> [bhelgaas: folded in fixes from Lorenzo: http://lkml.kernel.org/r/20170701140629.GC8977@red-moon] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Russell King <linux@armlinux.org.uk> Cc: Andrew Lunn <andrew@lunn.ch>
-
- 01 7月, 2017 1 次提交
-
-
由 Arnd Bergmann 提交于
With the new task struct randomization, we can run into a build failure for certain random seeds, which will place fields beyond the allow immediate size in the assembly: arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:803: Error: bad immediate value for offset (4096) Only two constants in asm-offset.h are affected, and I'm changing both of them here to work correctly in all configurations. One more macro has the problem, but is currently unused, so this removes it instead of adding complexity. Suggested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de> [kees: Adjust commit log slightly] Signed-off-by: NKees Cook <keescook@chromium.org>
-