<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/powerpc/kernel, branch linux-4.20.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.20.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.20.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-02-27T09:09:47Z</updated>
<entry>
<title>powerpc/8xx: fix setting of pagetable for Abatron BDI debug tool.</title>
<updated>2019-02-27T09:09:47Z</updated>
<author>
<name>Christophe Leroy</name>
</author>
<published>2019-01-09T20:30:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=485db4ce0094125c99f8361095201cf1ec2bd7f5'/>
<id>urn:sha1:485db4ce0094125c99f8361095201cf1ec2bd7f5</id>
<content type='text'>
[ Upstream commit fb0bdec51a4901b7dd088de0a1e365e1b9f5cd21 ]

Commit 8c8c10b90d88 ("powerpc/8xx: fix handling of early NULL pointer
dereference") moved the loading of r6 earlier in the code. As some
functions are called inbetween, r6 needs to be loaded again with the
address of swapper_pg_dir in order to set PTE pointers for
the Abatron BDI.

Fixes: 8c8c10b90d88 ("powerpc/8xx: fix handling of early NULL pointer dereference")
Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>powerpc/fadump: Do not allow hot-remove memory from fadump reserved area.</title>
<updated>2019-02-12T19:02:27Z</updated>
<author>
<name>Mahesh Salgaonkar</name>
</author>
<published>2018-08-20T08:17:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b5965289fb8941a33b9fac72d4e6d3d9733ccd1c'/>
<id>urn:sha1:b5965289fb8941a33b9fac72d4e6d3d9733ccd1c</id>
<content type='text'>
[ Upstream commit 0db6896ff6332ba694f1e61b93ae3b2640317633 ]

For fadump to work successfully there should not be any holes in reserved
memory ranges where kernel has asked firmware to move the content of old
kernel memory in event of crash. Now that fadump uses CMA for reserved
area, this memory area is now not protected from hot-remove operations
unless it is cma allocated. Hence, fadump service can fail to re-register
after the hot-remove operation, if hot-removed memory belongs to fadump
reserved region. To avoid this make sure that memory from fadump reserved
area is not hot-removable if fadump is registered.

However, if user still wants to remove that memory, he can do so by
manually stopping fadump service before hot-remove operation.

Signed-off-by: Mahesh Salgaonkar &lt;mahesh@linux.vnet.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly</title>
<updated>2019-02-12T19:02:10Z</updated>
<author>
<name>Mathieu Malaterre</name>
</author>
<published>2018-10-31T12:31:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=eaa9cde28e3b4cb8e7476f49b052092b68bfbe8b'/>
<id>urn:sha1:eaa9cde28e3b4cb8e7476f49b052092b68bfbe8b</id>
<content type='text'>
[ Upstream commit beba24ac59133cb36ecd03f9af9ccb11971ee20e ]

When both `CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y` and `CONFIG_UBSAN=y`
are set, link step typically produce numberous warnings about orphan
section:

  + powerpc-linux-gnu-ld -EB -m elf32ppc -Bstatic --orphan-handling=warn --build-id --gc-sections -X -o .tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds --who
  le-archive built-in.a --no-whole-archive --start-group lib/lib.a --end-group
  powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_data393' from `init/main.o' being placed in section `.data..Lubsan_data393'.
  powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_data394' from `init/main.o' being placed in section `.data..Lubsan_data394'.
  ...
  powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_type11' from `init/main.o' being placed in section `.data..Lubsan_type11'.
  powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_type12' from `init/main.o' being placed in section `.data..Lubsan_type12'.
  ...

This commit remove those warnings produced at W=1.

Link: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg135407.html
Suggested-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Mathieu Malaterre &lt;malat@debian.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>powerpc/tm: Limit TM code inside PPC_TRANSACTIONAL_MEM</title>
<updated>2019-01-22T20:09:54Z</updated>
<author>
<name>Breno Leitao</name>
</author>
<published>2019-01-09T13:16:45Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=83dcbd8f7dba6da30d557279353ea769e7069235'/>
<id>urn:sha1:83dcbd8f7dba6da30d557279353ea769e7069235</id>
<content type='text'>
commit 897bc3df8c5aebb54c32d831f917592e873d0559 upstream.

Commit e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint")
moved a code block around and this block uses a 'msr' variable outside of
the CONFIG_PPC_TRANSACTIONAL_MEM, however the 'msr' variable is declared
inside a CONFIG_PPC_TRANSACTIONAL_MEM block, causing a possible error when
CONFIG_PPC_TRANSACTION_MEM is not defined.

	error: 'msr' undeclared (first use in this function)

This is not causing a compilation error in the mainline kernel, because
'msr' is being used as an argument of MSR_TM_ACTIVE(), which is defined as
the following when CONFIG_PPC_TRANSACTIONAL_MEM is *not* set:

	#define MSR_TM_ACTIVE(x) 0

This patch just fixes this issue avoiding the 'msr' variable usage outside
the CONFIG_PPC_TRANSACTIONAL_MEM block, avoiding trusting in the
MSR_TM_ACTIVE() definition.

Cc: stable@vger.kernel.org
Reported-by: Christoph Biedl &lt;linux-kernel.bfrz@manchmal.in-ulm.de&gt;
Fixes: e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint")
Signed-off-by: Breno Leitao &lt;leitao@debian.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>powerpc/tm: Unset MSR[TS] if not recheckpointing</title>
<updated>2019-01-16T21:03:19Z</updated>
<author>
<name>Breno Leitao</name>
</author>
<published>2018-11-26T20:12:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=36556fcd29e40c8d62073a151429e77b2239b0ab'/>
<id>urn:sha1:36556fcd29e40c8d62073a151429e77b2239b0ab</id>
<content type='text'>
commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream.

There is a TM Bad Thing bug that can be caused when you return from a
signal context in a suspended transaction but with ucontext MSR[TS] unset.

This forces regs-&gt;msr[TS] to be set at syscall entrance (since the CPU
state is transactional). It also calls treclaim() to flush the transaction
state, which is done based on the live (mfmsr) MSR state.

Since user context MSR[TS] is not set, then restore_tm_sigcontexts() is not
called, thus, not executing recheckpoint, keeping the CPU state as not
transactional. When calling rfid, SRR1 will have MSR[TS] set, but the CPU
state is non transactional, causing the TM Bad Thing with the following
stack:

	[   33.862316] Bad kernel stack pointer 3fffd9dce3e0 at c00000000000c47c
	cpu 0x8: Vector: 700 (Program Check) at [c00000003ff7fd40]
	    pc: c00000000000c47c: fast_exception_return+0xac/0xb4
	    lr: 00003fff865f442c
	    sp: 3fffd9dce3e0
	   msr: 8000000102a03031
	  current = 0xc00000041f68b700
	  paca    = 0xc00000000fb84800   softe: 0        irq_happened: 0x01
	    pid   = 1721, comm = tm-signal-sigre
	Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)
	WARNING: exception is not recoverable, can't continue

The same problem happens on 32-bits signal handler, and the fix is very
similar, if tm_recheckpoint() is not executed, then regs-&gt;msr[TS] should be
zeroed.

This patch also fixes a sparse warning related to lack of indentation when
CONFIG_PPC_TRANSACTIONAL_MEM is set.

Fixes: 2b0a576d15e0e ("powerpc: Add new transactional memory state to the signal context")
CC: Stable &lt;stable@vger.kernel.org&gt;	# 3.10+
Signed-off-by: Breno Leitao &lt;leitao@debian.org&gt;
Tested-by: Michal Suchánek &lt;msuchanek@suse.de&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>powerpc/tm: Set MSR[TS] just prior to recheckpoint</title>
<updated>2019-01-13T08:24:07Z</updated>
<author>
<name>Breno Leitao</name>
</author>
<published>2018-11-21T19:21:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=21e5f402c6c25c1b65fa29d9927a601e661d175a'/>
<id>urn:sha1:21e5f402c6c25c1b65fa29d9927a601e661d175a</id>
<content type='text'>
commit e1c3743e1a20647c53b719dbf28b48f45d23f2cd upstream.

On a signal handler return, the user could set a context with MSR[TS] bits
set, and these bits would be copied to task regs-&gt;msr.

At restore_tm_sigcontexts(), after current task regs-&gt;msr[TS] bits are set,
several __get_user() are called and then a recheckpoint is executed.

This is a problem since a page fault (in kernel space) could happen when
calling __get_user(). If it happens, the process MSR[TS] bits were
already set, but recheckpoint was not executed, and SPRs are still invalid.

The page fault can cause the current process to be de-scheduled, with
MSR[TS] active and without tm_recheckpoint() being called.  More
importantly, without TEXASR[FS] bit set also.

