<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/arm/kernel/traps.c, branch v5.4.272</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>exit: Add and use make_task_dead.</title>
<updated>2023-02-06T06:52:49+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2023-02-02T04:42:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=9a18c9c8336fff473a2b72707bd14a52298417b8'/>
<id>9a18c9c8336fff473a2b72707bd14a52298417b8</id>
<content type='text'>
commit 0e25498f8cd43c1b5aa327f373dd094e9a006da7 upstream.

There are two big uses of do_exit.  The first is it's design use to be
the guts of the exit(2) system call.  The second use is to terminate
a task after something catastrophic has happened like a NULL pointer
in kernel code.

Add a function make_task_dead that is initialy exactly the same as
do_exit to cover the cases where do_exit is called to handle
catastrophic failure.  In time this can probably be reduced to just a
light wrapper around do_task_dead. For now keep it exactly the same so
that there will be no behavioral differences introducing this new
concept.

Replace all of the uses of do_exit that use it for catastraphic
task cleanup with make_task_dead to make it clear what the code
is doing.

As part of this rename rewind_stack_do_exit
rewind_stack_and_make_dead.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0e25498f8cd43c1b5aa327f373dd094e9a006da7 upstream.

There are two big uses of do_exit.  The first is it's design use to be
the guts of the exit(2) system call.  The second use is to terminate
a task after something catastrophic has happened like a NULL pointer
in kernel code.

Add a function make_task_dead that is initialy exactly the same as
do_exit to cover the cases where do_exit is called to handle
catastrophic failure.  In time this can probably be reduced to just a
light wrapper around do_task_dead. For now keep it exactly the same so
that there will be no behavioral differences introducing this new
concept.

Replace all of the uses of do_exit that use it for catastraphic
task cleanup with make_task_dead to make it clear what the code
is doing.

As part of this rename rewind_stack_do_exit
rewind_stack_and_make_dead.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: Spectre-BHB workaround</title>
<updated>2022-03-11T10:22:38+00:00</updated>
<author>
<name>Russell King (Oracle)</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2022-02-10T16:05:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=920f7970cf0db39f7f5387dc0af8620627726957'/>
<id>920f7970cf0db39f7f5387dc0af8620627726957</id>
<content type='text'>
commit b9baf5c8c5c356757f4f9d8180b5e9d234065bc3 upstream.

Workaround the Spectre BHB issues for Cortex-A15, Cortex-A57,
Cortex-A72, Cortex-A73 and Cortex-A75. We also include Brahma B15 as
well to be safe, which is affected by Spectre V2 in the same ways as
Cortex-A15.

Reviewed-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
[changes due to lack of SYSTEM_FREEING_INITMEM - gregkh]
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b9baf5c8c5c356757f4f9d8180b5e9d234065bc3 upstream.

Workaround the Spectre BHB issues for Cortex-A15, Cortex-A57,
Cortex-A72, Cortex-A73 and Cortex-A75. We also include Brahma B15 as
well to be safe, which is affected by Spectre V2 in the same ways as
Cortex-A15.

Reviewed-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
[changes due to lack of SYSTEM_FREEING_INITMEM - gregkh]
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: early traps initialisation</title>
<updated>2022-03-11T10:22:38+00:00</updated>
<author>
<name>Russell King (Oracle)</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2022-02-11T19:46:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=31814db6e478d41a161092e436af66d84ff5d072'/>
<id>31814db6e478d41a161092e436af66d84ff5d072</id>
<content type='text'>
commit 04e91b7324760a377a725e218b5ee783826d30f5 upstream.

Provide a couple of helpers to copy the vectors and stubs, and also
to flush the copied vectors and stubs.

Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 04e91b7324760a377a725e218b5ee783826d30f5 upstream.

