linux-stable.git/arch, branch v3.18.28

powerpc/powernv: Shorten EEH function names

2016-03-04T15:18:41+00:00

[ Upstream commit 01f3bfb7804ae20aaf66884cf537f7dc2cdc1671 ]

The patch shortens names of EEH functions in powernv-eeh.c and no
logic change introduced by this patch.

Signed-off-by: Gavin Shan 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Sasha Levin

ARM: 8519/1: ICST: try other dividends than 1

2016-03-04T15:18:40+00:00

[ Upstream commit e972c37459c813190461dabfeaac228e00aae259 ]

Since the dawn of time the ICST code has only supported divide
by one or hang in an eternal loop. Luckily we were always dividing
by one because the reference frequency for the systems using
the ICSTs is 24MHz and the [min,max] values for the PLL input
if [10,320] MHz for ICST307 and [6,200] for ICST525, so the loop
will always terminate immediately without assigning any divisor
for the reference frequency.

But for the code to make sense, let's insert the missing i++

Reported-by: David Binderman 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Walleij 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

ARM: 8517/1: ICST: avoid arithmetic overflow in icst_hz()

2016-03-04T15:18:38+00:00

[ Upstream commit 5070fb14a0154f075c8b418e5bc58a620ae85a45 ]

When trying to set the ICST 307 clock to 25174000 Hz I ran into
this arithmetic error: the icst_hz_to_vco() correctly figure out
DIVIDE=2, RDW=100 and VDW=99 yielding a frequency of
25174000 Hz out of the VCO. (I replicated the icst_hz() function
in a spreadsheet to verify this.)

However, when I called icst_hz() on these VCO settings it would
instead return 4122709 Hz. This causes an error in the common
clock driver for ICST as the common clock framework will call
.round_rate() on the clock which will utilize icst_hz_to_vco()
followed by icst_hz() suggesting the erroneous frequency, and
then the clock gets set to this.

The error did not manifest in the old clock framework since
this high frequency was only used by the CLCD, which calls
clk_set_rate() without first calling clk_round_rate() and since
the old clock framework would not call clk_round_rate() before
setting the frequency, the correct values propagated into
the VCO.

After some experimenting I figured out that it was due to a simple
arithmetic overflow: the divisor for 24Mhz reference frequency
as reference becomes 24000000*2*(99+8)=0x132212400 and the "1"
in bit 32 overflows and is lost.

But introducing an explicit 64-by-32 bit do_div() and casting
the divisor into (u64) we get the right frequency back, and the
right frequency gets set.

Tested on the ARM Versatile.

Cc: stable@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: Pawel Moll 
Signed-off-by: Linus Walleij 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin

MIPS: Fix buffer overflow in syscall_get_arguments()

2016-03-02T20:18:54+00:00

[ Upstream commit f4dce1ffd2e30fa31756876ef502ce6d2324be35 ]

Since commit 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls
(o32)"), syscall_get_arguments() attempts to handle o32 indirect syscall
arguments by incrementing both the start argument number and the number
of arguments to fetch. However only the start argument number needs to
be incremented. The number of arguments does not change, they're just
shifted up by one, and in fact the output array is provided by the
caller and is likely only n entries long, so reading more arguments
overflows the output buffer.

In the case of seccomp, this results in it fetching 7 arguments starting
at the 2nd one, which overflows the unsigned long args[6] in
populate_seccomp_data(). This clobbers the $s0 register from
syscall_trace_enter() which __seccomp_phase1_filter() saved onto the
stack, into which syscall_trace_enter() had placed its syscall number
argument. This caused Chromium to crash.

Credit goes to Milko for tracking it down as far as $s0 being clobbered.

Fixes: 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls (o32)")
Reported-by: Milko Leporis 
Signed-off-by: James Hogan 
Cc: linux-mips@linux-mips.org
Cc:  # 3.15-
Patchwork: https://patchwork.linux-mips.org/patch/12213/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin

net: filter: make JITs zero A for SKF_AD_ALU_XOR_X

2016-02-15T20:42:43+00:00

[ Upstream commit 55795ef5469290f89f04e12e662ded604909e462 ]

The SKF_AD_ALU_XOR_X ancillary is not like the other ancillary data
instructions since it XORs A with X while all the others replace A with
some loaded value.  All the BPF JITs fail to clear A if this is used as
the first instruction in a filter.  This was found using american fuzzy
lop.

Add a helper to determine if A needs to be cleared given the first
instruction in a filter, and use this in the JITs.  Except for ARM, the
rest have only been compile-tested.

Fixes: 3480593131e0 ("net: filter: get rid of BPF_S_* enum")
Signed-off-by: Rabin Vincent 
Acked-by: Daniel Borkmann 
Acked-by: Alexei Starovoitov 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

