linux-stable.git/arch/parisc/kernel/process.c, branch v5.8 Linux kernel stable tree maccess: make get_kernel_nofault() check for minimal type compatibility 2020-06-18T19:10:37+00:00 Linus Torvalds torvalds@linux-foundation.org 2020-06-18T19:10:37+00:00 0c389d89abc28edf70ae847ee2fa55acb267b826 Now that we've renamed probe_kernel_address() to get_kernel_nofault() and made it look and behave more in line with get_user(), some of the subtle type behavior differences end up being more obvious and possibly dangerous. When you do get_user(val, user_ptr); the type of the access comes from the "user_ptr" part, and the above basically acts as val = *user_ptr; by design (except, of course, for the fact that the actual dereference is done with a user access). Note how in the above case, the type of the end result comes from the pointer argument, and then the value is cast to the type of 'val' as part of the assignment. So the type of the pointer is ultimately the more important type both for the access itself. But 'get_kernel_nofault()' may now _look_ similar, but it behaves very differently. When you do get_kernel_nofault(val, kernel_ptr); it behaves like val = *(typeof(val) *)kernel_ptr; except, of course, for the fact that the actual dereference is done with exception handling so that a faulting access is suppressed and returned as the error code. But note how different the casting behavior of the two superficially similar accesses are: one does the actual access in the size of the type the pointer points to, while the other does the access in the size of the target, and ignores the pointer type entirely. Actually changing get_kernel_nofault() to act like get_user() is almost certainly the right thing to do eventually, but in the meantime this patch adds logit to at least verify that the pointer type is compatible with the type of the result. In many cases, this involves just casting the pointer to 'void *' to make it obvious that the type of the pointer is not the important part. It's not how 'get_user()' acts, but at least the behavioral difference is now obvious and explicit. Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Now that we've renamed probe_kernel_address() to get_kernel_nofault()
and made it look and behave more in line with get_user(), some of the
subtle type behavior differences end up being more obvious and possibly
dangerous.

When you do

        get_user(val, user_ptr);

the type of the access comes from the "user_ptr" part, and the above
basically acts as

        val = *user_ptr;

by design (except, of course, for the fact that the actual dereference
is done with a user access).

Note how in the above case, the type of the end result comes from the
pointer argument, and then the value is cast to the type of 'val' as
part of the assignment.

So the type of the pointer is ultimately the more important type both
for the access itself.

But 'get_kernel_nofault()' may now _look_ similar, but it behaves very
differently.  When you do

        get_kernel_nofault(val, kernel_ptr);

it behaves like

        val = *(typeof(val) *)kernel_ptr;

except, of course, for the fact that the actual dereference is done with
exception handling so that a faulting access is suppressed and returned
as the error code.

But note how different the casting behavior of the two superficially
similar accesses are: one does the actual access in the size of the type
the pointer points to, while the other does the access in the size of
the target, and ignores the pointer type entirely.

Actually changing get_kernel_nofault() to act like get_user() is almost
certainly the right thing to do eventually, but in the meantime this
patch adds logit to at least verify that the pointer type is compatible
with the type of the result.

In many cases, this involves just casting the pointer to 'void *' to
make it obvious that the type of the pointer is not the important part.
It's not how 'get_user()' acts, but at least the behavioral difference
is now obvious and explicit.

Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
maccess: rename probe_kernel_address to get_kernel_nofault 2020-06-18T18:14:40+00:00 Christoph Hellwig hch@lst.de 2020-06-17T07:37:55+00:00 25f12ae45fc1931a1dce3cc59f9989a9d87834b0 Better describe what this helper does, and match the naming of copy_from_kernel_nofault. Also switch the argument order around, so that it acts and looks like get_user(). Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Better describe what this helper does, and match the naming of
copy_from_kernel_nofault.

