linux-stable.git/arch/parisc, branch v3.10.2

parisc: optimize mtsp(0,sr) inline assembly

2013-07-22T01:21:26+00:00

commit 92b59929825d67db575043a76651865d16873b36 upstream.

If the value which should be moved into a space register is zero, we can
optimize the inline assembly to become "mtsp %r0,%srX".

Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

parisc: Ensure volatile space register %sr1 is not clobbered

2013-07-22T01:21:26+00:00

commit e8d8fc219f9a0e63e7fb927881e6f4db8e7d34df upstream.

I still see the occasional random segv on rp3440.  Looking at one of
these (a code 15), it appeared the problem must be with the cache
handling of anonymous pages.  Reviewing this, I noticed that the space
register %sr1 might be being clobbered when we flush an anonymous page.

Register %sr1 is used for TLB purges in a couple of places.  These
purges are needed on PA8800 and PA8900 processors to ensure cache
consistency of flushed cache lines.

The solution here is simply to move the %sr1 load into the TLB lock
region needed to ensure that one purge executes at a time on SMP
systems.  This was already the case for one use.  After a few days of
operation, I haven't had a random segv on my rp3440.

Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

parisc: Fix gcc miscompilation in pa_memcpy()

2013-07-22T01:21:26+00:00

commit 5b879d78bc0818aa710f5d4d9abbfc2aca075cc3 upstream.

When running the LTP testsuite one may hit this kernel BUG() with the
write06 testcase:

kernel BUG at mm/filemap.c:2023!
CPU: 1 PID: 8614 Comm: writev01 Not tainted 3.10.0-rc7-64bit-c3000+ #6
IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000401e6e84 00000000401e6e88
 IIR: 03ffe01f    ISR: 0000000010340000  IOR: 000001fbe0380820
 CPU:        1   CR30: 00000000bef80000 CR31: ffffffffffffffff
 ORIG_R28: 00000000bdc192c0
 IAOQ[0]: iov_iter_advance+0x3c/0xc0
 IAOQ[1]: iov_iter_advance+0x40/0xc0
 RP(r2): generic_file_buffered_write+0x204/0x3f0
Backtrace:
 [<00000000401e764c>] generic_file_buffered_write+0x204/0x3f0
 [<00000000401eab24>] __generic_file_aio_write+0x244/0x448
 [<00000000401eadc0>] generic_file_aio_write+0x98/0x150
 [<000000004024f460>] do_sync_readv_writev+0xc0/0x130
 [<000000004025037c>] compat_do_readv_writev+0x12c/0x340
 [<00000000402505f8>] compat_writev+0x68/0xa0
 [<0000000040251d88>] compat_SyS_writev+0x98/0xf8

Reason for this crash is a gcc miscompilation in the fault handlers of
pa_memcpy() which return the fault address instead of the copied bytes.
Since this seems to be a generic problem with gcc-4.7.x (and below), it's
better to simplify the fault handlers in pa_memcpy to avoid this problem.

Here is a simple reproducer for the problem:

int main(int argc, char **argv)
{
	int fd, nbytes;
	struct iovec wr_iovec[] = {
		{ "TEST STRING                     ",32},
		{ (char*)0x40005000,32} }; // random memory.
	fd = open(DATA_FILE, O_RDWR | O_CREAT, 0666);
	nbytes = writev(fd, wr_iovec, 2);
	printf("return value = %d, errno %d (%s)\n",
		nbytes, errno, strerror(errno));
	return 0;
}

In addition, John David Anglin wrote:
There is no gcc PR as pa_memcpy is not legitimate C code. There is an
implicit assumption that certain variables will contain correct values
when an exception occurs and the code randomly jumps to one of the
exception blocks.  There is no guarantee of this.  If a PR was filed, it
would likely be marked as invalid.

Signed-off-by: Helge Deller 
Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

parisc: Use unshadowed index register for flush instructions in flush_dcache_page_asm and flush_icache_page_asm

2013-06-18T18:29:10+00:00

The comment at the start of pacache.S states that the base and index
registers used for fdc,fic, and pdc instructions should not use shadowed
registers. Although this is probably unnecessary for tmpalias flushes,
there is also no reason not to comply.

Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller

parisc: provide pci_mmap_page_range() for parisc

2013-06-18T18:29:08+00:00

pci_mmap_page_range() is needed for X11-server support on C8000 with ATI
FireGL card.

Signed-off-by Thomas Bogendoerfer 
Signed-off-by: Helge Deller

parisc: fix serial ports on C8000 workstation

2013-06-18T18:29:07+00:00

The C8000 workstation (64 bit kernel only) has a somewhat different
serial port configuration than other models.
Thomas Bogendoerfer sent a patch to fix this in September 2010, which
was now minimally modified by me.

Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Helge Deller

parisc: fix kernel BUG at arch/parisc/include/asm/mmzone.h:50 (part 2)

2013-06-18T18:20:21+00:00

Make sure that we really return -1 (instead of 0x00ff) as node id for
page frame numbers which are not physically available.

This finally fixes the kernel panic when running
cat /proc/kpageflags /proc/kpagecount.

Theoretically this patch now limits the number of physical memory ranges
to 127 instead of 254, but currently we have MAX_PHYSMEM_RANGES
hardcoded to 8 which is sufficient for all existing parisc machines.

Signed-off-by: Helge Deller

parisc: kernel: using strlcpy() instead of strcpy()

2013-06-01T12:29:01+00:00

'boot_args' is an input args, and 'boot_command_line' has a fix length.
So use strlcpy() instead of strcpy() to avoid memory overflow.

Signed-off-by: Chen Gang 
Acked-by: Kyle McMartin 
Signed-off-by: Helge Deller

parisc: rename "CONFIG_PA7100" to "CONFIG_PA7000"

2013-06-01T12:28:47+00:00

There's a Makefile line setting cflags for CONFIG_PA7100. But that
Kconfig macro doesn't exist. There is a Kconfig symbol PA7000, which
covers both PA7000 and PA7100 processors. So let's use the corresponding
Kconfig macro.

Signed-off-by: Paul Bolle 
Signed-off-by: Helge Deller

parisc: fix kernel BUG at arch/parisc/include/asm/mmzone.h:50

2013-06-01T12:28:35+00:00

With CONFIG_DISCONTIGMEM=y and multiple physical memory areas,
cat /proc/kpageflags triggers this kernel bug:

kernel BUG at arch/parisc/include/asm/mmzone.h:50!
CPU: 2 PID: 7848 Comm: cat Tainted: G      D W 3.10.0-rc3-64bit #44
 IAOQ[0]: kpageflags_read0x128/0x238
 IAOQ[1]: kpageflags_read0x12c/0x238
 RP(r2): proc_reg_read0xbc/0x130
Backtrace:
 [<00000000402ca2d4>] proc_reg_read0xbc/0x130
 [<0000000040235bcc>] vfs_read0xc4/0x1d0
 [<0000000040235f0c>] SyS_read0x94/0xf0
 [<0000000040105fc0>] syscall_exit0x0/0x14

kpageflags_read() walks through the whole memory, even if some memory
areas are physically not available. So, we should better not BUG on an
unavailable pfn in pfn_to_nid() but just return the expected value -1 or
0.

Signed-off-by: Helge Deller