ARM: nomadik: set up MCDATDIR2

2016-02-15T20:42:40+00:00

[ Upstream commit 43c4034963d6e838d971cbe59bfe84ae6e8370e6 ]

This extra data line for high-speed MMC transfers was unrouted,
set it up properly in the dtsi file.

Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

ARM: dts: at91: sama5d4: fix instance id of DBGU

2016-02-15T20:42:35+00:00

[ Upstream commit 929e883f2bfdf68d4bd3aec43912e956417005c7 ]

Change instance id of DBGU to 45.

Signed-off-by: Mohamed Jamsheeth Hajanajubudeen 
Fixes: 7c661394c56c ("ARM: at91: dt: add device tree file for SAMA5D4 SoC")
Cc: stable@vger.kernel.org   # 3.18+
Signed-off-by: Nicolas Ferre 
Signed-off-by: Sasha Levin

arm64: restore bogomips information in /proc/cpuinfo

2016-02-15T20:42:34+00:00

[ Upstream commit 92e788b749862ebe9920360513a718e5dd4da7a9 ]

As previously reported, some userspace applications depend on bogomips
showed by /proc/cpuinfo. Although there is much less legacy impact on
aarch64 than arm, it does break libvirt.

This patch reverts commit 326b16db9f69 ("arm64: delay: don't bother
reporting bogomips in /proc/cpuinfo"), but with some tweak due to
context change and without the pr_info().

Fixes: 326b16db9f69 ("arm64: delay: don't bother reporting bogomips in /proc/cpuinfo")
Signed-off-by: Yang Shi 
Acked-by: Will Deacon 
Cc:  # 3.12+
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

x86/mm/pat: Avoid truncation when converting cpa->numpages to address

2016-02-15T20:42:34+00:00

[ Upstream commit 742563777e8da62197d6cb4b99f4027f59454735 ]

There are a couple of nasty truncation bugs lurking in the pageattr
code that can be triggered when mapping EFI regions, e.g. when we pass
a cpa->pgd pointer. Because cpa->numpages is a 32-bit value, shifting
left by PAGE_SHIFT will truncate the resultant address to 32-bits.

Viorel-Cătălin managed to trigger this bug on his Dell machine that
provides a ~5GB EFI region which requires 1236992 pages to be mapped.
When calling populate_pud() the end of the region gets calculated
incorrectly in the following buggy expression,

  end = start + (cpa->numpages << PAGE_SHIFT);

And only 188416 pages are mapped. Next, populate_pud() gets invoked
for a second time because of the loop in __change_page_attr_set_clr(),
only this time no pages get mapped because shifting the remaining
number of pages (1048576) by PAGE_SHIFT is zero. At which point the
loop in __change_page_attr_set_clr() spins forever because we fail to
map progress.

Hitting this bug depends very much on the virtual address we pick to
map the large region at and how many pages we map on the initial run
through the loop. This explains why this issue was only recently hit
with the introduction of commit

  a5caa209ba9c ("x86/efi: Fix boot crash by mapping EFI memmap
   entries bottom-up at runtime, instead of top-down")

It's interesting to note that safe uses of cpa->numpages do exist in
the pageattr code. If instead of shifting ->numpages we multiply by
PAGE_SIZE, no truncation occurs because PAGE_SIZE is a UL value, and
so the result is unsigned long.

To avoid surprises when users try to convert very large cpa->numpages
values to addresses, change the data type from 'int' to 'unsigned
long', thereby making it suitable for shifting by PAGE_SHIFT without
any type casting.

The alternative would be to make liberal use of casting, but that is
far more likely to cause problems in the future when someone adds more
code and fails to cast properly; this bug was difficult enough to
track down in the first place.

Reported-and-tested-by: Viorel-Cătălin Răpițeanu 
Acked-by: Borislav Petkov 
Cc: Sai Praneeth Prakhya 
Cc: 
Signed-off-by: Matt Fleming 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=110131
Link: http://lkml.kernel.org/r/1454067370-10374-1-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin

powerpc/eeh: Fix PE location code

2016-02-15T20:42:32+00:00

[ Upstream commit 7e56f627768da4e6480986b5145dc3422bc448a5 ]

In eeh_pe_loc_get(), the PE location code is retrieved from the
"ibm,loc-code" property of the device node for the bridge of the
PE's primary bus. It's not correct because the property indicates
the parent PE's location code.

This reads the correct PE location code from "ibm,io-base-loc-code"
or "ibm,slot-location-code" property of PE parent bus's device node.

Cc: stable@vger.kernel.org # v3.16+
Fixes: 357b2f3dd9b7 ("powerpc/eeh: Dump PE location code")
Signed-off-by: Gavin Shan 
Tested-by: Russell Currey 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin