linux/arch, branch v3.7

Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus

2012-12-06T16:42:13Z

Pull MIPS fixes from Ralf Baechle: "These are the fixes for the N32 syscall bugs found by Al, an extraneous break that broke detection for R3000 and R3081 processors, an endless loop processing signals for kernel task (x86 received the same fix a while ago) and a fix for transparent huge page which took ages to track down because it was so hard to come up with a workable test case." * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: Fix endless loop when processing signals for kernel tasks MIPS: R3000/R3081: Fix CPU detection. MIPS: N32: Fix signalfd4 syscall entry point MIPS: N32: Fix preadv(2) and pwritev(2) entry points. MIPS: Avoid mcheck by flushing page range in huge_ptep_set_access_flags()

MIPS: Fix endless loop when processing signals for kernel tasks

2012-12-05T18:59:00Z

The problem occurs [1] when a kernel-mode task returns from a system call with a pending signal. A real-life scenario is a child of 'khelper' returning from a failed kernel_execve() in ____call_usermodehelper() [ kernel/kmod.c ]. kernel_execve() fails due to a pending SIGKILL, which is the result of "kill -9 -1" (at least, busybox's init does it upon reboot). The loop is as follows: * syscall_exit_work: - work_pending: // start_of_the_loop - work_notifysig: - do_notify_resume() - do_signal() - if (!user_mode(regs)) return; - resume_userspace // TIF_SIGPENDING is still set - work_pending // so we call work_pending => goto // start_of_the_loop More information can be found in another LKML thread: http://www.serverphorums.com/read.php?12,457826 [1] The problem was also reproduced on !CONFIG_VM86 x86, and the following fix was accepted. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=29a2e2836ff9ea65a603c89df217f4198973a74f Signed-off-by: Dmitry Adamushko Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/3571/ Signed-off-by: Ralf Baechle

MIPS: R3000/R3081: Fix CPU detection.

2012-12-05T18:58:54Z

Broken since e05ea74fc56f347f872ef9946d27c53e8bf20864 (lmo) rsp. cea7e2dfdef53fe55f359d00da562a268be06fd2 (kernel.org) [MIPS: Sort out CPU type to name translation.] These CPUs are no longer very popular to say the least ... Signed-off-by: Ralf Baechle Reported-by: Murphy McCauley

MIPS: N32: Fix signalfd4 syscall entry point

2012-12-05T18:58:48Z

This needs to use the compat entry point or it's going to fail on big endian systems. Noticed by Al Viro. Signed-off-by: Ralf Baechle

MIPS: N32: Fix preadv(2) and pwritev(2) entry points.

2012-12-04T16:59:39Z

By using the native syscall entry point the kernel was also expecting 64-bit iovec structures. This is broken since ddd9e91b71072b8ebe89311c3a44b077defa1756 [preadv/ pwritev: MIPS: Add preadv(2) and pwritev(2) syscalls.] which originally added these two syscalls. I walked through piles of code, including libc and couldn't find anything that would have worked around the issue so this change the API to what it should always have been. Noticed and patch suggested by Al Viro. Signed-off-by: Ralf Baechle

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

2012-12-04T16:42:29Z

Pull sparc fixes from David Miller: "Two small fixes for Sparc, nobody uses sparc, so these are low risk :-) 1) Piggyback is too picky about the symbol types that _start and _end have in the final kernel image, and it thus breaks with newer binutils. Future proof by getting rid of the symbol type checks. 2) exit_group() should kill register windows on sparc64 the same way we do for plain exit(). Thanks to Al Viro for spotting this." * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc: Fix piggyback with newer binutils. sparc64: exit_group should kill register windows just like plain exit.

MIPS: Avoid mcheck by flushing page range in huge_ptep_set_access_flags()

2012-12-04T15:57:54Z

Problem: 1) Huge page mapping of anonymous memory is initially invalid. Will be faulted in by copy-on-write mechanism. 2) Userspace attempts store at the end of the huge mapping. 3) TLB Refill exception handler fill TLB with a normal (4K sized) invalid page at the end of the huge mapping virtual address range. 4) Userspace restarted, and re-attempts the store at the end of the huge mapping. 5) Page from #3 is invalid, we get a fault and go to the hugepage fault handler. This tries to map a huge page and calls huge_ptep_set_access_flags() to install the mapping. 6) We just call the generic ptep_set_access_flags() to set up the page tables, but the flush there assumes a normal (4K sized) page and only tries to flush the first part of the huge page virtual address out of the TLB, since the existing entry from step #3 doesn't conflict, nothing is flushed. 7) We attempt to load the mapping into the TLB, but because it conflicts with the entry from step #3, we get a Machine Check exception. The fix: Flush the entire rage covered by the huge page in huge_ptep_set_access_flags(), and remove the optimization in local_flush_tlb_range() so that the flush actually does the correct thing. Signed-off-by: David Daney Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: Hillf Danton Patchwork: https://patchwork.linux-mips.org/patch/4661/ Signed-off-by: Ralf Baechle (cherry picked from commit dd617f258cc39d36be26afee9912624a2d23112c)

sparc: Fix piggyback with newer binutils.

2012-12-03T19:24:25Z

Newer versions of binutils mark '_end' as 'B' instead of 'A' for whatever reason. To be honest, the piggyback code doesn't actually care what kind of symbol _start and _end are, it just wants to find them and record the address. So remove the type from the match strings. Reported-by: Aaro Koskinen Signed-off-by: David S. Miller

sparc64: exit_group should kill register windows just like plain exit.

2012-12-03T19:17:57Z

Reported-by: Al Viro Signed-off-by: David S. Miller

[parisc] open(2) compat bug

2012-12-03T19:13:09Z

In commit 9d73fc2d641f ("open*(2) compat fixes (s390, arm64)") I said: > > The usual rules for open()/openat()/open_by_handle_at() are > 1) native 32bit - don't force O_LARGEFILE in flags > 2) native 64bit - force O_LARGEFILE in flags > 3) compat on 64bit host - as for native 32bit > 4) native 32bit ABI for 64bit system (mips/n32, x86/x32) - as for native 64bit > > There are only two exceptions - s390 compat has open() forcing O_LARGEFILE and > arm64 compat has open_by_handle_at() doing the same thing. The same binaries > on native host (s390/31 and arm resp.) will *not* force O_LARGEFILE, so IMO > both are emulation bugs. Three exceptions, actually - parisc open() is another case like that. Native 32bit won't force O_LARGEFILE, the same binary on parisc64 will. Signed-off-by: Al Viro Signed-off-by: Linus Torvalds