linux-stable.git/arch/sparc, branch linux-3.12.y

sparc/ptrace: Preserve previous registers for short regset write

2017-04-07T08:59:34+00:00

commit d3805c546b275c8cc7d40f759d029ae92c7175f2 upstream.

Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET
to fill all the registers, the thread's old registers are preserved.

Signed-off-by: Dave Martin 
Acked-by: David S. Miller 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby

sparc64: fix compile warning section mismatch in find_node()

2016-12-13T16:01:13+00:00

[ Upstream commit 87a349f9cc0908bc0cfac0c9ece3179f650ae95a ]

A compile warning is introduced by a commit to fix the find_node().
This patch fix the compile warning by moving find_node() into __init
section. Because find_node() is only used by memblock_nid_range() which
is only used by a __init add_node_ranges(). find_node() and
memblock_nid_range() should also be inside __init section.

Signed-off-by: Thomas Tai 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

sparc64: Fix find_node warning if numa node cannot be found

2016-12-13T16:01:13+00:00

[ Upstream commit 74a5ed5c4f692df2ff0a2313ea71e81243525519 ]

When booting up LDOM, find_node() warns that a physical address
doesn't match a NUMA node.

WARNING: CPU: 0 PID: 0 at arch/sparc/mm/init_64.c:835
find_node+0xf4/0x120 find_node: A physical address doesn't
match a NUMA node rule. Some physical memory will be
owned by node 0.Modules linked in:

CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc3 #4
Call Trace:
 [0000000000468ba0] __warn+0xc0/0xe0
 [0000000000468c74] warn_slowpath_fmt+0x34/0x60
 [00000000004592f4] find_node+0xf4/0x120
 [0000000000dd0774] add_node_ranges+0x38/0xe4
 [0000000000dd0b1c] numa_parse_mdesc+0x268/0x2e4
 [0000000000dd0e9c] bootmem_init+0xb8/0x160
 [0000000000dd174c] paging_init+0x808/0x8fc
 [0000000000dcb0d0] setup_arch+0x2c8/0x2f0
 [0000000000dc68a0] start_kernel+0x48/0x424
 [0000000000dcb374] start_early_boot+0x27c/0x28c
 [0000000000a32c08] tlb_fixup_done+0x4c/0x64
 [0000000000027f08] 0x27f08

It is because linux use an internal structure node_masks[] to
keep the best memory latency node only. However, LDOM mdesc can
contain single latency-group with multiple memory latency nodes.

If the address doesn't match the best latency node within
node_masks[], it should check for an alternative via mdesc.
The warning message should only be printed if the address
doesn't match any node_masks[] nor within mdesc. To minimize
the impact of searching mdesc every time, the last matched
mask and index is stored in a variable.

Signed-off-by: Thomas Tai 
Reviewed-by: Chris Hyser 
Reviewed-by: Liam Merwick 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

sparc32: Fix inverted invalid_frame_pointer checks on sigreturns

2016-12-13T16:01:12+00:00

[ Upstream commit 07b5ab3f71d318e52c18cc3b73c1d44c908aacfa ]

Signed-off-by: Andreas Larsson 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

sparc64: Handle extremely large kernel TLB range flushes more gracefully.

2016-11-28T21:22:46+00:00

[ Upstream commit a74ad5e660a9ee1d071665e7e8ad822784a2dc7f ]

When the vmalloc area gets fragmented, and because the firmware
mapping area sits between where modules live and the vmalloc area, we
can sometimes receive requests for enormous kernel TLB range flushes.

When this happens the cpu just spins flushing billions of pages and
this triggers the NMI watchdog and other problems.

We took care of this on the TSB side by doing a linear scan of the
table once we pass a certain threshold.

Do something similar for the TLB flush, however we are limited by
the TLB flush facilities provided by the different chip variants.

First of all we use an (mostly arbitrary) cut-off of 256K which is
about 32 pages.  This can be tuned in the future.

The huge range code path for each chip works as follows:

1) On spitfire we flush all non-locked TLB entries using diagnostic
   acceses.

2) On cheetah we use the "flush all" TLB flush.

3) On sun4v/hypervisor we do a TLB context flush on context 0, which
   unlike previous chips does not remove "permanent" or locked
   entries.

We could probably do something better on spitfire, such as limiting
the flush to kernel TLB entries or even doing range comparisons.
However that probably isn't worth it since those chips are old and
the TLB only had 64 entries.

Reported-by: James Clarke 
Tested-by: James Clarke 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

sparc64: Fix illegal relative branches in hypervisor patched TLB cross-call code.

2016-11-28T21:22:45+00:00

[ Upstream commit a236441bb69723032db94128761a469030c3fe6d ]

Just like the non-cross-call TLB flush handlers, the cross-call ones need
to avoid doing PC-relative branches outside of their code blocks.

Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

sparc64: Fix instruction count in comment for __hypervisor_flush_tlb_pending.

2016-11-28T21:22:44+00:00

[ Upstream commit 830cda3f9855ff092b0e9610346d110846fc497c ]

Noticed by James Clarke.

Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

sparc64: Fix illegal relative branches in hypervisor patched TLB code.

2016-11-28T21:22:44+00:00

[ Upstream commit b429ae4d5b565a71dfffd759dfcd4f6c093ced94 ]

When we copy code over to patch another piece of code, we can only use
PC-relative branches that target code within that piece of code.

Such PC-relative branches cannot be made to external symbols because
the patch moves the location of the code and thus modifies the
relative address of external symbols.

Use an absolute jmpl to fix this problem.

Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

sparc64: Handle extremely large kernel TSB range flushes sanely.

2016-11-28T21:22:43+00:00

[ Upstream commit 849c498766060a16aad5b0e0d03206726e7d2fa4 ]

If the number of pages we are flushing is more than twice the number
of entries in the TSB, just scan the TSB table for matches rather
than probing each and every page in the range.

Based upon a patch and report by James Clarke.

Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

sparc: Handle negative offsets in arch_jump_label_transform

2016-11-28T21:22:42+00:00

[ Upstream commit 9d9fa230206a3aea6ef451646c97122f04777983 ]

Additionally, if the offset will overflow the immediate for a ba,pt
instruction, fall back on a standard ba to get an extra 3 bits.

Signed-off-by: James Clarke 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby