14 Nov, 2018
3 commits
-
commit 99a3ae51d557d8e38a7aece65678a31f9db215ee upstream.
In the C-code we need to put the physical address of the hpmc handler in
the interrupt vector table (IVA) in order to get HPMCs working. Since
on parisc64 function pointers are indirect (in fact they are function
descriptors) we instead export the address as variable and not as
function.This reverts a small part of commit f39cce654f9a ("parisc: Add
cfi_startproc and cfi_endproc to assembly code").Signed-off-by: Helge Deller
Cc: [4.9+]
Signed-off-by: Greg Kroah-Hartman -
commit 3c229b3f2dd8133f61bb81d3cb018be92f4bba39 upstream.
Fix a long-existing small nasty bug in the map_pages() implementation which
leads to overwriting already written pte entries with zero, *if* map_pages() is
called a second time with an end address which isn't aligned on a pmd boundry.
This happens for example if we want to remap only the text segment read/write
in order to run alternative patching on the code. Exiting the loop when we
reach the end address fixes this.Cc: stable@vger.kernel.org
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
commit 1138b6718ff74d2a934459643e3754423d23b5e2 upstream.
Helge noticed that the address of the os_hpmc handler was not being
correctly calculated in the hpmc macro. As a result, PDCE_CHECK would
fail to call os_hpmc:e800009802e00000 0000000000000000 CC_ERR_CHECK_HPMC
37000f7302e00000 8040004000000000 CC_ERR_CPU_CHECK_SUMMARY
f600105e02e00000 fffffff0f0c00000 CC_MC_HPMC_MONARCH_SELECTED
140003b202e00000 000000000000000b CC_ERR_HPMC_STATE_ENTRY
5600100b02e00000 00000000000001a0 CC_MC_OS_HPMC_LEN_ERR
5600106402e00000 fffffff0f0438e70 CC_MC_BR_TO_OS_HPMC_FAILED
e800009802e00000 0000000000000000 CC_ERR_CHECK_HPMC
37000f7302e00000 8040004000000000 CC_ERR_CPU_CHECK_SUMMARY
4000109f02e00000 0000000000000000 CC_MC_HPMC_INITIATED
4000101902e00000 0000000000000000 CC_MC_MULTIPLE_HPMCS
030010d502e00000 0000000000000000 CC_CPU_STOPThe address problem can be seen by dumping the fault vector:
0000000040159000 :
40159000: 63 6f 77 73 stb r15,-2447(dp)
40159004: 20 63 61 6e ldil L%b747000,r3
40159008: 20 66 6c 79 ldil L%-1c3b3000,r3
...
40159020: 08 00 02 40 nop
40159024: 20 6e 60 02 ldil L%15d000,r3
40159028: 34 63 00 00 ldo 0(r3),r3
4015902c: e8 60 c0 02 bv,n r0(r3)
40159030: 08 00 02 40 nop
40159034: 00 00 00 00 break 0,0
40159038: c0 00 70 00 bb,*< r0,sar,40159840
4015903c: 00 00 00 00 break 0,0Location 40159038 should contain the physical address of os_hpmc:
000000004015d000 :
4015d000: 08 1a 02 43 copy r26,r3
4015d004: 01 c0 08 a4 mfctl iva,r4
4015d008: 48 85 00 68 ldw 34(r4),r5This patch moves the address setup into initialize_ivt to resolve the
above problem. I tested the change by dumping the HPMC entry after setup:0000000040209020: 8000240
0000000040209024: 206a2004
0000000040209028: 34630ac0
000000004020902c: e860c002
0000000040209030: 8000240
0000000040209034: 1bdddce6
0000000040209038: 15d000
000000004020903c: 1a0Signed-off-by: John David Anglin
Cc:
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman
24 Aug, 2018
2 commits
-
commit 3b885ac1dc35b87a39ee176a6c7e2af9c789d8b8 upstream.
Now that mb() is an instruction barrier, it will slow performance if we issue
unnecessary barriers.The spinlock defines have a number of unnecessary barriers. The __ldcw()
define is both a hardware and compiler barrier. The mb() barriers in the
routines using __ldcw() serve no purpose.The only barrier needed is the one in arch_spin_unlock(). We need to ensure
all accesses are complete prior to releasing the lock.Signed-off-by: John David Anglin
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
commit 7797167ffde1f00446301cb22b37b7c03194cfaf upstream.
Now that we use a sync prior to releasing the locks in syscall.S, we don't need
the PA 2.0 ordered stores used to release some locks. Using an ordered store,
potentially slows the release and subsequent code.There are a number of other ordered stores and loads that serve no purpose. I
have converted these to normal stores.Signed-off-by: John David Anglin
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman
16 Aug, 2018
2 commits
-
commit fedb8da96355f5f64353625bf96dc69423ad1826 upstream.
For years I thought all parisc machines executed loads and stores in
order. However, Jeff Law recently indicated on gcc-patches that this is
not correct. There are various degrees of out-of-order execution all the
way back to the PA7xxx processor series (hit-under-miss). The PA8xxx
series has full out-of-order execution for both integer operations, and
loads and stores.This is described in the following article:
http://web.archive.org/web/20040214092531/http://www.cpus.hp.com/technical_references/advperf.shtmlFor this reason, we need to define mb() and to insert a memory barrier
before the store unlocking spinlocks. This ensures that all memory
accesses are complete prior to unlocking. The ldcw instruction performs
the same function on entry.Signed-off-by: John David Anglin
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
commit 66509a276c8c1d19ee3f661a41b418d101c57d29 upstream.
Enable the -mlong-calls compiler option by default, because otherwise in most
cases linking the vmlinux binary fails due to truncations of R_PARISC_PCREL22F
relocations. This fixes building the 64-bit defconfig.Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman
21 Jun, 2018
3 commits
-
[ Upstream commit 01f56832cfb6fcc204e7203f46841b6185ebd574 ]
No other architecture has setup_profiling_timer() in the init section,
thus on parisc we face this section mismatch warning:
Reference from the function devm_device_add_group() to the function .init.text:setup_profiling_timer()Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit b819439fea305a0bfd6ca23a7994fd1a8847c0d8 ]
Fix two section mismatches in drivers.c:
1) Section mismatch in reference from the function alloc_tree_node() to
the function .init.text:create_tree_node().
2) Section mismatch in reference from the function walk_native_bus() to
the function .init.text:alloc_pa_dev().Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit f76cdd00ef0e39d880139b074e3b247594dff95a ]
The read_persistent_clock() uses a timespec, which is not year 2038 safe
on 32bit systems. On parisc architecture, we have implemented generic
RTC drivers that can be used to compensate the system suspend time, but
the RTC time can not represent the nanosecond resolution, so this patch
just converts to read_persistent_clock64() with timespec64.Signed-off-by: Baolin Wang
Acked-by: Arnd Bergmann
Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
19 Apr, 2018
2 commits
-
commit d5654e156bc4d68a87bbaa6d7e020baceddf6e68 upstream.
Make sure that the HPMC (High Priority Machine Check) handler is 16-byte
aligned and that it's length in the IVT is a multiple of 16 bytes.
Otherwise PDC may decide not to call the HPMC crash handler.Signed-off-by: Helge Deller
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 615b2665fd20c327b631ff1e79426775de748094 upstream.
As found by the ubsan checker, the value of the 'index' variable can be
out of range for the bc[] array:UBSAN: Undefined behaviour in arch/parisc/kernel/drivers.c:655:21
index 6 is out of range for type 'char [6]'
Backtrace:
[] __ubsan_handle_out_of_bounds+0x68/0x80
[] check_parent+0xc0/0x170
[] descend_children+0x30/0x6c
[] device_for_each_child+0x60/0x98
[] parse_tree_node+0x40/0x54
[] check_parent+0xf0/0x170
[] descend_children+0x30/0x6c
[] device_for_each_child+0x60/0x98
[] descend_children+0x4c/0x6c
[] device_for_each_child+0x60/0x98
[] parse_tree_node+0x40/0x54
[] hwpath_to_device+0xa4/0xc4Signed-off-by: Helge Deller
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
21 Mar, 2018
1 commit
-
commit 9ef0f88fe5466c2ca1d2975549ba6be502c464c1 upstream.
Just when I had decided that flush_cache_range() was always called with
a valid context, Helge reported two cases where the
"BUG_ON(!vma->vm_mm->context);" was hit on the phantom buildd:kernel BUG at /mnt/sdb6/linux/linux-4.15.4/arch/parisc/kernel/cache.c:587!
CPU: 1 PID: 3254 Comm: kworker/1:2 Tainted: G D 4.15.0-1-parisc64-smp #1 Debian 4.15.4-1+b1
Workqueue: events free_ioctx
IAOQ[0]: flush_cache_range+0x164/0x168
IAOQ[1]: flush_cache_page+0x0/0x1c8
RP(r2): unmap_page_range+0xae8/0xb88
Backtrace:
[] unmap_page_range+0xae8/0xb88
[] unmap_single_vma+0xc0/0x188
[] zap_page_range_single+0x134/0x1f8
[] unmap_mapping_range+0x1cc/0x208
[] truncate_pagecache+0x98/0x108
[] truncate_setsize+0x9c/0xb8
[] put_aio_ring_file+0x80/0x100
[] aio_free_ring+0x8c/0x290
[] free_ioctx+0x80/0x180
[] process_one_work+0x21c/0x668
[] worker_thread+0x20c/0x778
[] kthread+0x2d4/0x2e0
[] end_fault_vector+0x20/0xc0This indicates that we need to handle the no context case in
flush_cache_range() as we do in flush_cache_mm().In thinking about this, I realized that we don't need to flush the TLB
when there is no context. So, I added context checks to the large flush
cases in flush_cache_mm() and flush_cache_range(). The large flush case
occurs frequently in flush_cache_mm() and the change should improve fork
performance.The v2 version of this change removes the BUG_ON from flush_cache_page()
by skipping the TLB flush when there is no context. I also added code
to flush the TLB in flush_cache_mm() and flush_cache_range() when we
have a context that's not current. Now all three routines handle TLB
flushes in a similar manner.Signed-off-by: John David Anglin
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman
09 Mar, 2018
3 commits
-
commit 0adb24e03a124b79130c9499731936b11ce2677d upstream.
The change to flush_kernel_vmap_range() wasn't sufficient to avoid the
SMP stalls. The problem is some drivers call these routines with
interrupts disabled. Interrupts need to be enabled for flush_tlb_all()
and flush_cache_all() to work. This version adds checks to ensure
interrupts are not disabled before calling routines that need IPI
interrupts. When interrupts are disabled, we now drop into slower code.The attached change fixes the ordering of cache and TLB flushes in
several cases. When we flush the cache using the existing PTE/TLB
entries, we need to flush the TLB after doing the cache flush. We don't
need to do this when we flush the entire instruction and data caches as
these flushes don't use the existing TLB entries. The same is true for
tmpalias region flushes.The flush_kernel_vmap_range() and invalidate_kernel_vmap_range()
routines have been updated.Secondly, we added a new purge_kernel_dcache_range_asm() routine to
pacache.S and use it in invalidate_kernel_vmap_range(). Nominally,
purges are faster than flushes as the cache lines don't have to be
written back to memory.Hopefully, this is sufficient to resolve the remaining problems due to
cache speculation. So far, testing indicates that this is the case. I
did work up a patch using tmpalias flushes, but there is a performance
hit because we need the physical address for each page, and we also need
to sequence access to the tmpalias flush code. This increases the
probability of stalls.Signed-off-by: John David Anglin
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
commit 636a415bcc7f4fd020ece8fd5fc648c4cef19c34 upstream.
When run under QEMU, calling mfctl(16) creates some overhead because the
qemu timer has to be scaled and moved into the register. This patch
reduces the number of calls to mfctl(16) by moving the calls out of the
loops.Additionally, increase the minimal time interval to 8000 cycles instead
of 500 to compensate possible QEMU delays when delivering interrupts.Signed-off-by: Helge Deller
Cc: stable@vger.kernel.org # 4.14+
Signed-off-by: Greg Kroah-Hartman -
commit 5ffa8518851f1401817c15d2a7eecc0373c26ff9 upstream.
When running on qemu we know that the (emulated) cr16 cpu-internal
clocks are syncronized. So let's use them unconditionally on qemu.Signed-off-by: Helge Deller
Cc: stable@vger.kernel.org # 4.14+
Signed-off-by: Greg Kroah-Hartman
03 Mar, 2018
1 commit
-
[ Upstream commit da57c5414f49ef9e4bcb9ae0bbafd1d650b31411 ]
In testing, I found that the thread stack can be 16 kB when using an irq
stack. Without it, the thread stack needs to be 32 kB. Currently, the irq
stack is 32 kB. While it probably could be 16 kB, I would prefer to leave it
as is for safety.Signed-off-by: John David Anglin
Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
10 Jan, 2018
2 commits
-
commit 310d82784fb4d60c80569f5ca9f53a7f3bf1d477 upstream.
Add qemu idle sleep support when running under qemu with SeaBIOS PDC
firmware.Like the power architecture we use the "or" assembler instructions,
which translate to nops on real hardware, to indicate that qemu shall
idle sleep.Signed-off-by: Helge Deller
Cc: Richard Henderson
Signed-off-by: Greg Kroah-Hartman -
commit 88776c0e70be0290f8357019d844aae15edaa967 upstream.
Qemu for PARISC reported on a 32bit SMP parisc kernel strange failures
about "Not-handled unaligned insn 0x0e8011d6 and 0x0c2011c9."Those opcodes evaluate to the ldcw() assembly instruction which requires
(on 32bit) an alignment of 16 bytes to ensure atomicity.As it turns out, qemu is correct and in our assembly code in entry.S and
pacache.S we don't pay attention to the required alignment.This patch fixes the problem by aligning the lock offset in assembly
code in the same manner as we do in our C-code.Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman
30 Dec, 2017
3 commits
-
commit 9352aeada4d8d8753fc0e414fbfe8fdfcb68a12c upstream.
This reverts commit 5c38602d83e584047906b41b162ababd4db4106d.
Interrupts can't be enabled early because the register saves are done on
the thread stack prior to switching to the IRQ stack. This caused stack
overflows and the thread stack needed increasing to 32k. Even then,
stack overflows still occasionally occurred.Background:
Even with a 32 kB thread stack, I have seen instances where the thread
stack overflowed on the mx3210 buildd. Detection of stack overflow only
occurs when we have an external interrupt. When an external interrupt
occurs, we switch to the thread stack if we are not already on a kernel
stack. Then, registers and specials are saved to the kernel stack.The bug occurs in intr_return where interrupts are reenabled prior to
returning from the interrupt. This was done incase we need to schedule
or deliver signals. However, it introduces the possibility that
multiple external interrupts may occur on the thread stack and cause a
stack overflow. These might not be detected and cause the kernel to
misbehave in random ways.This patch changes the code back to only reenable interrupts when we are
going to schedule or deliver signals. As a result, we generally return
from an interrupt before reenabling interrupts. This minimizes the
growth of the thread stack.Fixes: 5c38602d83e5 ("parisc: Re-enable interrupts early")
Signed-off-by: John David Anglin
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
commit 203c110b39a89b48156c7450504e454fedb7f7f6 upstream.
Static analysis tools complain that we intended to have curly braces
around this indent block. In this case this assumption is wrong, so fix
the indenting.Fixes: 2f3c7b8137ef ("parisc: Add core code for self-extracting kernel")
Reported-by: Dan Carpenter
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
commit 0ed9d3de5f8f97e6efd5ca0e3377cab5f0451ead upstream.
The os_hpmc_size variable sometimes wasn't aligned at word boundary and thus
triggered the unaligned fault handler at startup.
Fix it by aligning it properly.Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman
17 Dec, 2017
1 commit
-
commit 4d2dc2cc766c3b51929658cacbc6e34fc8e242fb upstream.
Currently, we're capping the values too low in the F_GETLK64 case. The
fields in that structure are 64-bit values, so we shouldn't need to do
any sort of fixup there.Make sure we check that assumption at build time in the future however
by ensuring that the sizes we're copying will fit.With this, we no longer need COMPAT_LOFF_T_MAX either, so remove it.
Fixes: 94073ad77fff2 (fs/locks: don't mess with the address limit in compat_fcntl64)
Reported-by: Vitaly Lipatov
Signed-off-by: Jeff Layton
Reviewed-by: David Howells
Signed-off-by: Greg Kroah-Hartman
30 Nov, 2017
1 commit
-
commit 05f016d2ca7a4fab99d5d5472168506ddf95e74f upstream.
As noted by Christoph Biedl, passing a pointer size of 4 in the new CAS
implementation causes a kernel crash. The attached patch corrects the
off by one error in the argument validity check.In reviewing the code, I noticed that we only perform word operations
with the pointer size argument. The subi instruction intentionally uses
a word condition on 64-bit kernels. Nullification was used instead of a
cmpib instruction as the branch should never be taken. The shlw
pseudo-operation generates a depw,z instruction and it clears the target
before doing a shift left word deposit. Thus, we don't need to clip the
upper 32 bits of this argument on 64-bit kernels.Tested with a gcc testsuite run with a 64-bit kernel. The gcc atomic
code in libgcc is the only direct user of the new CAS implementation
that I am aware of.Signed-off-by: John David Anglin
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman
02 Nov, 2017
3 commits
-
Many user space API headers have licensing information, which is either
incomplete, badly formatted or just a shorthand for referring to the
license under which the file is supposed to be. This makes it hard for
compliance tools to determine the correct license.Update these files with an SPDX license identifier. The identifier was
chosen based on the license information in the file.GPL/LGPL licensed headers get the matching GPL/LGPL SPDX license
identifier with the added 'WITH Linux-syscall-note' exception, which is
the officially assigned exception identifier for the kernel syscall
exception:NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".This exception makes it possible to include GPL headers into non GPL
code, without confusing license compliance tools.Headers which have either explicit dual licensing or are just licensed
under a non GPL license are updated with the corresponding SPDX
identifier and the GPLv2 with syscall exception identifier. The format
is:
((GPL-2.0 WITH Linux-syscall-note) OR SPDX-ID-OF-OTHER-LICENSE)SPDX license identifiers are a legally binding shorthand, which can be
used instead of the full boiler plate text. The update does not remove
existing license information as this has to be done on a case by case
basis and the copyright holders might have to be consulted. This will
happen in a separate step.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne. See the previous patch in this series for the
methodology of how this patch was researched.Reviewed-by: Kate Stewart
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
Many user space API headers are missing licensing information, which
makes it hard for compliance tools to determine the correct license.By default are files without license information under the default
license of the kernel, which is GPLV2. Marking them GPLV2 would exclude
them from being included in non GPLV2 code, which is obviously not
intended. The user space API headers fall under the syscall exception
which is in the kernels COPYING file:NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".otherwise syscall usage would not be possible.
Update the files which contain no license information with an SPDX
license identifier. The chosen identifier is 'GPL-2.0 WITH
Linux-syscall-note' which is the officially assigned identifier for the
Linux syscall exception. SPDX license identifiers are a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne. See the previous patch in this series for the
methodology of how this patch was researched.Reviewed-by: Kate Stewart
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
19 Oct, 2017
3 commits
-
For CPUs which have an unknown or invalid CPU location (physical location)
assume that their cycle counters aren't syncronized across CPUs.Signed-off-by: Helge Deller
Fixes: c8c3735997a3 ("parisc: Enhance detection of synchronous cr16 clocksources")
Cc: stable@vger.kernel.org # 4.13+
Signed-off-by: Helge Deller -
__cmpxchg_u64 is built and used outside CONFIG_64BIT and thus needs to
be exported. This fixes the following build error seen when building
parisc:allmodconfig.ERROR: "__cmpxchg_u64" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
Signed-off-by: Guenter Roeck
Signed-off-by: Helge Deller -
As discussed on the debian-hppa list, double-wordcompare and exchange
operations fail on 32-bit kernels. Looking at the code, I realized that
the ",ma" completer does the wrong thing in the "ldw,ma 4(%r26), %r29"
instruction. This increments %r26 and causes the following store to
write to the wrong location.Note by Helge Deller:
The patch applies cleanly to stable kernel series if this upstream
commit is merged in advance:
f4125cfdb300 ("parisc: Avoid trashing sr2 and sr3 in LWS code").Signed-off-by: John David Anglin
Tested-by: Christoph Biedl
Fixes: 89206491201c ("parisc: Implement new LWS CAS supporting 64 bit operations.")
Cc: stable@vger.kernel.org # 3.13+
Signed-off-by: Helge Deller
06 Oct, 2017
1 commit
-
Pull watchddog clean-up and fixes from Thomas Gleixner:
"The watchdog (hard/softlockup detector) code is pretty much broken in
its current state. The patch series addresses this by removing all
duct tape and refactoring it into a workable state.The reasons why I ask for inclusion that late in the cycle are:
1) The code causes lockdep splats vs. hotplug locking which get
reported over and over. Unfortunately there is no easy fix.2) The risk of breakage is minimal because it's already broken
3) As 4.14 is a long term stable kernel, I prefer to have working
watchdog code in that and the lockdep issues resolved. I wouldn't
ask you to pull if 4.14 wouldn't be a LTS kernel or if the
solution would be easy to backport.4) The series was around before the merge window opened, but then got
delayed due to the UP failure caused by the for_each_cpu()
surprise which we discussed recently.Changes vs. V1:
- Addressed your review points
- Addressed the warning in the powerpc code which was discovered late
- Changed two function names which made sense up to a certain point
in the series. Now they match what they do in the end.- Fixed a 'unused variable' warning, which got not detected by the
intel robot. I triggered it when trying all possible related config
combinations manually. Randconfig testing seems not random enough.The changes have been tested by and reviewed by Don Zickus and tested
and acked by Micheal Ellerman for powerpc"* 'core-watchdog-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (36 commits)
watchdog/core: Put softlockup_threads_initialized under ifdef guard
watchdog/core: Rename some softlockup_* functions
powerpc/watchdog: Make use of watchdog_nmi_probe()
watchdog/core, powerpc: Lock cpus across reconfiguration
watchdog/core, powerpc: Replace watchdog_nmi_reconfigure()
watchdog/hardlockup/perf: Fix spelling mistake: "permanetely" -> "permanently"
watchdog/hardlockup/perf: Cure UP damage
watchdog/hardlockup: Clean up hotplug locking mess
watchdog/hardlockup/perf: Simplify deferred event destroy
watchdog/hardlockup/perf: Use new perf CPU enable mechanism
watchdog/hardlockup/perf: Implement CPU enable replacement
watchdog/hardlockup/perf: Implement init time detection of perf
watchdog/hardlockup/perf: Implement init time perf validation
watchdog/core: Get rid of the racy update loop
watchdog/core, powerpc: Make watchdog_nmi_reconfigure() two stage
watchdog/sysctl: Clean up sysctl variable name space
watchdog/sysctl: Get rid of the #ifdeffery
watchdog/core: Clean up header mess
watchdog/core: Further simplify sysctl handling
watchdog/core: Get rid of the thread teardown/setup dance
...
23 Sep, 2017
9 commits
-
gcc-7 optimizes the byte-wise accesses of get_unaligned_le32() into
word-wise accesses if the 32-bit integer output_len is declared as
external. This panics then the bootloader since we don't have the
unaligned access fault trap handler installed during boot time.Avoid this optimization by declaring output_len as byte-aligned and thus
unbreak the bootloader code.Additionally, compile the boot code optimized for size.
Signed-off-by: Helge Deller
-
By adding the feature to build the kernel as self-extracting
executeable, the possibility to simply compress the kernel with gzip was
lost.This patch now reintroduces this possibilty again and leaves it up to
the user to decide how the kernel should be built.The palo bootloader is able to natively load both formats.
Signed-off-by: Helge Deller
-
Commit 24587380f61d ("parisc: Add MADV_HWPOISON and MADV_SOFT_OFFLINE") added
the necessary constants to handle hardware-poisoning. Those were needed to
support the page deallocation feature from firmware.But I completely missed to add the relevant fault handler code. This now
showed up when I ran the madvise07 testcase from the Linux Test Project,
which failed with a kernel BUG at arch/parisc/mm/fault.c:320.With this patch the parisc kernel now behaves like other platforms and
gives the same kernel syslog warnings when poisoning pages.Signed-off-by: Helge Deller
-
Signed-off-by: Helge Deller
-
While scanning the PDT for reported broken memory modules, warn if the
initrd was coincidentally loaded into bad memory.Signed-off-by: Helge Deller
-
According to the programming note at page 1-31 of the PA 1.1 Firmware
Architecture document, one should use the PDC_INSTR firmware function to
get the instruction that invokes a PDCE_CHECK in the HPMC handler. This
patch follows this note and sets the instruction which has been a nop up
until now.
Testing on a C3000 and C8000 showed that this firmware call isn't
implemented on those machines, so maybe it's only needed on older ones.Signed-off-by: Helge Deller
-
Signed-off-by: Helge Deller
-
Signed-off-by: Helge Deller
-
Check stack pointer if we are reaching the stack end and stop unwinding
if we do. This fixes early backtraces and avoids showing unrealistic
call stacks.Signed-off-by: Helge Deller