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

sparc64: Make sure %pil interrupts are enabled during hypervisor yield.

2014-04-22T23:49:22+00:00

[ Upstream commit cb3042d609e30e6144024801c89be3925106752b ]

In arch_cpu_idle() we must enable %pil based interrupts before
potentially invoking the hypervisor cpu yield call.

As per the Hypervisor API documentation for cpu_yield:

	Interrupts which are blocked by some mechanism other that
	pstate.ie (for example %pil) are not guaranteed to cause
	a return from this service.

It seems that only first generation Niagara chips are hit by this
bug.  My best guess is that later chips implement this in hardware
and wake up anyways from %pil events, whereas in first generation
chips the yield is implemented completely in hypervisor code and
requires %pil to be enabled in order to wake properly from this
call.

Fixes: 87fa05aeb3a5 ("sparc: Use generic idle loop")
Reported-by: Fabio M. Di Nitto 
Reported-by: Jan Engelhardt 
Tested-by: Jan Engelhardt 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: don't treat 64-bit syscall return codes as 32-bit

2014-04-22T23:49:21+00:00

[ Upstream commit 1535bd8adbdedd60a0ee62e28fd5225d66434371 ]

When checking a system call return code for an error,
linux_sparc_syscall was sign-extending the lower 32-bit value and
comparing it to -ERESTART_RESTARTBLOCK. lseek can return valid return
codes whose lower 32-bits alone would indicate a failure (such as 4G-1).
Use the whole 64-bit value to check for errors. Only the 32-bit path
should sign extend the lower 32-bit value.

Signed-off-by: Dave Kleikamp 
Acked-by: Bob Picco 
Acked-by: Allen Pais 
Cc: David S. Miller 
Cc: sparclinux@vger.kernel.org
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc32: fix build failure for arch_jump_label_transform

2014-04-22T23:49:21+00:00

[ Upstream commit 4f6500fff5f7644a03c46728fd7ef0f62fa6940b ]

In arch/sparc/Kernel/Makefile, we see:

   obj-$(CONFIG_SPARC64)   += jump_label.o

However, the Kconfig selects HAVE_ARCH_JUMP_LABEL unconditionally
for all SPARC.  This in turn leads to the following failure when
doing allmodconfig coverage builds:

kernel/built-in.o: In function `__jump_label_update':
jump_label.c:(.text+0x8560c): undefined reference to `arch_jump_label_transform'
kernel/built-in.o: In function `arch_jump_label_transform_static':
(.text+0x85cf4): undefined reference to `arch_jump_label_transform'
make: *** [vmlinux] Error 1

Change HAVE_ARCH_JUMP_LABEL to be conditional on SPARC64 so that it
matches the Makefile.

Signed-off-by: Paul Gortmaker 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bpf: do not use reciprocal divide

2014-01-16T01:02:08+00:00

At first Jakub Zawadzki noticed that some divisions by reciprocal_divide
were not correct. (off by one in some cases)
http://www.wireshark.org/~darkjames/reciprocal-buggy.c

He could also show this with BPF:
http://www.wireshark.org/~darkjames/set-and-dump-filter-k-bug.c

The reciprocal divide in linux kernel is not generic enough,
lets remove its use in BPF, as it is not worth the pain with
current cpus.

Signed-off-by: Eric Dumazet 
Reported-by: Jakub Zawadzki 
Cc: Mircea Gherzan 
Cc: Daniel Borkmann 
Cc: Hannes Frederic Sowa 
Cc: Matt Evans 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: David S. Miller 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc

2014-01-05T06:10:45+00:00

Pull sparc bugfixes from David Miller:

 1) Missing include can lead to build failure, from Kirill Tkhai.

 2) Use dev_is_pci() where applicable, from Yijing Wang.

 3) Enable irqs after we enable preemption in cpu startup path, from
    Kirill Tkhai.

 4) Revert a __copy_{to,from}_user_inatomic change that broke
    iov_iter_copy_from_user_atomic() and thus several tests in xfstests
    and LTP.  From Dave Kleikamp.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
  Revert "sparc64: Fix __copy_{to,from}_user_inatomic defines."
  sparc64: smp_callin: Enable irqs after preemption is disabled
  sparc/PCI: Use dev_is_pci() to identify PCI devices
  sparc64: Fix build regression

Revert "sparc64: Fix __copy_{to,from}_user_inatomic defines."

2014-01-05T01:55:19+00:00

This reverts commit 145e1c0023585e0e8f6df22316308ec61c5066b2.

This commit broke the behavior of __copy_from_user_inatomic when
it is only partially successful. Instead of returning the number
of bytes not copied, it now returns 1. This translates to the
wrong value being returned by iov_iter_copy_from_user_atomic.

xfstests generic/246 and LTP writev01 both fail on btrfs and nfs
because of this.

Signed-off-by: Dave Kleikamp 
Cc: Hugh Dickins 
Cc: David S. Miller 
Cc: sparclinux@vger.kernel.org
Signed-off-by: David S. Miller

sparc64: smp_callin: Enable irqs after preemption is disabled

2014-01-05T01:55:19+00:00

Most of other architectures have below suggested order.
So lets do the same to fit generic idle loop scheme better.

Signed-off-by: Kirill Tkhai 
Signed-off-by: David S. Miller

sparc/PCI: Use dev_is_pci() to identify PCI devices

2014-01-05T01:55:19+00:00

Use dev_is_pci() instead of checking bus type directly.

Signed-off-by: Yijing Wang 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: David S. Miller

mm: fix TLB flush race between migration, and change_protection_range

2013-12-19T03:04:51+00:00

There are a few subtle races, between change_protection_range (used by
mprotect and change_prot_numa) on one side, and NUMA page migration and
compaction on the other side.

The basic race is that there is a time window between when the PTE gets
made non-present (PROT_NONE or NUMA), and the TLB is flushed.

During that time, a CPU may continue writing to the page.

This is fine most of the time, however compaction or the NUMA migration
code may come in, and migrate the page away.

When that happens, the CPU may continue writing, through the cached
translation, to what is no longer the current memory location of the
process.

This only affects x86, which has a somewhat optimistic pte_accessible.
All other architectures appear to be safe, and will either always flush,
or flush whenever there is a valid mapping, even with no permissions
(SPARC).

The basic race looks like this:

CPU A			CPU B			CPU C

						load TLB entry
make entry PTE/PMD_NUMA
			fault on entry
						read/write old page
			start migrating page
			change PTE/PMD to new page
						read/write old page [*]
flush TLB
						reload TLB from new entry
						read/write new page
						lose data

[*] the old page may belong to a new user at this point!

The obvious fix is to flush remote TLB entries, by making sure that
pte_accessible aware of the fact that PROT_NONE and PROT_NUMA memory may
still be accessible if there is a TLB flush pending for the mm.

This should fix both NUMA migration and compaction.

[mgorman@suse.de: fix build]
Signed-off-by: Rik van Riel 
Signed-off-by: Mel Gorman 
Cc: Alex Thorlton 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

sparc64: Fix build regression

2013-12-03T16:51:51+00:00

This patch fixes build error which was introduced by commit

812cb83a56a908729c453a7db3fb2c262119bc9d (Implement HAVE_CONTEXT_TRACKING).

[*]https://lkml.org/lkml/2013/11/23/103

Signed-off-by: Kirill Tkhai 
CC: David Miller 
Signed-off-by: David S. Miller