Provide a couple of helpers to copy the vectors and stubs, and also
to flush the copied vectors and stubs.

Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8948/1: Prevent OOB access in stacktrace</title>
<updated>2020-10-01T11:17:29+00:00</updated>
<author>
<name>Vincent Whitchurch</name>
<email>vincent.whitchurch@axis.com</email>
</author>
<published>2019-12-16T10:48:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=47634c0fc94c398c0d37c36be171aa0e3e6c5207'/>
<id>47634c0fc94c398c0d37c36be171aa0e3e6c5207</id>
<content type='text'>
[ Upstream commit 40ff1ddb5570284e039e0ff14d7a859a73dc3673 ]

The stacktrace code can read beyond the stack size, when it attempts to
read pt_regs from exception frames.

This can happen on normal, non-corrupt stacks.  Since the unwind
information in the extable is not correct for function prologues, the
unwinding code can return data from the stack which is not actually the
caller function address, and if in_entry_text() happens to succeed on
this value, we can end up reading data from outside the task's stack
when attempting to read pt_regs, since there is no bounds check.

Example:

 [&lt;8010e729&gt;] (unwind_backtrace) from [&lt;8010a9c9&gt;] (show_stack+0x11/0x14)
 [&lt;8010a9c9&gt;] (show_stack) from [&lt;8057d8d7&gt;] (dump_stack+0x87/0xac)
 [&lt;8057d8d7&gt;] (dump_stack) from [&lt;8012271d&gt;] (tasklet_action_common.constprop.4+0xa5/0xa8)
 [&lt;8012271d&gt;] (tasklet_action_common.constprop.4) from [&lt;80102333&gt;] (__do_softirq+0x11b/0x31c)
 [&lt;80102333&gt;] (__do_softirq) from [&lt;80122485&gt;] (irq_exit+0xad/0xd8)
 [&lt;80122485&gt;] (irq_exit) from [&lt;8015f3d7&gt;] (__handle_domain_irq+0x47/0x84)
 [&lt;8015f3d7&gt;] (__handle_domain_irq) from [&lt;8036a523&gt;] (gic_handle_irq+0x43/0x78)
 [&lt;8036a523&gt;] (gic_handle_irq) from [&lt;80101a49&gt;] (__irq_svc+0x69/0xb4)
 Exception stack(0xeb491f58 to 0xeb491fa0)
 1f40:                                                       7eb14794 00000000
 1f60: ffffffff 008dd32c 008dd324 ffffffff 008dd314 0000002a 801011e4 eb490000
 1f80: 0000002a 7eb1478c 50c5387d eb491fa8 80101001 8023d09c 40080033 ffffffff
 [&lt;80101a49&gt;] (__irq_svc) from [&lt;8023d09c&gt;] (do_pipe2+0x0/0xac)
 [&lt;8023d09c&gt;] (do_pipe2) from [&lt;ffffffff&gt;] (0xffffffff)
 Exception stack(0xeb491fc8 to 0xeb492010)
 1fc0:                   008dd314 0000002a 00511ad8 008de4c8 7eb14790 7eb1478c
 1fe0: 00511e34 7eb14774 004c8557 76f44098 60080030 7eb14794 00000000 00000000
 2000: 00000001 00000000 ea846c00 ea847cc0

In this example, the stack limit is 0xeb492000, but 16 bytes outside the
stack have been read.

Fix it by adding bounds checks.

Signed-off-by: Vincent Whitchurch &lt;vincent.whitchurch@axis.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 40ff1ddb5570284e039e0ff14d7a859a73dc3673 ]

The stacktrace code can read beyond the stack size, when it attempts to
read pt_regs from exception frames.

This can happen on normal, non-corrupt stacks.  Since the unwind
information in the extable is not correct for function prologues, the
unwinding code can return data from the stack which is not actually the
caller function address, and if in_entry_text() happens to succeed on
this value, we can end up reading data from outside the task's stack
when attempting to read pt_regs, since there is no bounds check.

Example:

 [&lt;8010e729&gt;] (unwind_backtrace) from [&lt;8010a9c9&gt;] (show_stack+0x11/0x14)
 [&lt;8010a9c9&gt;] (show_stack) from [&lt;8057d8d7&gt;] (dump_stack+0x87/0xac)
 [&lt;8057d8d7&gt;] (dump_stack) from [&lt;8012271d&gt;] (tasklet_action_common.constprop.4+0xa5/0xa8)
 [&lt;8012271d&gt;] (tasklet_action_common.constprop.4) from [&lt;80102333&gt;] (__do_softirq+0x11b/0x31c)
 [&lt;80102333&gt;] (__do_softirq) from [&lt;80122485&gt;] (irq_exit+0xad/0xd8)
 [&lt;80122485&gt;] (irq_exit) from [&lt;8015f3d7&gt;] (__handle_domain_irq+0x47/0x84)
 [&lt;8015f3d7&gt;] (__handle_domain_irq) from [&lt;8036a523&gt;] (gic_handle_irq+0x43/0x78)
 [&lt;8036a523&gt;] (gic_handle_irq) from [&lt;80101a49&gt;] (__irq_svc+0x69/0xb4)
 Exception stack(0xeb491f58 to 0xeb491fa0)
 1f40:                                                       7eb14794 00000000
 1f60: ffffffff 008dd32c 008dd324 ffffffff 008dd314 0000002a 801011e4 eb490000
 1f80: 0000002a 7eb1478c 50c5387d eb491fa8 80101001 8023d09c 40080033 ffffffff
 [&lt;80101a49&gt;] (__irq_svc) from [&lt;8023d09c&gt;] (do_pipe2+0x0/0xac)
 [&lt;8023d09c&gt;] (do_pipe2) from [&lt;ffffffff&gt;] (0xffffffff)
 Exception stack(0xeb491fc8 to 0xeb492010)
 1fc0:                   008dd314 0000002a 00511ad8 008de4c8 7eb14790 7eb1478c
 1fe0: 00511e34 7eb14774 004c8557 76f44098 60080030 7eb14794 00000000 00000000
 2000: 00000001 00000000 ea846c00 ea847cc0

In this example, the stack limit is 0xeb492000, but 16 bytes outside the
stack have been read.

Fix it by adding bounds checks.

Signed-off-by: Vincent Whitchurch &lt;vincent.whitchurch@axis.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace</title>
<updated>2019-07-09T04:48:15+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2019-07-09T04:48:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=5ad18b2e60b75c7297a998dea702451d33a052ed'/>
<id>5ad18b2e60b75c7297a998dea702451d33a052ed</id>
<content type='text'>
Pull force_sig() argument change from Eric Biederman:
 "A source of error over the years has been that force_sig has taken a
  task parameter when it is only safe to use force_sig with the current
  task.

  The force_sig function is built for delivering synchronous signals
  such as SIGSEGV where the userspace application caused a synchronous
  fault (such as a page fault) and the kernel responded with a signal.

  Because the name force_sig does not make this clear, and because the
  force_sig takes a task parameter the function force_sig has been
  abused for sending other kinds of signals over the years. Slowly those
  have been fixed when the oopses have been tracked down.

  This set of changes fixes the remaining abusers of force_sig and
  carefully rips out the task parameter from force_sig and friends
  making this kind of error almost impossible in the future"

* 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (27 commits)
  signal/x86: Move tsk inside of CONFIG_MEMORY_FAILURE in do_sigbus
  signal: Remove the signal number and task parameters from force_sig_info
  signal: Factor force_sig_info_to_task out of force_sig_info
  signal: Generate the siginfo in force_sig
  signal: Move the computation of force into send_signal and correct it.
  signal: Properly set TRACE_SIGNAL_LOSE_INFO in __send_signal
  signal: Remove the task parameter from force_sig_fault
  signal: Use force_sig_fault_to_task for the two calls that don't deliver to current
  signal: Explicitly call force_sig_fault on current
  signal/unicore32: Remove tsk parameter from __do_user_fault
  signal/arm: Remove tsk parameter from __do_user_fault
  signal/arm: Remove tsk parameter from ptrace_break
  signal/nds32: Remove tsk parameter from send_sigtrap
  signal/riscv: Remove tsk parameter from do_trap
  signal/sh: Remove tsk parameter from force_sig_info_fault
  signal/um: Remove task parameter from send_sigtrap
  signal/x86: Remove task parameter from send_sigtrap
  signal: Remove task parameter from force_sig_mceerr
  signal: Remove task parameter from force_sig
  signal: Remove task parameter from force_sigsegv
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull force_sig() argument change from Eric Biederman:
 "A source of error over the years has been that force_sig has taken a
  task parameter when it is only safe to use force_sig with the current
  task.

  The force_sig function is built for delivering synchronous signals
  such as SIGSEGV where the userspace application caused a synchronous
  fault (such as a page fault) and the kernel responded with a signal.

  Because the name force_sig does not make this clear, and because the
  force_sig takes a task parameter the function force_sig has been
  abused for sending other kinds of signals over the years. Slowly those
  have been fixed when the oopses have been tracked down.

  This set of changes fixes the remaining abusers of force_sig and
  carefully rips out the task parameter from force_sig and friends
  making this kind of error almost impossible in the future"

* 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (27 commits)
  signal/x86: Move tsk inside of CONFIG_MEMORY_FAILURE in do_sigbus
  signal: Remove the signal number and task parameters from force_sig_info
  signal: Factor force_sig_info_to_task out of force_sig_info
  signal: Generate the siginfo in force_sig
  signal: Move the computation of force into send_signal and correct it.
  signal: Properly set TRACE_SIGNAL_LOSE_INFO in __send_signal
  signal: Remove the task parameter from force_sig_fault
  signal: Use force_sig_fault_to_task for the two calls that don't deliver to current
  signal: Explicitly call force_sig_fault on current
  signal/unicore32: Remove tsk parameter from __do_user_fault
  signal/arm: Remove tsk parameter from __do_user_fault
  signal/arm: Remove tsk parameter from ptrace_break
  signal/nds32: Remove tsk parameter from send_sigtrap
  signal/riscv: Remove tsk parameter from do_trap
  signal/sh: Remove tsk parameter from force_sig_info_fault
  signal/um: Remove task parameter from send_sigtrap
  signal/x86: Remove task parameter from send_sigtrap
  signal: Remove task parameter from force_sig_mceerr
  signal: Remove task parameter from force_sig
  signal: Remove task parameter from force_sigsegv
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm</title>
<updated>2019-07-09T04:08:34+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2019-07-09T04:08:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2b49350b16fa3171136d7cf351ac7e9e6673b8f2'/>
<id>2b49350b16fa3171136d7cf351ac7e9e6673b8f2</id>
<content type='text'>
Pull ARM updates from Russell King:

 - Add a "cut here" to make it clearer where oops dumps should be cut
   from - we already have a marker for the end of the dumps.

 - Add logging severity to show_pte()

 - Drop unnecessary common-page-size linker flag

 - Errata workarounds for Cortex A12 857271, Cortex A17 857272 and
   Cortex A7 814220.

 - Remove some unused variables that had started to provoke a compiler
   warning.

* tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: 8863/1: stm32: select ARM errata 814220
  ARM: 8862/1: errata: 814220-B-Cache maintenance by set/way operations can execute out of order
  ARM: 8865/1: mm: remove unused variables
  ARM: 8864/1: Add workaround for I-Cache line size mismatch between CPU cores
  ARM: 8861/1: errata: Workaround errata A12 857271 / A17 857272
  ARM: 8860/1: VDSO: Drop implicit common-page-size linker flag
  ARM: arrange show_pte() to issue severity-based messages
  ARM: add "8&lt;--- cut here ---" to kernel dumps
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull ARM updates from Russell King:

 - Add a "cut here" to make it clearer where oops dumps should be cut
   from - we already have a marker for the end of the dumps.

 - Add logging severity to show_pte()

 - Drop unnecessary common-page-size linker flag

 - Errata workarounds for Cortex A12 857271, Cortex A17 857272 and
   Cortex A7 814220.

 - Remove some unused variables that had started to provoke a compiler
   warning.

* tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: 8863/1: stm32: select ARM errata 814220
  ARM: 8862/1: errata: 814220-B-Cache maintenance by set/way operations can execute out of order
  ARM: 8865/1: mm: remove unused variables
  ARM: 8864/1: Add workaround for I-Cache line size mismatch between CPU cores
  ARM: 8861/1: errata: Workaround errata A12 857271 / A17 857272
  ARM: 8860/1: VDSO: Drop implicit common-page-size linker flag
  ARM: arrange show_pte() to issue severity-based messages
  ARM: add "8&lt;--- cut here ---" to kernel dumps
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: arrange show_pte() to issue severity-based messages</title>
<updated>2019-06-20T21:29:23+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2019-01-29T15:44:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=49b38c345baa1bfdb79ff7f546755c29ea59e028'/>
<id>49b38c345baa1bfdb79ff7f546755c29ea59e028</id>
<content type='text'>
show_pte() is used to print information after various other kernel
messages, which themselves are printed at different severities.
Include the severity in the show_pte() information so that associated
messages are printed with the same severity.

Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
show_pte() is used to print information after various other kernel
messages, which themselves are printed at different severities.
Include the severity in the show_pte() information so that associated
messages are printed with the same severity.

Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: add "8&lt;--- cut here ---" to kernel dumps</title>
<updated>2019-06-20T21:29:23+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2019-01-29T14:07:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=bafeb7a0d9213e64a0e09d149b52abeb0c8798b5'/>
<id>bafeb7a0d9213e64a0e09d149b52abeb0c8798b5</id>
<content type='text'>
Add a "8&lt;--- cut here ---" marker to kernel dumps to help users cut
the dump at the right place when emailing list, rather than cutting
off the first line which gives the reason for the dump.

Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a "8&lt;--- cut here ---" marker to kernel dumps to help users cut
the dump at the right place when emailing list, rather than cutting
off the first line which gives the reason for the dump.

Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500</title>
<updated>2019-06-19T15:09:55+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2019-06-04T08:11:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=d2912cb15bdda8ba4a5dd73396ad62641af2f520'/>
<id>d2912cb15bdda8ba4a5dd73396ad62641af2f520</id>
<content type='text'>
Based on 2 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 version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

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

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Enrico Weigelt &lt;info@metux.net&gt;
Reviewed-by: Kate Stewart &lt;kstewart@linuxfoundation.org&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Based on 2 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 version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

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

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Enrico Weigelt &lt;info@metux.net&gt;
Reviewed-by: Kate Stewart &lt;kstewart@linuxfoundation.org&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>signal: Remove the task parameter from force_sig_fault</title>
<updated>2019-05-29T14:31:43+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2019-05-23T16:04:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2e1661d2673667d886cd40ad9f414cb6db48d8da'/>
<id>2e1661d2673667d886cd40ad9f414cb6db48d8da</id>
<content type='text'>
As synchronous exceptions really only make sense against the current
task (otherwise how are you synchronous) remove the task parameter
from from force_sig_fault to make it explicit that is what is going
on.

The two known exceptions that deliver a synchronous exception to a
stopped ptraced task have already been changed to
force_sig_fault_to_task.

The callers have been changed with the following emacs regular expression
(with obvious variations on the architectures that take more arguments)
to avoid typos:

force_sig_fault[(]\([^,]+\)[,]\([^,]+\)[,]\([^,]+\)[,]\W+current[)]
-&gt;
force_sig_fault(\1,\2,\3)

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As synchronous exceptions really only make sense against the current
task (otherwise how are you synchronous) remove the task parameter
from from force_sig_fault to make it explicit that is what is going
on.

The two known exceptions that deliver a synchronous exception to a
stopped ptraced task have already been changed to
force_sig_fault_to_task.

The callers have been changed with the following emacs regular expression
(with obvious variations on the architectures that take more arguments)
to avoid typos:

force_sig_fault[(]\([^,]+\)[,]\([^,]+\)[,]\([^,]+\)[,]\W+current[)]
-&gt;
force_sig_fault(\1,\2,\3)

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
