v4.4: thread_info to task_struct |
||||||
Issue descriptionThere are a set of patches in the upstream kernel that move the thread_info(residing on the stack) data structure into the task_struct(kmalloc area). Applying these patches have at least the following benefits :- 1. A bug that might allow for a kernel stack overflow cannot be used to overwrite fields such as "addr_limit" inside thread_info. 2. Information leaks in the form of kernel stack variable addresses can be used to locate the address of thread_info. Moving the thread_info to kmalloc'd space renders this common technique useless.
,
May 1 2018
,
May 1 2018
#1: 25 patches, not 26. Initial patches have been uploaded here for review: https://chromium-review.googlesource.com/#/c/chromiumos/third_party/kernel/+/1037664
,
May 1 2018
Sounds like a good idea. Is this for aarch64 or also x86_64 ? Either case, please run trybots on a variety of systems.
,
May 1 2018
These patches are for ARM64 alone. I'll make sure to run the trybots on various systems, thanks.
,
May 1 2018
Build and qemu boot tests for all architectures passed with the CL in #3.
,
May 2 2018
Update: I'm working on listing the patches for the thread_info to task_struct move for x86 and uploading them along with the same CL.
,
May 17 2018
Update: I have a set of patches that move thread_info to task_struct for x86_64, but these have only been tested on a qemu buildroot fs. I'll test these patches on a chromebook next.
,
May 29 2018
I've tested the patches on a chromebook-astronaut. Next steps :- - rebase the arm64 changes on top and upload the CLs for review
,
May 29 2018
I've uploaded the patches here for review : https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1077202/1 Topic set to : v4.4-titots-arm64-x64
,
Jun 11 2018
coral-pre-cq http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8945070086711045872 coral-paladin-tryjob http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8945000465125439616 bob-paladin-tryjob http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8944451998185786848 bob-pre-cq http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8945069961025093104 clapper-pre-cq http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8945069856744441392 clapper-paladin-tryjob http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8944913069427628736 kevin-paladin-tryjob http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8945000434239342288 kevin-pre-cq http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8945069692032216144 kip-pre-cq http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8945069645755564176 kip-paladin-tryjob http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8944987968739473232 pyro-paladin-tryjob http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8944451936152980448 pyro-pre-cq http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8945069244140913152 bob-paladin and pyro-paladin were having lab failures across multiple runs.
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/24a46467edde884a1c3dad14861d171aff416a23 commit 24a46467edde884a1c3dad14861d171aff416a23 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Jun 15 17:52:12 2018 BACKPORT: Clarify naming of thread info/stack allocators We've had the thread info allocated together with the thread stack for most architectures for a long time (since the thread_info was split off from the task struct), but that is about to change. But the patches that move the thread info to be off-stack (and a part of the task struct instead) made it clear how confused the allocator and freeing functions are. Because the common case was that we share an allocation with the thread stack and the thread_info, the two pointers were identical. That identity then meant that we would have things like ti = alloc_thread_info_node(tsk, node); ... tsk->stack = ti; which certainly _worked_ (since stack and thread_info have the same value), but is rather confusing: why are we assigning a thread_info to the stack? And if we move the thread_info away, the "confusing" code just gets to be entirely bogus. So remove all this confusion, and make it clear that we are doing the stack allocation by renaming and clarifying the function names to be about the stack. The fact that the thread_info then shares the allocation is an implementation detail, and not really about the allocation itself. This is a pure renaming and type fix: we pass in the same pointer, it's just that we clarify what the pointer means. The ia64 code that actually only has one single allocation (for all of task_struct, thread_info and kernel thread stack) now looks a bit odd, but since "tsk->stack" is actually not even used there, that oddity doesn't matter. It would be a separate thing to clean that up, I intentionally left the ia64 changes as a pure brute-force renaming and type change. Backport Note: Inside kernel/fork.c, modify the call to kaiser_unmap_thread_stack to take in "stack" instead of "ti". BUG= chromium:836330 TEST=Build and run Change-Id: Ia03939a043d1cb6e2d701e9e01e76b30a6216482 Acked-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit b235beea9e996a4d36fed6cfef4801a3e7d7a9a5) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037664 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/24a46467edde884a1c3dad14861d171aff416a23/init/main.c [modify] https://crrev.com/24a46467edde884a1c3dad14861d171aff416a23/arch/ia64/include/asm/thread_info.h [modify] https://crrev.com/24a46467edde884a1c3dad14861d171aff416a23/kernel/fork.c [modify] https://crrev.com/24a46467edde884a1c3dad14861d171aff416a23/arch/tile/kernel/process.c [modify] https://crrev.com/24a46467edde884a1c3dad14861d171aff416a23/arch/ia64/Kconfig [modify] https://crrev.com/24a46467edde884a1c3dad14861d171aff416a23/arch/Kconfig [modify] https://crrev.com/24a46467edde884a1c3dad14861d171aff416a23/arch/mn10300/kernel/kgdb.c [modify] https://crrev.com/24a46467edde884a1c3dad14861d171aff416a23/arch/mn10300/include/asm/thread_info.h [modify] https://crrev.com/24a46467edde884a1c3dad14861d171aff416a23/include/linux/sched.h [modify] https://crrev.com/24a46467edde884a1c3dad14861d171aff416a23/arch/tile/include/asm/thread_info.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/da48fd3e1b6a6e748f692364a956e5366e355c78 commit da48fd3e1b6a6e748f692364a956e5366e355c78 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Jun 15 17:52:13 2018 UPSTREAM: fix up initial thread stack pointer vs thread_info confusion The INIT_TASK() initializer was similarly confused about the stack vs thread_info allocation that the allocators had, and that were fixed in commit b235beea9e99 ("Clarify naming of thread info/stack allocators"). The task ->stack pointer only incidentally ends up having the same value as the thread_info, and in fact that will change. So fix the initial task struct initializer to point to 'init_stack' instead of 'init_thread_info', and make sure the ia64 definition for that exists. This actually makes the ia64 tsk->stack pointer be sensible for the initial task, but not for any other task. As mentioned in commit b235beea9e99, that whole pointer isn't actually used on ia64, since task_stack_page() there just points to the (single) allocation. All the other architectures seem to have copied the 'init_stack' definition, even if it tended to be generally unusued. BUG= chromium:836330 TEST=Build and run Change-Id: I545d5c183bcb15ab3be9b7513ffc34fa8e0c1d3f Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 7f1a00b6fcd0e3c19beba2e92d157dc0c2cf3494) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037665 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/da48fd3e1b6a6e748f692364a956e5366e355c78/include/linux/init_task.h [modify] https://crrev.com/da48fd3e1b6a6e748f692364a956e5366e355c78/arch/ia64/kernel/init_task.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/89fa2c4d608484fcfb8155425d732a424c8623b0 commit 89fa2c4d608484fcfb8155425d732a424c8623b0 Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:15 2018 UPSTREAM: printk: when dumping regs, show the stack, not thread_info We currently show: task: <current> ti: <current_thread_info()> task.ti: <task_thread_info(current)>" "ti" and "task.ti" are redundant, and neither is actually what we want to show, which the the base of the thread stack. Change the display to show the stack pointer explicitly. BUG= chromium:836330 TEST=Build and run Change-Id: Ib6873eff06aa4db786aabc747893684c739f8780 Link: http://lkml.kernel.org/r/543ac5bd66ff94000a57a02e11af7239571a3055.1468523549.git.luto@kernel.org Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 8b70ca65616b3588ea1907e87f0df6d2530350df) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037666 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/89fa2c4d608484fcfb8155425d732a424c8623b0/kernel/printk/printk.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/cec9202e7d7b4b40601f25b4fe591ca913bb2d65 commit cec9202e7d7b4b40601f25b4fe591ca913bb2d65 Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:16 2018 UPSTREAM: sched/core: Allow putting thread_info into task_struct If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT, then thread_info is defined as a single 'u32 flags' and is the first entry of task_struct. thread_info::task is removed (it serves no purpose if thread_info is embedded in task_struct), and thread_info::cpu gets its own slot in task_struct. This is heavily based on a patch written by Linus. BUG= chromium:836330 TEST=Build and run Change-Id: I92816d5468185b4d02c6a48a81ef994d82e71c24 Originally-from: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jann Horn <jann@thejh.net> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/a0898196f0476195ca02713691a5037a14f2aac5.1473801993.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit c65eacbe290b8141554c71b2c94489e73ade8c8d) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037667 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/cec9202e7d7b4b40601f25b4fe591ca913bb2d65/include/linux/init_task.h [modify] https://crrev.com/cec9202e7d7b4b40601f25b4fe591ca913bb2d65/init/init_task.c [modify] https://crrev.com/cec9202e7d7b4b40601f25b4fe591ca913bb2d65/include/linux/thread_info.h [modify] https://crrev.com/cec9202e7d7b4b40601f25b4fe591ca913bb2d65/include/linux/sched.h [modify] https://crrev.com/cec9202e7d7b4b40601f25b4fe591ca913bb2d65/init/Kconfig [modify] https://crrev.com/cec9202e7d7b4b40601f25b4fe591ca913bb2d65/kernel/sched/sched.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a762b140ce7c6fa29ff2674576833d89e99ef602 commit a762b140ce7c6fa29ff2674576833d89e99ef602 Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:18 2018 UPSTREAM: sched/core: Add try_get_task_stack() and put_task_stack() There are a few places in the kernel that access stack memory belonging to a different task. Before we can start freeing task stacks before the task_struct is freed, we need a way for those code paths to pin the stack. BUG= chromium:836330 TEST=Build and run Change-Id: I923d01816604395f50f9787cc4d1f76f7e841f79 Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jann Horn <jann@thejh.net> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/17a434f50ad3d77000104f21666575e10a9c1fbd.1474003868.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit c6c314a613cd7d03fb97713e0d642b493de42e69) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037668 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/a762b140ce7c6fa29ff2674576833d89e99ef602/include/linux/sched.h [modify] https://crrev.com/a762b140ce7c6fa29ff2674576833d89e99ef602/init/Kconfig
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8762c2f2868e229370543bf1d7892e89ac192cfc commit 8762c2f2868e229370543bf1d7892e89ac192cfc Author: Oleg Nesterov <oleg@redhat.com> Date: Fri Jun 15 17:52:20 2018 UPSTREAM: kthread: Pin the stack via try_get_task_stack()/put_task_stack() in to_live_kthread() function get_task_struct(tsk) no longer pins tsk->stack so all users of to_live_kthread() should do try_get_task_stack/put_task_stack to protect "struct kthread" which lives on kthread's stack. TODO: Kill to_live_kthread(), perhaps we can even kill "struct kthread" too, and rework kthread_stop(), it can use task_work_add() to sync with the exiting kernel thread. BUG= chromium:836330 TEST=Build and run Change-Id: Ibd8c6efefecdbfe1376a805e60defca164334e83 Message-Id: <20160629180357.GA7178@redhat.com> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jann Horn <jann@thejh.net> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/cb9b16bbc19d4aea4507ab0552e4644c1211d130.1474003868.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 23196f2e5f5d810578a772785807dcdc2b9fdce9) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037669 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/8762c2f2868e229370543bf1d7892e89ac192cfc/kernel/kthread.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a4598c98c9e371d5f4fbaad7d8acaa3e86233e40 commit a4598c98c9e371d5f4fbaad7d8acaa3e86233e40 Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:52:21 2018 UPSTREAM: thread_info: factor out restart_block Since commit f56141e3e2d9aabf ("all arches, signal: move restart_block to struct task_struct"), thread_info and restart_block have been logically distinct, yet struct restart_block is still defined in <linux/thread_info.h>. At least one architecture (erroneously) uses restart_block as part of its thread_info, and thus the definition of restart_block must come before the include of <asm/thread_info>. Subsequent patches in this series need to shuffle the order of includes and definitions in <linux/thread_info.h>, and will make this ordering fragile. This patch moves the definition of restart_block out to its own header. This serves as generic cleanup, logically separating thread_info and restart_block, and also makes it easier to avoid fragility. BUG= chromium:836330 TEST=Build and run Change-Id: I653985811f772d29b71332a7b60c8588de01ee85 Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Andy Lutomirski <luto@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 53d74d056a4e306a72b8883d325b5d853c0618e6) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037670 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/a4598c98c9e371d5f4fbaad7d8acaa3e86233e40/include/linux/thread_info.h [add] https://crrev.com/a4598c98c9e371d5f4fbaad7d8acaa3e86233e40/include/linux/restart_block.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8bb0513b552ae44a724dd323e537ac8102a9dc6d commit 8bb0513b552ae44a724dd323e537ac8102a9dc6d Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:52:52 2018 UPSTREAM: arm64: thread_info remove stale items We have a comment claiming __switch_to() cares about where cpu_context is located relative to cpu_domain in thread_info. However arm64 has never had a thread_info::cpu_domain field, and neither __switch_to nor cpu_switch_to care where the cpu_context field is relative to others. Additionally, the init_thread_info alias is never used anywhere in the kernel, and will shortly become problematic when thread_info is moved into task_struct. This patch removes both. BUG= chromium:836330 TEST=Build and run Change-Id: I21d0a78ab29042cd49719a9aa4c7103325f22cf1 Signed-off-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit dcbe02855f048fdf1e13ebc697e83c8d297f9f5a) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037672 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/8bb0513b552ae44a724dd323e537ac8102a9dc6d/arch/arm64/include/asm/thread_info.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2de36b24956d00d220b368d31f6d4737c1c6330f commit 2de36b24956d00d220b368d31f6d4737c1c6330f Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:52:53 2018 UPSTREAM: arm64: asm-offsets: remove unused definitions Subsequent patches will move the thread_info::{task,cpu} fields, and the current TI_{TASK,CPU} offset definitions are not used anywhere. This patch removes the redundant definitions. BUG= chromium:836330 TEST=Build and run Change-Id: I342c07899fd4622bce5ca4746a75503c51bd530b Signed-off-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 3fe12da4c7fa6491e0fb7c5371716ac7f8ea80a5) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037673 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/2de36b24956d00d220b368d31f6d4737c1c6330f/arch/arm64/kernel/asm-offsets.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/75ab27061038fd7af3635ea71e839ff5b4c689b8 commit 75ab27061038fd7af3635ea71e839ff5b4c689b8 Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:52:55 2018 UPSTREAM: arm64: factor out current_stack_pointer We define current_stack_pointer in <asm/thread_info.h>, though other files and header relying upon it do not have this necessary include, and are thus fragile to changes in the header soup. Subsequent patches will affect the header soup such that directly including <asm/thread_info.h> may result in a circular header include in some of these cases, so we can't simply include <asm/thread_info.h>. Instead, factor current_thread_info into its own header, and have all existing users include this explicitly. BUG= chromium:836330 TEST=Build and run Change-Id: I5f51c5e6658c986a0a52a60dc2fb197356aac71c Signed-off-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit a9ea0017ebe8889dfa136cac2aa7ae0ee6915e1f) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037674 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/75ab27061038fd7af3635ea71e839ff5b4c689b8/arch/arm64/kernel/stacktrace.c [modify] https://crrev.com/75ab27061038fd7af3635ea71e839ff5b4c689b8/arch/arm64/include/asm/percpu.h [modify] https://crrev.com/75ab27061038fd7af3635ea71e839ff5b4c689b8/arch/arm64/kernel/return_address.c [modify] https://crrev.com/75ab27061038fd7af3635ea71e839ff5b4c689b8/arch/arm64/include/asm/perf_event.h [modify] https://crrev.com/75ab27061038fd7af3635ea71e839ff5b4c689b8/arch/arm64/include/asm/thread_info.h [modify] https://crrev.com/75ab27061038fd7af3635ea71e839ff5b4c689b8/arch/arm64/kernel/traps.c [add] https://crrev.com/75ab27061038fd7af3635ea71e839ff5b4c689b8/arch/arm64/include/asm/stack_pointer.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/acd2149542d1482283b873b368dca6b2b5c5d36f commit acd2149542d1482283b873b368dca6b2b5c5d36f Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:52:56 2018 UPSTREAM: arm64: traps: simplify die() and __die() In arm64's die and __die routines we pass around a thread_info, and subsequently use this to determine the relevant task_struct, and the end of the thread's stack. Subsequent patches will decouple thread_info from the stack, and this approach will no longer work. To figure out the end of the stack, we can use the new generic end_of_stack() helper. As we only call __die() from die(), and die() always deals with the current task, we can remove the parameter and have both acquire current directly, which also makes it clear that __die can't be called for arbitrary tasks. BUG= chromium:836330 TEST=Build and run Change-Id: I26d64533ff7ac7a57eebdd6e117c63b39e73e38b Signed-off-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 876e7a38e8788773aac768091aaa3b42e470c03b) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037675 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/acd2149542d1482283b873b368dca6b2b5c5d36f/arch/arm64/kernel/traps.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/baeea2e3af335fc0d30bb1812d94d8ab03deeb5d commit baeea2e3af335fc0d30bb1812d94d8ab03deeb5d Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:52:58 2018 UPSTREAM: arm64: unexport walk_stackframe The walk_stackframe functions is architecture-specific, with a varying prototype, and common code should not use it directly. None of its current users can be built as modules. With THREAD_INFO_IN_TASK, users will also need to hold a stack reference before calling it. There's no reason for it to be exported, and it's very easy to misuse, so unexport it for now. BUG= chromium:836330 TEST=Build and run Change-Id: I4bd1051af67e1b9b1aa8d3267873b4e55a0b577d Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 2020a5ae7c8c2c8504565004915017507b135c63) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037676 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/baeea2e3af335fc0d30bb1812d94d8ab03deeb5d/arch/arm64/kernel/stacktrace.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1c160633121a7775ef8a5859f27407c8ac8869a4 commit 1c160633121a7775ef8a5859f27407c8ac8869a4 Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:52:59 2018 UPSTREAM: arm64: prep stack walkers for THREAD_INFO_IN_TASK When CONFIG_THREAD_INFO_IN_TASK is selected, task stacks may be freed before a task is destroyed. To account for this, the stacks are refcounted, and when manipulating the stack of another task, it is necessary to get/put the stack to ensure it isn't freed and/or re-used while we do so. This patch reworks the arm64 stack walking code to account for this. When CONFIG_THREAD_INFO_IN_TASK is not selected these perform no refcounting, and this should only be a structural change that does not affect behaviour. BUG= chromium:836330 TEST=Build and run Change-Id: I30111cfa22f28e3ff818372499a2dc0f52ff0cb1 Signed-off-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 9bbd4c56b0b642f04396da378296e68096d5afca) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037677 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/1c160633121a7775ef8a5859f27407c8ac8869a4/arch/arm64/kernel/stacktrace.c [modify] https://crrev.com/1c160633121a7775ef8a5859f27407c8ac8869a4/arch/arm64/kernel/traps.c [modify] https://crrev.com/1c160633121a7775ef8a5859f27407c8ac8869a4/arch/arm64/kernel/process.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/564d605cd167dbf6a398726e24b00a7d5b629217 commit 564d605cd167dbf6a398726e24b00a7d5b629217 Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:53:02 2018 BACKPORT: arm64: move sp_el0 and tpidr_el1 into cpu_suspend_ctx When returning from idle, we rely on the fact that thread_info lives at the end of the kernel stack, and restore this by masking the saved stack pointer. Subsequent patches will sever the relationship between the stack and thread_info, and to cater for this we must save/restore sp_el0 explicitly, storing it in cpu_suspend_ctx. As cpu_suspend_ctx must be doubleword aligned, this leaves us with an extra slot in cpu_suspend_ctx. We can use this to save/restore tpidr_el1 in the same way, which simplifies the code, avoiding pointer chasing on the restore path (as we no longer need to load thread_info::cpu followed by the relevant slot in __per_cpu_offset based on this). This patch stashes both registers in cpu_suspend_ctx. Backport Note: - set_my_cpu_offset now uses the cpu number obtained from task_cpu(current). - NR_CTX_REGS is increased from 11 to 13. In the original patch, this is increased from 10 to 12. - Upon suspending and resuming, sp_el0 and tpidr_el1 are saved and restored at different offsets. The original patch stores them at offsets 80 and 88. This patch saves them at offsets 88 and 96. BUG= chromium:836330 TEST=Build and run Change-Id: Icd08805b3cfdbb55ffd1ebaa773dcdab5c2d10cb Signed-off-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: James Morse <james.morse@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 623b476fc815464a0241ea7483da7b3580b7d8ac) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037678 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/564d605cd167dbf6a398726e24b00a7d5b629217/arch/arm64/mm/proc.S [modify] https://crrev.com/564d605cd167dbf6a398726e24b00a7d5b629217/arch/arm64/include/asm/suspend.h [modify] https://crrev.com/564d605cd167dbf6a398726e24b00a7d5b629217/arch/arm64/kernel/suspend.c [modify] https://crrev.com/564d605cd167dbf6a398726e24b00a7d5b629217/arch/arm64/kernel/sleep.S
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7622a55c1d75c2205dbf4800c468d565d0f1ff8b commit 7622a55c1d75c2205dbf4800c468d565d0f1ff8b Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:53:04 2018 UPSTREAM: arm64: smp: prepare for smp_processor_id() rework Subsequent patches will make smp_processor_id() use a percpu variable. This will make smp_processor_id() dependent on the percpu offset, and thus we cannot use smp_processor_id() to figure out what to initialise the offset to. Prepare for this by initialising the percpu offset based on current::cpu, which will work regardless of how smp_processor_id() is implemented. Also, make this relationship obvious by placing this code together at the start of secondary_start_kernel(). BUG= chromium:836330 TEST=Build and boot Change-Id: I32e03791b04524516261fd736a643a9171b25301 Signed-off-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 580efaa7ccfb8c0790dce4396434f0e5ac8d86ee) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037679 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/7622a55c1d75c2205dbf4800c468d565d0f1ff8b/arch/arm64/kernel/smp.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b0c9c5292652f8c0980d6188e6340869ac8f77bc commit b0c9c5292652f8c0980d6188e6340869ac8f77bc Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:53:06 2018 UPSTREAM: arm64: make cpu number a percpu variable In the absence of CONFIG_THREAD_INFO_IN_TASK, core code maintains thread_info::cpu, and low-level architecture code can access this to build raw_smp_processor_id(). With CONFIG_THREAD_INFO_IN_TASK, core code maintains task_struct::cpu, which for reasons of hte header soup is not accessible to low-level arch code. Instead, we can maintain a percpu variable containing the cpu number. For both the old and new implementation of raw_smp_processor_id(), we read a syreg into a GPR, add an offset, and load the result. As the offset is now larger, it may not be folded into the load, but otherwise the assembly shouldn't change much. BUG= chromium:836330 TEST=Build and boot Change-Id: I73bb45768e4e6e155857e2c62cabfb120f5ca4a7 Signed-off-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: James Morse <james.morse@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 57c82954e77fa12c1023e87210d2ede77aaa0058) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037680 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/b0c9c5292652f8c0980d6188e6340869ac8f77bc/arch/arm64/kernel/smp.c [modify] https://crrev.com/b0c9c5292652f8c0980d6188e6340869ac8f77bc/arch/arm64/include/asm/smp.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e523e234f2e195b7d99eb1a525cc46b54a50ffde commit e523e234f2e195b7d99eb1a525cc46b54a50ffde Author: Robin Murphy <robin.murphy@arm.com> Date: Fri Jun 15 17:53:07 2018 UPSTREAM: arm64: smp: Prevent raw_smp_processor_id() recursion Under CONFIG_DEBUG_PREEMPT=y, this_cpu_ptr() ends up calling back into raw_smp_processor_id(), resulting in some hilariously catastrophic infinite recursion. In the normal case, we have: #define this_cpu_ptr(ptr) raw_cpu_ptr(ptr) and everything is dandy. However for CONFIG_DEBUG_PREEMPT, this_cpu_ptr() is defined in terms of my_cpu_offset, wherein the fun begins: #define my_cpu_offset per_cpu_offset(smp_processor_id()) ... #define smp_processor_id() debug_smp_processor_id() ... notrace unsigned int debug_smp_processor_id(void) { return check_preemption_disabled("smp_processor_id", ""); ... notrace static unsigned int check_preemption_disabled(const char *what1, const char *what2) { int this_cpu = raw_smp_processor_id(); and bang. Use raw_cpu_ptr() directly to avoid that. BUG= chromium:836330 TEST=Build and boot Change-Id: I897fc073f5bd25e3a84b40de6cb3927e45ed7ca8 Fixes: 57c82954e77f ("arm64: make cpu number a percpu variable") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 34a6980c82fb1342e7064844c95aa4cf933e5ecc) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037681 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/e523e234f2e195b7d99eb1a525cc46b54a50ffde/arch/arm64/include/asm/smp.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/eb61c55ada7f65de869ca551d70ac122f7f43551 commit eb61c55ada7f65de869ca551d70ac122f7f43551 Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:53:09 2018 BACKPORT: arm64: assembler: introduce ldr_this_cpu Shortly we will want to load a percpu variable in the return from userspace path. We can save an instruction by folding the addition of the percpu offset into the load instruction, and this patch adds a new helper to do so. At the same time, we clean up this_cpu_ptr for consistency. As with {adr,ldr,str}_l, we change the template to take the destination register first, and name this dst. Secondly, we rename the macro to adr_this_cpu, following the scheme of adr_l, and matching the newly added ldr_this_cpu. Backport Note: - adr_this_cpu does not exist for v4.4, this commit introduces the macro. - The upstream change to add do_softirq_own_stack, 8e23dacd, is not present. As a result, a subsequent changes(aa4d5d3c, d224a69e), that used a macro to access the per-cpu to keep track of the irq_stack is not present. As a result, the change from this_cpu_ptr to adr_this_cpu is not required. BUG= chromium:836330 TEST=Build and boot Change-Id: I2ebe4ba035b45eac9b74d9e06fe198e698ee7c92 Signed-off-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 1b7e2296a822dfd2349960addc42a139360ce769) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037682 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/eb61c55ada7f65de869ca551d70ac122f7f43551/arch/arm64/include/asm/assembler.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/dd40e8135b3c5c4cf2068a10abcf2b8e54427794 commit dd40e8135b3c5c4cf2068a10abcf2b8e54427794 Author: Jungseok Lee <jungseoklee85@gmail.com> Date: Fri Jun 15 17:53:01 2018 UPSTREAM: arm64: Store struct thread_info in sp_el0 There is need for figuring out how to manage struct thread_info data when IRQ stack is introduced. struct thread_info information should be copied to IRQ stack under the current thread_info calculation logic whenever context switching is invoked. This is too expensive to keep supporting the approach. Instead, this patch pays attention to sp_el0 which is an unused scratch register in EL1 context. sp_el0 utilization not only simplifies the management, but also prevents text section size from being increased largely due to static allocated IRQ stack as removing masking operation using THREAD_SIZE in many places. BUG= chromium:836330 TEST=Build and boot Change-Id: I4d6d6eeb17ef439d5b7c207d024f36dbab8e47eb Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Jungseok Lee <jungseoklee85@gmail.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit 6cdf9c7ca687e01840d0215437620a20263012fc) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037683 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/dd40e8135b3c5c4cf2068a10abcf2b8e54427794/arch/arm64/kernel/head.S [modify] https://crrev.com/dd40e8135b3c5c4cf2068a10abcf2b8e54427794/arch/arm64/kernel/entry.S [modify] https://crrev.com/dd40e8135b3c5c4cf2068a10abcf2b8e54427794/arch/arm64/include/asm/thread_info.h [modify] https://crrev.com/dd40e8135b3c5c4cf2068a10abcf2b8e54427794/arch/arm64/kernel/sleep.S
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d1a3798d62494643d0d0b02b4d9ace4ef7338a81 commit d1a3798d62494643d0d0b02b4d9ace4ef7338a81 Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:53:10 2018 UPSTREAM: arm64: Add macros to read/write system registers Rather than crafting custom macros for reading/writing each system register provide generics accessors, read_sysreg and write_sysreg, for this purpose. BUG= chromium:836330 TEST=Build and boot Change-Id: Ic816787ccce8e165c24b832142471e9f45cb03da Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Suzuki Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> (cherry picked from commit 3600c2fdc09a43a30909743569e35a29121602ed) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037684 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/d1a3798d62494643d0d0b02b4d9ace4ef7338a81/arch/arm64/include/asm/sysreg.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/77ecb896b3cb697e10e641f79df5a50bbfc44173 commit 77ecb896b3cb697e10e641f79df5a50bbfc44173 Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:53:12 2018 BACKPORT: arm64: split thread_info from task stack This patch moves arm64's struct thread_info from the task stack into task_struct. This protects thread_info from corruption in the case of stack overflows, and makes its address harder to determine if stack addresses are leaked, making a number of attacks more difficult. Precise detection and handling of overflow is left for subsequent patches. Largely, this involves changing code to store the task_struct in sp_el0, and acquire the thread_info from the task struct. Core code now implements current_thread_info(), and as noted in <linux/sched.h> this relies on offsetof(task_struct, thread_info) == 0, enforced by core code. This change means that the 'tsk' register used in entry.S now points to a task_struct, rather than a thread_info as it used to. To make this clear, the TI_* field offsets are renamed to TSK_TI_*, with asm-offsets appropriately updated to account for the structural change. Userspace clobbers sp_el0, and we can no longer restore this from the stack. Instead, the current task is cached in a per-cpu variable that we can safely access from early assembly as interrupts are disabled (and we are thus not preemptible). Both secondary entry and idle are updated to stash the sp and task pointer separately. Backport Note: The points of difference between the upstream patch and this are as follows :- - arch/arm64/kernel/head.S: Changes in how thread_info is saved for primary and secondary processors - arch/arm64/kernel/entry.S: Locations where thread_info attributes are accessed now use the newer offset BUG= chromium:836330 TEST=Build and boot Change-Id: Ifd133d2feba93af236c9ca354bf650af6a9333dc Signed-off-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: James Morse <james.morse@arm.com> Cc: Kees Cook <keescook@chromium.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit c02433dd6de32f042cf3ffe476746b1115b8c096) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037685 Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> [modify] https://crrev.com/77ecb896b3cb697e10e641f79df5a50bbfc44173/arch/arm64/kernel/smp.c [modify] https://crrev.com/77ecb896b3cb697e10e641f79df5a50bbfc44173/arch/arm64/kernel/head.S [modify] https://crrev.com/77ecb896b3cb697e10e641f79df5a50bbfc44173/arch/arm64/include/asm/smp.h [modify] https://crrev.com/77ecb896b3cb697e10e641f79df5a50bbfc44173/arch/arm64/kernel/asm-offsets.c [modify] https://crrev.com/77ecb896b3cb697e10e641f79df5a50bbfc44173/arch/arm64/kernel/process.c [add] https://crrev.com/77ecb896b3cb697e10e641f79df5a50bbfc44173/arch/arm64/include/asm/current.h [modify] https://crrev.com/77ecb896b3cb697e10e641f79df5a50bbfc44173/arch/arm64/kernel/entry.S [modify] https://crrev.com/77ecb896b3cb697e10e641f79df5a50bbfc44173/arch/arm64/Kconfig [modify] https://crrev.com/77ecb896b3cb697e10e641f79df5a50bbfc44173/arch/arm64/include/asm/thread_info.h [modify] https://crrev.com/77ecb896b3cb697e10e641f79df5a50bbfc44173/arch/arm64/include/asm/Kbuild
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9c780e12d5fafd94fc7a197f5ea3a573d0baa9ab commit 9c780e12d5fafd94fc7a197f5ea3a573d0baa9ab Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:53:13 2018 UPSTREAM: kdb: use task_cpu() instead of task_thread_info()->cpu We'll need this cleanup to make the cpu field in thread_info be optional. BUG= chromium:836330 TEST=Build and boot Change-Id: I2ce67414025221a522307756d8417c3f7b8484f1 Link: http://lkml.kernel.org/r/da298328dc77ea494576c2f20a934218e758a6fa.1468523549.git.luto@kernel.org Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit e558af65be65713ef2e8b2aa637c6263caeed172) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037686 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/9c780e12d5fafd94fc7a197f5ea3a573d0baa9ab/include/linux/kdb.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f24b0e67e3a35d631b8e1cd2b1eac29d28f696f4 commit f24b0e67e3a35d631b8e1cd2b1eac29d28f696f4 Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:53:15 2018 UPSTREAM: arm64: restore get_current() optimisation Commit c02433dd6de32f04 ("arm64: split thread_info from task stack") inverted the relationship between get_current() and current_thread_info(), with sp_el0 now holding the current task_struct rather than the current thead_info. The new implementation of get_current() prevents the compiler from being able to optimize repeated calls to either, resulting in a noticeable penalty in some microbenchmarks. This patch restores the previous optimisation by implementing get_current() in the same way as our old current_thread_info(), using a non-volatile asm statement. BUG= chromium:836330 TEST=Build and boot Change-Id: I6dc71e630abcd62c3b27a34fa131dffaa56f660b Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reported-by: Davidlohr Bueso <dbueso@suse.de> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 9d84fb27fa135c99c9fe3de33628774a336a70a8) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037687 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/f24b0e67e3a35d631b8e1cd2b1eac29d28f696f4/arch/arm64/include/asm/current.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/951ab2387aee27626f641e1c2a61e683e41b46e3 commit 951ab2387aee27626f641e1c2a61e683e41b46e3 Author: Michael Ellerman <mpe@ellerman.id.au> Date: Fri Jun 15 17:53:16 2018 UPSTREAM: Fix build break in fork.c when THREAD_SIZE < PAGE_SIZE Commit b235beea9e99 ("Clarify naming of thread info/stack allocators") breaks the build on some powerpc configs, where THREAD_SIZE < PAGE_SIZE: kernel/fork.c:235:2: error: implicit declaration of function 'free_thread_stack' kernel/fork.c:355:8: error: assignment from incompatible pointer type stack = alloc_thread_stack_node(tsk, node); ^ Fix it by renaming free_stack() to free_thread_stack(), and updating the return type of alloc_thread_stack_node(). BUG= chromium:836330 TEST=Build and boot Change-Id: I85262f8a80c8256a0b1171e57628f8cc754eccc1 Fixes: b235beea9e99 ("Clarify naming of thread info/stack allocators") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 9521d39976db20f8ef9b56af66661482a17d5364) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1037688 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/951ab2387aee27626f641e1c2a61e683e41b46e3/kernel/fork.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/53af76dd77e1abdcf17da0a199ea84c8b549964e commit 53af76dd77e1abdcf17da0a199ea84c8b549964e Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:04 2018 UPSTREAM: x86/entry/32: Add an ASM_CLAC to entry_SYSENTER_32 Both before and after 5f310f739b4c ("x86/entry/32: Re-implement SYSENTER using the new C path"), we relied on a uaccess very early in the SYSENTER path to clear AC. After that change, though, we can potentially make it all the way into C code with AC set, which enlarges the attack surface for SMAP bypass by doing SYSENTER with AC set. Strengthen the SMAP protection by addding the missing ASM_CLAC right at the beginning. BUG= chromium:836330 TEST=Build and boot Change-Id: I3c7e79758a48e3a47465c952549bb86d72632374 Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/3e36be110724896e32a4a1fe73bacb349d3cba94.1456262295.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 04d1d281dcfe683a53cddfab8371fc8bb302b069) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077202 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/53af76dd77e1abdcf17da0a199ea84c8b549964e/arch/x86/entry/entry_32.S
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9e4ad7d30a775cc033d652826ed4c41a6f8840e1 commit 9e4ad7d30a775cc033d652826ed4c41a6f8840e1 Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:06 2018 UPSTREAM: x86/entry/32: Filter NT and speed up AC filtering in SYSENTER This makes the 32-bit code work just like the 64-bit code. It should speed up syscalls on 32-bit kernels on Skylake by something like 20 cycles (by analogy to the 64-bit compat case). It also cleans up NT just like we do for the 64-bit case. BUG= chromium:836330 TEST=Build and boot Change-Id: I3bbd19ffc8874b18f7c657473afcd66873c5a219 Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/07daef3d44bd1ed62a2c866e143e8df64edb40ee.1457578375.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 67f590e8d4d718d9bd377b39223f7f69678d6a10) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077203 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/9e4ad7d30a775cc033d652826ed4c41a6f8840e1/arch/x86/entry/entry_32.S
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9312628bdcf0ce15b630252b26f8ae87b568f6bd commit 9312628bdcf0ce15b630252b26f8ae87b568f6bd Author: Brian Gerst <brgerst@gmail.com> Date: Fri Jun 15 17:52:07 2018 UPSTREAM: x86/entry, sched/x86: Don't save/restore EFLAGS on task switch Now that NT is filtered by the SYSENTER entry code, it is safe to skip saving and restoring flags on task switch. Also remove a leftover reset of flags on 64-bit fork. BUG= chromium:836330 TEST=Build and boot Change-Id: I40e022ba81f2e151f23698b52e6c0407cc19ec26 Signed-off-by: Brian Gerst <brgerst@gmail.com> Acked-by: Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Borislav Petkov <bp@suse.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1462416278-11974-2-git-send-email-brgerst@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 092c74e420952c7cb68141731f2b562245b51eeb) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077204 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/9312628bdcf0ce15b630252b26f8ae87b568f6bd/arch/x86/entry/entry_64.S [modify] https://crrev.com/9312628bdcf0ce15b630252b26f8ae87b568f6bd/arch/x86/entry/entry_32.S [modify] https://crrev.com/9312628bdcf0ce15b630252b26f8ae87b568f6bd/arch/x86/include/asm/switch_to.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/49207be1bf08476fcc35548379ca9282f1963074 commit 49207be1bf08476fcc35548379ca9282f1963074 Author: Brian Gerst <brgerst@gmail.com> Date: Fri Jun 15 17:52:09 2018 UPSTREAM: sched/x86: Add 'struct inactive_task_frame' to better document the sleeping task stack frame Add 'struct inactive_task_frame', which defines the layout of the stack for a sleeping process. For now, the only defined field is the BP register (frame pointer). BUG= chromium:836330 TEST=Build and boot Change-Id: Ibe8aaf4aedf2d46410179a550088196c15c5c66e Signed-off-by: Brian Gerst <brgerst@gmail.com> Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1471106302-10159-4-git-send-email-brgerst@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 7b32aeadbc95d4a41402c1c0da6aa3ab51af4c10) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077205 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/49207be1bf08476fcc35548379ca9282f1963074/arch/x86/kernel/process.c [modify] https://crrev.com/49207be1bf08476fcc35548379ca9282f1963074/arch/x86/kernel/kgdb.c [modify] https://crrev.com/49207be1bf08476fcc35548379ca9282f1963074/arch/x86/include/asm/stacktrace.h [modify] https://crrev.com/49207be1bf08476fcc35548379ca9282f1963074/arch/x86/include/asm/switch_to.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5f9662229ae3322b372661d6d1c64216957bf736 commit 5f9662229ae3322b372661d6d1c64216957bf736 Author: Brian Gerst <brgerst@gmail.com> Date: Fri Jun 15 17:52:10 2018 BACKPORT: sched/x86: Rewrite the switch_to() code Move the low-level context switch code to an out-of-line asm stub instead of using complex inline asm. This allows constructing a new stack frame for the child process to make it seamlessly flow to ret_from_fork without an extra test and branch in __switch_to(). It also improves code generation for __schedule() by using the C calling convention instead of clobbering all registers. BUG= chromium:836330 TEST=Build and boot Backport Notes: - the original switch_to implementation inside switch_to.h had been modified to include retpoline related code in the v4.4 commit 18bb117d1b769. When moving switch_to to entry_32.S and entry_64.S, the retpoline code needs to be moved as well; similar to how it is done for the v4.14 kernel. - In the original upstream patch, inside arch/x86/include/asm/switch_to.h, switch_to expected a call to prepare_switch_to. This was introduced in e37e43a49("x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)"). As VMAP_STACK is not being backported, that patch is not pulled in, and the call to prepare_switch_to is not present. Change-Id: I127d75f5312d52892b8256609e98902a89e948c6 Signed-off-by: Brian Gerst <brgerst@gmail.com> Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1471106302-10159-5-git-send-email-brgerst@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 0100301bfdf56a2a370c7157b5ab0fbf9313e1cd) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077206 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/5f9662229ae3322b372661d6d1c64216957bf736/arch/x86/entry/entry_64.S [modify] https://crrev.com/5f9662229ae3322b372661d6d1c64216957bf736/arch/x86/kernel/smpboot.c [modify] https://crrev.com/5f9662229ae3322b372661d6d1c64216957bf736/arch/x86/kernel/asm-offsets_64.c [modify] https://crrev.com/5f9662229ae3322b372661d6d1c64216957bf736/arch/x86/entry/entry_32.S [modify] https://crrev.com/5f9662229ae3322b372661d6d1c64216957bf736/arch/x86/include/asm/processor.h [modify] https://crrev.com/5f9662229ae3322b372661d6d1c64216957bf736/arch/x86/include/asm/thread_info.h [modify] https://crrev.com/5f9662229ae3322b372661d6d1c64216957bf736/arch/x86/include/asm/switch_to.h [modify] https://crrev.com/5f9662229ae3322b372661d6d1c64216957bf736/arch/x86/kernel/process_32.c [modify] https://crrev.com/5f9662229ae3322b372661d6d1c64216957bf736/arch/x86/kernel/asm-offsets.c [modify] https://crrev.com/5f9662229ae3322b372661d6d1c64216957bf736/arch/x86/kernel/process_64.c [modify] https://crrev.com/5f9662229ae3322b372661d6d1c64216957bf736/arch/x86/kernel/asm-offsets_32.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/62a409113f43eaee4b77c62946e0b8fe679ac1b3 commit 62a409113f43eaee4b77c62946e0b8fe679ac1b3 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Jun 15 17:52:23 2018 UPSTREAM: x86: avoid avoid passing around 'thread_info' in stack dumping code None of the code actually wants a thread_info, it all wants a task_struct, and it's just converting to a thread_info pointer much too early. No semantic change. BUG= chromium:836330 TEST=Build and boot Change-Id: Ic30c0a7c5b3642301ffdee32360e57ed241aba32 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit da01e18a37a57f360222d3a123b8f6994aa1ad14) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077247 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/62a409113f43eaee4b77c62946e0b8fe679ac1b3/arch/x86/kernel/dumpstack_32.c [modify] https://crrev.com/62a409113f43eaee4b77c62946e0b8fe679ac1b3/arch/x86/kernel/dumpstack.c [modify] https://crrev.com/62a409113f43eaee4b77c62946e0b8fe679ac1b3/arch/x86/include/asm/stacktrace.h [modify] https://crrev.com/62a409113f43eaee4b77c62946e0b8fe679ac1b3/arch/x86/kernel/dumpstack_64.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a460536f648210a5d6cff6d1514c994a92048a39 commit a460536f648210a5d6cff6d1514c994a92048a39 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Jun 15 17:52:24 2018 UPSTREAM: x86: fix up a few misc stack pointer vs thread_info confusions As the actual pointer value is the same for the thread stack allocation and the thread_info, code that confused the two worked fine, but will break when the thread info is moved away from the stack allocation. It also looks very confusing. For example, the kprobe code wanted to know the current top of stack. To do that, it used this: (unsigned long)current_thread_info() + THREAD_SIZE which did indeed give the correct value. But it's not only a fairly nonsensical expression, it's also rather complex, especially since we actually have this: static inline unsigned long current_top_of_stack(void) which not only gives us the value we are interested in, but happens to be how "current_thread_info()" is currently defined as: (struct thread_info *)(current_top_of_stack() - THREAD_SIZE); so using current_thread_info() to figure out the top of the stack really is a very round-about thing to do. The other cases are just simpler confusion about task_thread_info() vs task_stack_page(), which currently return the same pointer - but if you want the stack page, you really should be using the latter one. And there was one entirely unused assignment of the current stack to a thread_info pointer. All cleaned up to make more sense today, and make it easier to move the thread_info away from the stack in the future. No semantic changes. BUG= chromium:836330 TEST=Build and boot Change-Id: If0c0169f5183fac1c4e49b6df6aeac2ebf9a7bf9 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit aca9c293d098292579e345b2b39b394778d41526) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077248 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/a460536f648210a5d6cff6d1514c994a92048a39/arch/x86/kernel/dumpstack.c [modify] https://crrev.com/a460536f648210a5d6cff6d1514c994a92048a39/arch/x86/include/asm/kprobes.h [modify] https://crrev.com/a460536f648210a5d6cff6d1514c994a92048a39/arch/x86/kernel/irq_32.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/501eca34435656e4c7656c170901d0191c1d0a4c commit 501eca34435656e4c7656c170901d0191c1d0a4c Author: Dmitry V. Levin <ldv@altlinux.org> Date: Fri Jun 15 17:52:26 2018 UPSTREAM: x86/signal: Cleanup get_nr_restart_syscall() Check for TS_COMPAT instead of TIF_IA32 to distinguish ia32 tasks from 64-bit tasks. Check for __X32_SYSCALL_BIT iff CONFIG_X86_X32_ABI is defined. BUG= chromium:836330 TEST=Build and boot Change-Id: I87e0f4898355a57f01a0c10330b48ef1ddde083a Suggested-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Acked-by: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Elvira Khabirova <lineprinter0@gmail.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20160111145515.GB29007@altlinux.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 95d97adb2bb85d964bae4538e0574e742e522dda) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077249 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/501eca34435656e4c7656c170901d0191c1d0a4c/arch/x86/kernel/signal.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1fe74205b88579316d8b8607d1245323481542d7 commit 1fe74205b88579316d8b8607d1245323481542d7 Author: Dmitry Safonov <dsafonov@virtuozzo.com> Date: Fri Jun 15 17:52:27 2018 UPSTREAM: x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall() The is_ia32_task()/is_x32_task() function names are a big misnomer: they suggests that the compat-ness of a system call is a task property, which is not true, the compatness of a system call purely depends on how it was invoked through the system call layer. A task may call 32-bit and 64-bit and x32 system calls without changing any of its kernel visible state. This specific minomer is also actively dangerous, as it might cause kernel developers to use the wrong kind of security checks within system calls. So rename it to in_{ia32,x32}_syscall(). BUG= chromium:836330 TEST=Build and boot Change-Id: Ic80fb7cdf2caeb9423d740d8c56a155757f31388 Suggested-by: Andy Lutomirski <luto@amacapital.net> Suggested-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com> [ Expanded the changelog. ] Acked-by: Andy Lutomirski <luto@kernel.org> Cc: 0x7f454c46@gmail.com Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: akpm@linux-foundation.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/1460987025-30360-1-git-send-email-dsafonov@virtuozzo.com Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit abfb9498ee1327f534df92a7ecaea81a85913bae) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077250 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/1fe74205b88579316d8b8607d1245323481542d7/arch/x86/kernel/signal.c [modify] https://crrev.com/1fe74205b88579316d8b8607d1245323481542d7/arch/x86/kernel/ptrace.c [modify] https://crrev.com/1fe74205b88579316d8b8607d1245323481542d7/arch/x86/entry/common.c [modify] https://crrev.com/1fe74205b88579316d8b8607d1245323481542d7/arch/x86/include/asm/compat.h [modify] https://crrev.com/1fe74205b88579316d8b8607d1245323481542d7/arch/x86/kernel/uprobes.c [modify] https://crrev.com/1fe74205b88579316d8b8607d1245323481542d7/arch/x86/include/asm/thread_info.h [modify] https://crrev.com/1fe74205b88579316d8b8607d1245323481542d7/arch/x86/kernel/process_64.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9ea37b92060191df1c8899488c2aa1e87251a681 commit 9ea37b92060191df1c8899488c2aa1e87251a681 Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:29 2018 UPSTREAM: signal: consolidate {TS,TLF}_RESTORE_SIGMASK code In general, there's no need for the "restore sigmask" flag to live in ti->flags. alpha, ia64, microblaze, powerpc, sh, sparc (64-bit only), tile, and x86 use essentially identical alternative implementations, placing the flag in ti->status. Replace those optimized implementations with an equally good common implementation that stores it in a bitfield in struct task_struct and drop the custom implementations. Additional architectures can opt in by removing their TIF_RESTORE_SIGMASK defines. BUG= chromium:836330 TEST=Build and boot Change-Id: I7639b86f5414deff873fb85341a56c65f81b32f6 Link: http://lkml.kernel.org/r/8a14321d64a28e40adfddc90e18a96c086a6d6f9.1468522723.git.luto@kernel.org Signed-off-by: Andy Lutomirski <luto@kernel.org> Tested-by: Michael Ellerman <mpe@ellerman.id.au> [powerpc] Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Chris Metcalf <cmetcalf@mellanox.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Borislav Petkov <bp@suse.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dmitry Safonov <dsafonov@virtuozzo.com> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 7e7814180b334dff97ef8f56c7c40c277ad4531c) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077251 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/9ea37b92060191df1c8899488c2aa1e87251a681/arch/ia64/include/asm/thread_info.h [modify] https://crrev.com/9ea37b92060191df1c8899488c2aa1e87251a681/arch/sh/include/asm/thread_info.h [modify] https://crrev.com/9ea37b92060191df1c8899488c2aa1e87251a681/arch/sparc/include/asm/thread_info_64.h [modify] https://crrev.com/9ea37b92060191df1c8899488c2aa1e87251a681/include/linux/thread_info.h [modify] https://crrev.com/9ea37b92060191df1c8899488c2aa1e87251a681/include/linux/sched.h [modify] https://crrev.com/9ea37b92060191df1c8899488c2aa1e87251a681/arch/powerpc/include/asm/thread_info.h [modify] https://crrev.com/9ea37b92060191df1c8899488c2aa1e87251a681/arch/microblaze/include/asm/thread_info.h [modify] https://crrev.com/9ea37b92060191df1c8899488c2aa1e87251a681/arch/x86/include/asm/thread_info.h [modify] https://crrev.com/9ea37b92060191df1c8899488c2aa1e87251a681/arch/alpha/include/asm/thread_info.h [modify] https://crrev.com/9ea37b92060191df1c8899488c2aa1e87251a681/arch/tile/include/asm/thread_info.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a0149ffd5305625f2270216e14d8db0b0ced173e commit a0149ffd5305625f2270216e14d8db0b0ced173e Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:30 2018 UPSTREAM: x86/ptrace: Stop setting TS_COMPAT in ptrace code Setting TS_COMPAT in ptrace is wrong: if we happen to do it during syscall entry, then we'll confuse seccomp and audit. (The former isn't a security problem: seccomp is currently entirely insecure if a malicious ptracer is attached.) As a minimal fix, this patch adds a new flag TS_I386_REGS_POKED that handles the ptrace special case. BUG= chromium:836330 TEST=Build and boot Change-Id: If0ce93f06a26c4ec04090fa6a469bf6346b5313d Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: Oleg Nesterov <oleg@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Pedro Alves <palves@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/5383ebed38b39fa37462139e337aff7f2314d1ca.1469599803.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 609c19a385c8744c41f944e2a2d8afe8e8fb860e) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077252 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/a0149ffd5305625f2270216e14d8db0b0ced173e/arch/x86/include/asm/syscall.h [modify] https://crrev.com/a0149ffd5305625f2270216e14d8db0b0ced173e/arch/x86/include/asm/thread_info.h [modify] https://crrev.com/a0149ffd5305625f2270216e14d8db0b0ced173e/arch/x86/kernel/ptrace.c [modify] https://crrev.com/a0149ffd5305625f2270216e14d8db0b0ced173e/arch/x86/entry/common.c [modify] https://crrev.com/a0149ffd5305625f2270216e14d8db0b0ced173e/arch/x86/kernel/signal.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7d24d6267629e4ef0f6645f7f8f94aac274dcb23 commit 7d24d6267629e4ef0f6645f7f8f94aac274dcb23 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Jun 15 17:52:32 2018 UPSTREAM: um/Stop conflating task_struct::stack with thread_info thread_info may move in the future, so use the accessors. [ Andy Lutomirski wrote this changelog message and changed "task_thread_info(child)->cpu" to "task_cpu(child)". ] BUG= chromium:836330 TEST=Build and run Change-Id: Ic74273bc53a81ccf9d4ed4c3444ce3597db67bc2 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jann Horn <jann@thejh.net> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/3439705d9838940cc82733a7335fa8c654c37db8.1473801993.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit d896fa20a70c9e596438728561e058a74ed3196b) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077253 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/7d24d6267629e4ef0f6645f7f8f94aac274dcb23/arch/x86/um/ptrace_32.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9ab380d8993d827237e85f032a0460cfb0d659da commit 9ab380d8993d827237e85f032a0460cfb0d659da Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:33 2018 BACKPORT: x86/uaccess: Move thread_info::uaccess_err and thread_info::sig_on_uaccess_err to thread_struct struct thread_info is a legacy mess. To prepare for its partial removal, move the uaccess control fields out -- they're straightforward. BUG= chromium:836330 TEST=Build and boot Backport Note: In order to use "current" within extable.c, include linux/sched.h Change-Id: I759027ccefacab7574edf47c37017dd58bbdcbae Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/d0ac4d01c8e4d4d756264604e47445d5acc7900e.1468527351.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit dfa9a942fd7951c8f333cf3f377dde51ebd21685) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077254 [modify] https://crrev.com/9ab380d8993d827237e85f032a0460cfb0d659da/arch/x86/include/asm/uaccess.h [modify] https://crrev.com/9ab380d8993d827237e85f032a0460cfb0d659da/arch/x86/include/asm/processor.h [modify] https://crrev.com/9ab380d8993d827237e85f032a0460cfb0d659da/arch/x86/mm/extable.c [modify] https://crrev.com/9ab380d8993d827237e85f032a0460cfb0d659da/arch/x86/mm/fault.c [modify] https://crrev.com/9ab380d8993d827237e85f032a0460cfb0d659da/arch/x86/entry/vsyscall/vsyscall_64.c [modify] https://crrev.com/9ab380d8993d827237e85f032a0460cfb0d659da/arch/x86/include/asm/thread_info.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/59264bc2bf9b6e6815524c201dd217a7819e77f7 commit 59264bc2bf9b6e6815524c201dd217a7819e77f7 Author: Ingo Molnar <mingo@kernel.org> Date: Fri Jun 15 17:52:35 2018 UPSTREAM: x86/dumpstack: Rename thread_struct::sig_on_uaccess_error to sig_on_uaccess_err Rename it to match the thread_struct::uaccess_err pattern and also because it was too long. BUG= chromium:836330 TEST=Build and boot Change-Id: I787a6240a911cc9fc00725e9900d5e4c1c3c63ff Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 2a53ccbc0de1b1950aeedd24680f7eca65c86ff5) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077255 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/59264bc2bf9b6e6815524c201dd217a7819e77f7/arch/x86/mm/fault.c [modify] https://crrev.com/59264bc2bf9b6e6815524c201dd217a7819e77f7/arch/x86/entry/vsyscall/vsyscall_64.c [modify] https://crrev.com/59264bc2bf9b6e6815524c201dd217a7819e77f7/arch/x86/include/asm/processor.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3a21ce6179040e4c68f2b2b8761d0960e6e7caa5 commit 3a21ce6179040e4c68f2b2b8761d0960e6e7caa5 Author: Brian Gerst <brgerst@gmail.com> Date: Fri Jun 15 17:52:36 2018 UPSTREAM: x86/entry/32: Remove GET_THREAD_INFO() from entry code The entry code used to cache the thread_info pointer in the EBP register, but all the code that used it has been moved to C. Remove the unused code to get the pointer. BUG= chromium:836330 TEST=Build and boot Change-Id: I0a9524567203b66160950c809f8ba59ee5be82e9 Signed-off-by: Brian Gerst <brgerst@gmail.com> Acked-by: Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Borislav Petkov <bp@suse.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1462416278-11974-3-git-send-email-brgerst@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 1e17880371f85d3d866962e04ba3567c0654a125) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077256 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/3a21ce6179040e4c68f2b2b8761d0960e6e7caa5/arch/x86/entry/entry_32.S
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f9dff2c63a4089df076ea9b2e6a277160048b3f9 commit f9dff2c63a4089df076ea9b2e6a277160048b3f9 Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:38 2018 UPSTREAM: x86/uaccess: Move thread_info::addr_limit to thread_struct struct thread_info is a legacy mess. To prepare for its partial removal, move thread_info::addr_limit out. As an added benefit, this way is simpler. BUG= chromium:836330 TEST=Build and boot Change-Id: I85c81c960923c7e9c3c54832b25e78450c3bd8ab Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/15bee834d09402b47ac86f2feccdf6529f9bc5b0.1468527351.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 13d4ea097d18b419ad2a2b696063d44bf59acec0) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077257 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/f9dff2c63a4089df076ea9b2e6a277160048b3f9/arch/x86/lib/copy_user_64.S [modify] https://crrev.com/f9dff2c63a4089df076ea9b2e6a277160048b3f9/arch/x86/lib/getuser.S [modify] https://crrev.com/f9dff2c63a4089df076ea9b2e6a277160048b3f9/arch/x86/lib/putuser.S [modify] https://crrev.com/f9dff2c63a4089df076ea9b2e6a277160048b3f9/arch/x86/include/asm/uaccess.h [modify] https://crrev.com/f9dff2c63a4089df076ea9b2e6a277160048b3f9/arch/x86/include/asm/processor.h [modify] https://crrev.com/f9dff2c63a4089df076ea9b2e6a277160048b3f9/arch/x86/lib/usercopy_64.c [modify] https://crrev.com/f9dff2c63a4089df076ea9b2e6a277160048b3f9/drivers/pnp/isapnp/proc.c [modify] https://crrev.com/f9dff2c63a4089df076ea9b2e6a277160048b3f9/lib/bitmap.c [modify] https://crrev.com/f9dff2c63a4089df076ea9b2e6a277160048b3f9/arch/x86/include/asm/thread_info.h [modify] https://crrev.com/f9dff2c63a4089df076ea9b2e6a277160048b3f9/arch/x86/lib/csum-wrappers_64.c [modify] https://crrev.com/f9dff2c63a4089df076ea9b2e6a277160048b3f9/arch/x86/kernel/asm-offsets.c [modify] https://crrev.com/f9dff2c63a4089df076ea9b2e6a277160048b3f9/arch/x86/include/asm/checksum_32.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8e7cc3b99cacd381fc5f0ee4990c81a70d7c8377 commit 8e7cc3b99cacd381fc5f0ee4990c81a70d7c8377 Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:41 2018 UPSTREAM: x86/smp: Remove unnecessary initialization of thread_info::cpu It's statically initialized to zero -- no need to dynamically initialize it to zero as well. BUG= chromium:836330 TEST=Build and boot Change-Id: I7737f1f7ccf02974c86264c4a8356796a73cf27a Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/6cf6314dce3051371a913ee19d1b88e29c68c560.1468527351.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit eb43e8f85fffc1ba535e0362a872101dfe48abe3) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077259 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/8e7cc3b99cacd381fc5f0ee4990c81a70d7c8377/arch/x86/kernel/smpboot.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/fa105c81d43ee588efcf848d2113c81ca4489815 commit fa105c81d43ee588efcf848d2113c81ca4489815 Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:39 2018 UPSTREAM: x86/asm: Move the thread_info::status field to thread_struct Because sched.h and thread_info.h are a tangled mess, I turned in_compat_syscall() into a macro. If we had current_thread_struct() or similar and we could use it from thread_info.h, then this would be a bit cleaner. BUG= chromium:836330 TEST=Build and boot Change-Id: I621f7a8cb8e9082e14f2efc054076c7c8d15e62a Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jann Horn <jann@thejh.net> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/ccc8a1b2f41f9c264a41f771bb4a6539a642ad72.1473801993.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit b9d989c7218ac922185d82ad46f3e58b27a4bea9) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077258 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/fa105c81d43ee588efcf848d2113c81ca4489815/arch/x86/kernel/signal.c [modify] https://crrev.com/fa105c81d43ee588efcf848d2113c81ca4489815/arch/x86/kernel/ptrace.c [modify] https://crrev.com/fa105c81d43ee588efcf848d2113c81ca4489815/arch/x86/entry/common.c [modify] https://crrev.com/fa105c81d43ee588efcf848d2113c81ca4489815/arch/x86/kernel/fpu/init.c [modify] https://crrev.com/fa105c81d43ee588efcf848d2113c81ca4489815/arch/x86/include/asm/processor.h [modify] https://crrev.com/fa105c81d43ee588efcf848d2113c81ca4489815/arch/x86/include/asm/thread_info.h [modify] https://crrev.com/fa105c81d43ee588efcf848d2113c81ca4489815/arch/x86/include/asm/syscall.h [modify] https://crrev.com/fa105c81d43ee588efcf848d2113c81ca4489815/arch/x86/kernel/asm-offsets.c [modify] https://crrev.com/fa105c81d43ee588efcf848d2113c81ca4489815/arch/x86/kernel/process_64.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/190c847c8f74604aba97099441004c3ade2918fd commit 190c847c8f74604aba97099441004c3ade2918fd Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:43 2018 UPSTREAM: x86/smp: Remove stack_smp_processor_id() It serves no purpose -- raw_smp_processor_id() works fine. This change will be needed to move thread_info off the stack. BUG= chromium:836330 TEST=Build and boot Change-Id: I0db1e9dfe7b60d02cfd20fb25ff2508acf788a0b Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/a2bf4f07fbc30fb32f9f7f3f8f94ad3580823847.1468527351.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit fb59831b496a5bb7d0a06c7e702d88d1757edfca) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077260 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/190c847c8f74604aba97099441004c3ade2918fd/arch/x86/kernel/cpu/common.c [modify] https://crrev.com/190c847c8f74604aba97099441004c3ade2918fd/arch/x86/include/asm/cpu.h [modify] https://crrev.com/190c847c8f74604aba97099441004c3ade2918fd/arch/x86/include/asm/smp.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/49d1d2cbd2c070b0cc7456529abe8fb4f6b3d66c commit 49d1d2cbd2c070b0cc7456529abe8fb4f6b3d66c Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Jun 15 17:52:44 2018 BACKPORT: x86/entry: Get rid of pt_regs_to_thread_info() It was a nice optimization while it lasted, but thread_info is moving and this optimization will no longer work. Quoting Linus: Oh Gods, Andy. That pt_regs_to_thread_info() thing made me want to do unspeakable acts on a poor innocent wax figure that looked _exactly_ like you. BUG= chromium:836330 TEST=Build and boot Backport note: There is a need to replace pt_regs_to_thread_info with current_thread_info in both syscall_trace_enter_phase1 and syscall_trace_enter_phase2. Change-Id: I97c3c1e6ed26658499e3af96bc4f0d7f0f98a4cb [ Changelog written by Andy. ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jann Horn <jann@thejh.net> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/6376aa81c68798cc81631673f52bd91a3e078944.1473801993.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 97245d00585d82540f4538cf72d92a1e853c7b0e) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077261 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/49d1d2cbd2c070b0cc7456529abe8fb4f6b3d66c/arch/x86/entry/common.c
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7e5f209c5ac4ab9bed4ded23def23cc91305a7b0 commit 7e5f209c5ac4ab9bed4ded23def23cc91305a7b0 Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:46 2018 BACKPORT: x86: Move thread_info into task_struct Now that most of the thread_info users have been cleaned up, this is straightforward. Most of this code was written by Linus. BUG= chromium:836330 TEST=Build and boot Backport Notes : - The original patch removes the thread_info from arch/x86/include/asm/thread_info.h. This is not possible as thread_info in v4.4 has been modified to accomodate CONFIG_ALT_SYSCALL and CONFIG_IA32_EMULATION. Also, note that a later patch moves thread_info back into arch/x86/include/asm/thread_info.h - In entry_64.S there are locations that use nr_syscalls, sys_call_table if CONFIG_ALT_SYSCALL/CONFIG_IA32_EMULATION is enabled. Accesses to these need to be via current_task.thread_info. Change-Id: If3796b09b8c4e693116d2617f0f5d9ac3d658f88 Originally-from: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jann Horn <jann@thejh.net> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/a50eab40abeaec9cb9a9e3cbdeafd32190206654.1473801993.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 15f4eae70d365bba26854c90b6002aaabb18c8aa) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077262 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/7e5f209c5ac4ab9bed4ded23def23cc91305a7b0/arch/x86/entry/entry_64.S [modify] https://crrev.com/7e5f209c5ac4ab9bed4ded23def23cc91305a7b0/arch/x86/kernel/process.c [modify] https://crrev.com/7e5f209c5ac4ab9bed4ded23def23cc91305a7b0/include/linux/thread_info.h [modify] https://crrev.com/7e5f209c5ac4ab9bed4ded23def23cc91305a7b0/arch/x86/kernel/irq_64.c [modify] https://crrev.com/7e5f209c5ac4ab9bed4ded23def23cc91305a7b0/arch/x86/include/asm/thread_info.h [modify] https://crrev.com/7e5f209c5ac4ab9bed4ded23def23cc91305a7b0/arch/x86/kernel/asm-offsets.c [modify] https://crrev.com/7e5f209c5ac4ab9bed4ded23def23cc91305a7b0/arch/x86/Kconfig
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f32d853af696c00855bfd0f57711e1fd7d8b7773 commit f32d853af696c00855bfd0f57711e1fd7d8b7773 Author: Andy Lutomirski <luto@kernel.org> Date: Fri Jun 15 17:52:47 2018 UPSTREAM: x86/entry/64: Fix a minor comment rebase error When I rebased my thread_info changes onto Brian's switch_to() changes, I carefully checked that I fixed up all the code correctly, but I missed a comment :( BUG= chromium:836330 TEST=Build and boot Change-Id: I9096873a389ca985bc8f7fb5d485762c5550ee6b Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jann Horn <jann@thejh.net> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 15f4eae70d36 ("x86: Move thread_info into task_struct") Link: http://lkml.kernel.org/r/089fe1e1cbe8b258b064fccbb1a5a5fd23861031.1474003868.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit ff0071c03684485495e06f3936399eb9c93141a6) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077263 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/f32d853af696c00855bfd0f57711e1fd7d8b7773/arch/x86/entry/entry_64.S
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c013ee84d72bb0c955b6e2617396584f213484b8 commit c013ee84d72bb0c955b6e2617396584f213484b8 Author: Xi Kangjie <imxikangjie@gmail.com> Date: Fri Jun 15 17:52:49 2018 UPSTREAM: scripts/gdb/linux/tasks.py: fix get_thread_info Since kernel 4.9, the thread_info has been moved into task_struct, no longer locates at the bottom of kernel stack. See commits c65eacbe290b ("sched/core: Allow putting thread_info into task_struct") and 15f4eae70d36 ("x86: Move thread_info into task_struct"). Before fix: (gdb) set $current = $lx_current() (gdb) p $lx_thread_info($current) $1 = {flags = 1470918301} (gdb) p $current.thread_info $2 = {flags = 2147483648} After fix: (gdb) p $lx_thread_info($current) $1 = {flags = 2147483648} (gdb) p $current.thread_info $2 = {flags = 2147483648} BUG= chromium:836330 TEST=Build and boot Change-Id: If5fe446f2b2736728c728f0feb363e4990fa1171 Link: http://lkml.kernel.org/r/20180118210159.17223-1-imxikangjie@gmail.com Fixes: 15f4eae70d36 ("x86: Move thread_info into task_struct") Signed-off-by: Xi Kangjie <imxikangjie@gmail.com> Acked-by: Jan Kiszka <jan.kiszka@siemens.com> Acked-by: Kieran Bingham <kbingham@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 883d50f56d263f70fd73c0d96b09eb36c34e9305) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077264 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/c013ee84d72bb0c955b6e2617396584f213484b8/scripts/gdb/linux/tasks.py
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5ade05ea9408a426bec1ae7d9599bb2c55fc957b commit 5ade05ea9408a426bec1ae7d9599bb2c55fc957b Author: Mark Rutland <mark.rutland@arm.com> Date: Fri Jun 15 17:52:50 2018 UPSTREAM: thread_info: include <current.h> for THREAD_INFO_IN_TASK When CONFIG_THREAD_INFO_IN_TASK is selected, the current_thread_info() macro relies on current having been defined prior to its use. However, not all users of current_thread_info() include <asm/current.h>, and thus current is not guaranteed to be defined. When CONFIG_THREAD_INFO_IN_TASK is not selected, it's possible that get_current() / current are based upon current_thread_info(), and <asm/current.h> includes <asm/thread_info.h>. Thus always including <asm/current.h> would result in circular dependences on some platforms. To ensure both cases work, this patch includes <asm/current.h>, but only when CONFIG_THREAD_INFO_IN_TASK is selected. BUG= chromium:836330 TEST=Build and boot Change-Id: I095757ca7147ab5d5dcc35d4e628cdb0e2311858 Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Reviewed-by: Andy Lutomirski <luto@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit dc3d2a679cd8631b8a570fc8ca5f4712d7d25698) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1077265 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/5ade05ea9408a426bec1ae7d9599bb2c55fc957b/include/linux/thread_info.h
,
Jun 16 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ceb568925daa715c2aadfccb533012310f59ab60 commit ceb568925daa715c2aadfccb533012310f59ab60 Author: Guenter Roeck <groeck@chromium.org> Date: Sat Jun 16 07:44:05 2018 FIXUP: BACKPORT: x86: Move thread_info into task_struct One instance of ASM_THREAD_INFO() was not replaced, resulting in an assembler error. BUG= chromium:836330 TEST=Build x86_64:allmodconfig Change-Id: I7e399e795475e173ca0c44108cdcee7c8cfae723 Signed-off-by: Guenter Roeck <groeck@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1102984 Reviewed-by: Zubin Mithra <zsm@chromium.org> [modify] https://crrev.com/ceb568925daa715c2aadfccb533012310f59ab60/arch/x86/entry/entry_64.S
,
Jun 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/112ca3af722e21f24febaa8df451f92754b596f0 commit 112ca3af722e21f24febaa8df451f92754b596f0 Author: Brian Gerst <brgerst@gmail.com> Date: Wed Jun 20 05:41:21 2018 UPSTREAM: sched/x86/32, kgdb: Don't use thread.ip in sleeping_thread_to_gdb_regs() Match 64-bit and set gdb_regs[GDB_PC] to zero. thread.ip is always the same point in the scheduler (except for newly forked processes), and will be removed in a future patch. Signed-off-by: Brian Gerst <brgerst@gmail.com> Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1471106302-10159-2-git-send-email-brgerst@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 4e047aa7f267c3449b6d323510d35864829aca70) BUG= chromium:836330 TEST=Build i386:allmodconfig Change-Id: Ib54236a6833fe82e5ecff6390a1d46d2918624aa Signed-off-by: Guenter Roeck <groeck@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1104585 Reviewed-by: Zubin Mithra <zsm@chromium.org> [modify] https://crrev.com/112ca3af722e21f24febaa8df451f92754b596f0/arch/x86/kernel/kgdb.c
,
Aug 6
These patches have been in for a while now, closing the bug. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by zsm@chromium.org
, Apr 30 2018