Also switch the argument order around, so that it acts and looks
like get_user().

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
parisc: Implement copy_thread_tls 2020-01-07T12:31:21+00:00 Amanieu d'Antras amanieu@gmail.com 2020-01-02T17:24:10+00:00 d2f36c787b2181561d8b95814f8cdad64b348ad7 This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <amanieu@gmail.com> Cc: linux-parisc@vger.kernel.org Cc: <stable@vger.kernel.org> # 5.3.x Link: https://lore.kernel.org/r/20200102172413.654385-5-amanieu@gmail.com Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> 
This is required for clone3 which passes the TLS value through a
struct rather than a register.

Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
Cc: linux-parisc@vger.kernel.org
Cc: <stable@vger.kernel.org> # 5.3.x
Link: https://lore.kernel.org/r/20200102172413.654385-5-amanieu@gmail.com
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156 2019-05-30T18:26:35+00:00 Thomas Gleixner tglx@linutronix.de 2019-05-27T06:55:05+00:00 1a59d1b8e05ea6ab45f7e18897de1ef0e6bc3da6 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1334 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version this program is distributed in the
  hope that it will be useful but without any warranty without even
  the implied warranty of merchantability or fitness for a particular
  purpose see the gnu general public license for more details you
  should have received a copy of the gnu general public license along
  with this program if not write to the free software foundation inc
  59 temple place suite 330 boston ma 02111 1307 usa

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 1334 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
parisc: Use __ro_after_init in process.c 2019-05-10T19:00:45+00:00 Helge Deller deller@gmx.de 2019-05-10T18:54:31+00:00 7e4c65bf0637c089d8981ac7e99081a57ffbcdbc Signed-off-by: Helge Deller <deller@gmx.de> 
Signed-off-by: Helge Deller <deller@gmx.de>
parisc: Export running_on_qemu symbol for modules 2019-05-03T21:47:38+00:00 Helge Deller deller@gmx.de 2019-04-06T14:45:14+00:00 3e1120f4b57bc12437048494ab56648edaa5b57d Signed-off-by: Helge Deller <deller@gmx.de> CC: stable@vger.kernel.org # v4.9+ 
Signed-off-by: Helge Deller <deller@gmx.de>
CC: stable@vger.kernel.org # v4.9+
parisc: Detect QEMU earlier in boot process 2019-04-06T17:07:55+00:00 Helge Deller deller@gmx.de 2019-04-02T10:13:27+00:00 d006e95b5561f708d0385e9677ffe2c46f2ae345 While adding LASI support to QEMU, I noticed that the QEMU detection in the kernel happens much too late. For example, when a LASI chip is found by the kernel, it registers the LASI LED driver as well. But when we run on QEMU it makes sense to avoid spending unnecessary CPU cycles, so we need to access the running_on_QEMU flag earlier than before. This patch now makes the QEMU detection the fist task of the Linux kernel by moving it to where the kernel enters the C-coding. Fixes: 310d82784fb4 ("parisc: qemu idle sleep support") Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v4.14+ 
While adding LASI support to QEMU, I noticed that the QEMU detection in
the kernel happens much too late. For example, when a LASI chip is found
by the kernel, it registers the LASI LED driver as well.  But when we
run on QEMU it makes sense to avoid spending unnecessary CPU cycles, so
we need to access the running_on_QEMU flag earlier than before.

This patch now makes the QEMU detection the fist task of the Linux
kernel by moving it to where the kernel enters the C-coding.

Fixes: 310d82784fb4 ("parisc: qemu idle sleep support")
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # v4.14+
parisc: Fix and improve kernel stack unwinding 2018-08-13T07:54:17+00:00 Helge Deller deller@gmx.de 2018-08-04T22:03:29+00:00 c8921d72e390cb6fca3fb2b0c2badfda851647eb This patchset fixes and improves stack unwinding a lot: 1. Show backward stack traces with up to 30 callsites 2. Add callinfo to ENTRY_CFI() such that every assembler function will get an entry in the unwind table 3. Use constants instead of numbers in call_on_stack() 4. Do not depend on CONFIG_KALLSYMS to generate backtraces. 5. Speed up backtrace generation Make sure you have this patch to GNU as installed: https://sourceware.org/ml/binutils/2018-07/msg00474.html Without this patch, unwind info in the kernel is often wrong for various functions. Signed-off-by: Helge Deller <deller@gmx.de> 
This patchset fixes and improves stack unwinding a lot:
1. Show backward stack traces with up to 30 callsites
2. Add callinfo to ENTRY_CFI() such that every assembler function will get an
   entry in the unwind table
3. Use constants instead of numbers in call_on_stack()
4. Do not depend on CONFIG_KALLSYMS to generate backtraces.
5. Speed up backtrace generation

Make sure you have this patch to GNU as installed:
https://sourceware.org/ml/binutils/2018-07/msg00474.html
Without this patch, unwind info in the kernel is often wrong for various
functions.

Signed-off-by: Helge Deller <deller@gmx.de>
parisc: Prevent panic at system halt 2018-04-11T20:28:41+00:00 Helge Deller deller@gmx.de 2018-04-11T20:27:07+00:00 67698287031be7c1821f9b151237ca8cdb231fd1 When issuing a "shutdown -h now", the reboot syscall calls kernel_halt() which shouldn't return, otherwise one gets this panic: reboot: System halted Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.16.0-32bit+ #560 Backtrace: [<1018a694>] show_stack+0x18/0x28 [<106e68a8>] dump_stack+0x80/0x10c [<101a4df8>] panic+0xfc/0x290 [<101a90b8>] do_exit+0x73c/0x914 [<101c7e38>] SyS_reboot+0x190/0x1d4 [<1017e444>] syscall_exit+0x0/0x14 Fix it by letting machine_halt() call machine_power_off() which doesn't return. Signed-off-by: Helge Deller <deller@gmx.de> 
When issuing a "shutdown -h now", the reboot syscall calls kernel_halt()
which shouldn't return, otherwise one gets this panic:

reboot: System halted
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.16.0-32bit+ #560
Backtrace:
 [<1018a694>] show_stack+0x18/0x28
 [<106e68a8>] dump_stack+0x80/0x10c
 [<101a4df8>] panic+0xfc/0x290
 [<101a90b8>] do_exit+0x73c/0x914
 [<101c7e38>] SyS_reboot+0x190/0x1d4
 [<1017e444>] syscall_exit+0x0/0x14

Fix it by letting machine_halt() call machine_power_off() which doesn't
return.

Signed-off-by: Helge Deller <deller@gmx.de>
parisc: machine_power_off() should call pm_power_off() 2018-03-27T16:52:22+00:00 Helge Deller deller@gmx.de 2018-03-24T19:49:39+00:00 24002d59376e2d19a2a523fe88d5b32e691a43af Signed-off-by: Helge Deller <deller@gmx.de> Tested-by: Matt Turner <mattst88@gmail.com> 
Signed-off-by: Helge Deller <deller@gmx.de>
Tested-by: Matt Turner <mattst88@gmail.com>