Since TEXASR might not have the FS bit set, and when the process is
scheduled back, it will try to reclaim, which will be aborted because of
the CPU is not in the suspended state, and, then, recheckpoint. This
recheckpoint will restore thread-&gt;texasr into TEXASR SPR, which might be
zero, hitting a BUG_ON().

	kernel BUG at /build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
	cpu 0xb: Vector: 700 (Program Check) at [c00000041f1576d0]
	    pc: c000000000054550: restore_gprs+0xb0/0x180
	    lr: 0000000000000000
	    sp: c00000041f157950
	   msr: 8000000100021033
	  current = 0xc00000041f143000
	  paca    = 0xc00000000fb86300	 softe: 0	 irq_happened: 0x01
	    pid   = 1021, comm = kworker/11:1
	kernel BUG at /build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434!
	Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)
	enter ? for help
	[c00000041f157b30] c00000000001bc3c tm_recheckpoint.part.11+0x6c/0xa0
	[c00000041f157b70] c00000000001d184 __switch_to+0x1e4/0x4c0
	[c00000041f157bd0] c00000000082eeb8 __schedule+0x2f8/0x990
	[c00000041f157cb0] c00000000082f598 schedule+0x48/0xc0
	[c00000041f157ce0] c0000000000f0d28 worker_thread+0x148/0x610
	[c00000041f157d80] c0000000000f96b0 kthread+0x120/0x140
	[c00000041f157e30] c00000000000c0e0 ret_from_kernel_thread+0x5c/0x7c

This patch simply delays the MSR[TS] set, so, if there is any page fault in
the __get_user() section, it does not have regs-&gt;msr[TS] set, since the TM
structures are still invalid, thus avoiding doing TM operations for
in-kernel exceptions and possible process reschedule.

With this patch, the MSR[TS] will only be set just before recheckpointing
and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in
invalid state.

Other than that, if CONFIG_PREEMPT is set, there might be a preemption just
after setting MSR[TS] and before tm_recheckpoint(), thus, this block must
be atomic from a preemption perspective, thus, calling
preempt_disable/enable() on this code.

It is not possible to move tm_recheckpoint to happen earlier, because it is
required to get the checkpointed registers from userspace, with
__get_user(), thus, the only way to avoid this undesired behavior is
delaying the MSR[TS] set.

The 32-bits signal handler seems to be safe this current issue, but, it
might be exposed to the preemption issue, thus, disabling preemption in
this chunk of code.

Changes from v2:
 * Run the critical section with preempt_disable.

Fixes: 87b4e5393af7 ("powerpc/tm: Fix return of active 64bit signals")
Cc: stable@vger.kernel.org (v3.9+)
Signed-off-by: Breno Leitao &lt;leitao@debian.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Revert "powerpc/tm: Unset MSR[TS] if not recheckpointing"</title>
<updated>2019-01-13T08:24:07Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
</author>
<published>2019-01-11T07:05:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cecc892029273c6cc800d7ac40902673bc671e17'/>
<id>urn:sha1:cecc892029273c6cc800d7ac40902673bc671e17</id>
<content type='text'>
This reverts commit d412deb85a4aada382352a8202beb7af8921cd53 which is
commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream.

It breaks the powerpc build, so drop it from the tree until a fix goes
upstream.

Reported-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Cc: Breno Leitao &lt;leitao@debian.org&gt;
Cc: Michal Suchánek &lt;msuchanek@suse.de&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Christoph Biedl &lt;linux-kernel.bfrz@manchmal.in-ulm.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>powerpc/tm: Unset MSR[TS] if not recheckpointing</title>
<updated>2019-01-09T16:46:00Z</updated>
<author>
<name>Breno Leitao</name>
</author>
<published>2018-11-26T20:12:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d412deb85a4aada382352a8202beb7af8921cd53'/>
<id>urn:sha1:d412deb85a4aada382352a8202beb7af8921cd53</id>
<content type='text'>
commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream.

There is a TM Bad Thing bug that can be caused when you return from a
signal context in a suspended transaction but with ucontext MSR[TS] unset.

This forces regs-&gt;msr[TS] to be set at syscall entrance (since the CPU
state is transactional). It also calls treclaim() to flush the transaction
state, which is done based on the live (mfmsr) MSR state.

Since user context MSR[TS] is not set, then restore_tm_sigcontexts() is not
called, thus, not executing recheckpoint, keeping the CPU state as not
transactional. When calling rfid, SRR1 will have MSR[TS] set, but the CPU
state is non transactional, causing the TM Bad Thing with the following
stack:

	[   33.862316] Bad kernel stack pointer 3fffd9dce3e0 at c00000000000c47c
	cpu 0x8: Vector: 700 (Program Check) at [c00000003ff7fd40]
	    pc: c00000000000c47c: fast_exception_return+0xac/0xb4
	    lr: 00003fff865f442c
	    sp: 3fffd9dce3e0
	   msr: 8000000102a03031
	  current = 0xc00000041f68b700
	  paca    = 0xc00000000fb84800   softe: 0        irq_happened: 0x01
	    pid   = 1721, comm = tm-signal-sigre
	Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)
	WARNING: exception is not recoverable, can't continue

The same problem happens on 32-bits signal handler, and the fix is very
similar, if tm_recheckpoint() is not executed, then regs-&gt;msr[TS] should be
zeroed.

This patch also fixes a sparse warning related to lack of indentation when
CONFIG_PPC_TRANSACTIONAL_MEM is set.

Fixes: 2b0a576d15e0e ("powerpc: Add new transactional memory state to the signal context")
CC: Stable &lt;stable@vger.kernel.org&gt;	# 3.10+
Signed-off-by: Breno Leitao &lt;leitao@debian.org&gt;
Tested-by: Michal Suchánek &lt;msuchanek@suse.de&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>powerpc/fsl: Fix spectre_v2 mitigations reporting</title>
<updated>2019-01-09T16:45:51Z</updated>
<author>
<name>Diana Craciun</name>
</author>
<published>2018-12-12T14:03:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7708c700cca564534b2eb03c86d44d0d01052216'/>
<id>urn:sha1:7708c700cca564534b2eb03c86d44d0d01052216</id>
<content type='text'>
commit 7d8bad99ba5a22892f0cad6881289fdc3875a930 upstream.

Currently for CONFIG_PPC_FSL_BOOK3E the spectre_v2 file is incorrect:

  $ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
  "Mitigation: Software count cache flush"

Which is wrong. Fix it to report vulnerable for now.

Fixes: ee13cb249fab ("powerpc/64s: Add support for software count cache flush")
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Diana Craciun &lt;diana.craciun@nxp.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge tag 'powerpc-4.20-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux</title>
<updated>2018-12-14T17:33:34Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2018-12-14T17:33:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4645453cefcebdff9db26f02cf325607357295c4'/>
<id>urn:sha1:4645453cefcebdff9db26f02cf325607357295c4</id>
<content type='text'>
Pull powerpc fixes from Michael Ellerman:
 "One notable fix for our change to split pt_regs between user/kernel,
  we forgot to update BPF to use the user-visible type which was an ABI
  break for BPF programs.

  A slightly ugly but minimal fix to do_syscall_trace_enter() so that we
  use tracehook_report_syscall_entry() properly. We'll rework the code
  in next to avoid the empty if body.

  Seven commits fixing bugs in the new papr_scm (Storage Class Memory)
  driver. The driver was finally able to be tested on the other
  hypervisor which exposed several bugs. The fixes are all fairly
  minimal at least.

  Fix a crash in our MSI code if an MSI-capable device is plugged into a
  non-MSI capable PHB, only seen on older hardware (MPC8378).

  Fix our legacy serial code to look for "stdout-path" since the device
  trees were updated to use that instead of "linux,stdout-path".

  A change to the COFF zImage code to fix booting old powermacs.

  A couple of minor build fixes.

  Thanks to: Benjamin Herrenschmidt, Daniel Axtens, Dmitry V. Levin,
  Elvira Khabirova, Oliver O'Halloran, Paul Mackerras, Radu Rendec, Rob
  Herring, Sandipan Das"

* tag 'powerpc-4.20-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/ptrace: replace ptrace_report_syscall() with a tracehook call
  powerpc/mm: Fallback to RAM if the altmap is unusable
  powerpc/papr_scm: Use ibm,unit-guid as the iset cookie
  powerpc/papr_scm: Fix DIMM device registration race
  powerpc/papr_scm: Remove endian conversions
  powerpc/papr_scm: Update DT properties
  powerpc/papr_scm: Fix resource end address
  powerpc/papr_scm: Use depend instead of select
  powerpc/bpf: Fix broken uapi for BPF_PROG_TYPE_PERF_EVENT
  powerpc/boot: Fix build failures with -j 1
  powerpc: Look for "stdout-path" when setting up legacy consoles
  powerpc/msi: Fix NULL pointer access in teardown code
  powerpc/mm: Fix linux page tables build with some configs
  powerpc: Fix COFF zImage booting on old powermacs
</content>
</entry>
</feed>
