Process personality is stored together with other flags like UNAME26 in
an integer variable.  Overwriting this value with PER_LINUX drops all
other existing flags and as such broke tools like the uname26 tool.

Actually this was only broken on 32bit kernels, since for 32bit-ELF
binaries on 64-bit kernels the SET_PERSONALITY macro from
arch/parisc/kernel/binfmt_elf32.c is used which does not modifies the
personality value at all (which is wrong as long as we don't run HPUX
binaries or similiar).
Signed-off-by: NHelge Deller <deller@gmx.de>

Signed-off-by: NHelge Deller <deller@gmx.de>

LED activity is calculated out of the vm event counters wich are delivered
through the all_vm_events() function which requires CONFIG_VM_EVENT_COUNTERS.
Signed-off-by: NHelge Deller <deller@gmx.de>

Nothing uses compat_rt_sigframe.h anymore. Commit
f671c45d ("[PARISC] Arch-specific compat
signals") removed all includes of that header. It also basically copied
that entire header verbatim into signal32.h. It seems it was just
forgotten to also remove compat_rt_sigframe.h from the tree. Remove that
header now.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NHelge Deller <deller@gmx.de>

Commit d065bd81
(mm: retry page fault when blocking on disk transfer) and
commit 37b23e05
(x86,mm: make pagefault killable)

The above commits introduced changes into the x86 pagefault handler
for making the page fault handler retryable as well as killable.

These changes reduce the mmap_sem hold time, which is crucial
during OOM killer invocation.

Port these changes to parisc.
Signed-off-by: NKautuk Consul <consul.kautuk@gmail.com>
Signed-off-by: NHelge Deller <deller@gmx.de>

Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Signed-off-by: NHelge Deller <deller@gmx.de>

1) PTRACE_SYSCALL doesn't work for 64bit process on parisc64.
Compat syscall table is used instead of 64bit one.  IMO we should either
refuse to allow PTRACE_SYSCALL for 64bit processes or duplicate the
logics choosing the right syscall table into .Ltracesys.

	2) if you have let the tracee run with PTRACE_SYSCALL and
it had stopped, you can use PTRACE_POKEUSR to modify syscall number
(r20) and arguments 1--4 (r26--r23).  Modifications will have effect.
However, modifying arguments 5 and 6 (r22 and r21 resp.) works only
when process (32bit one) runs on 64bit host - on 32bit one it has no
effect.  AFAICS, the diff below should fix that one.
Signed-off-by: NAl Viro <viro@ZenIV.linux.org.uk>
Tested-by: NJohn David Anglin <dave.anglin@bell.net>
Signed-off-by: NHelge Deller <deller@gmx.de>

This patch unbreaks the current logic in that way, that even if
CONFIG_DISCONTIGMEM isn't set, the user may be informed, that he should turn on
CONFIG_DISCONTIGMEM for his machine.
Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Signed-off-by: NHelge Deller <deller@gmx.de>

Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Signed-off-by: NHelge Deller <deller@gmx.de>

It is necessary to disable preemption during cache flushes done through the
TMPALIAS region to ensure that the TLB setup is not clobbered by another flush.
Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Signed-off-by: NHelge Deller <deller@gmx.de>

People are playing odd games with IRQF_DISABLED, remove it.

Its not reliable, since shared interrupt lines could disable it for you,
and its possible and allowed for archs to disable IRQs to limit IRQ nesting.

Therefore, simply mandate that _ALL_ IRQ handlers are run with IRQs disabled.

[ This _should_ not break anything, since we've mandated that IRQ handlers
  _must_ be able to deal with this for a _long_ time ]

IRQ handlers should be fast, no if buts and any other exceptions. We also have
plenty instrumentation to find any offending IRQ latency sources.
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NHelge Deller <deller@gmx.de>

CONFIG_PARISC_TMPALIAS enables clear_user_highpage and copy_user_highpage.
These are essentially alternative implementations of clear_user_page and
copy_user_page.  They don't have anything to do with x86 high pages, but they
build on the infrastructure to save a few instructions.  Read the comment in
clear_user_highpage as it is very important to the implementation.  For this
reason, there isn't any gain in using the TMPALIAS/highpage approach.
Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Signed-off-by: NHelge Deller <deller@gmx.de>

flush_cache_mm, for the non current case also uses flush_dcache_page_asm
and flush_icache_page_asm which are TMPALIAS flushes.

For the non current case, the algorithm used by get_ptep is derived from the
vmalloc_to_page implementation in vmalloc.c.  It is essentially a generic page
table lookup.  The other alternative was to duplicate the lookup in entry.S.
The break point for switching to a full cache flush is somewhat arbitrary.  The
same approach is used in flush_cache_range for non current case.  In a GCC
build and check, many small programs are executed and this change provided a
significant performance enhancement, e.g. GCC build time was cut almost in half
on a rp3440 at j4.  Previously, we always flushed the entire cache.
Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Signed-off-by: NHelge Deller <deller@gmx.de>

Implement clear_page_asm and copy_page_asm. These are optimized routines to
clear and copy a page.  I tested prefetch optimizations in clear_page_asm and
copy_page_asm but didn't see any significant performance improvement on rp3440.
I'm not sure if these are routines are significantly faster than memset and/or
memcpy, but they are there for further performance evaluation.

TLB purge operations on PA 1.X SMP machines are now serialized with the help of
the new tlb_lock() and tlb_unlock() macros, since on some PA-RISC machines, TLB
purges need to be serialized in software.  Obviously, lock isn't needed in UP
kernels.  On PA 2.0 machines, there is a local TLB instruction which is much
less disruptive to the memory subsystem.  No lock is needed for local purge.

Loops are also unrolled in flush_instruction_cache_local and
flush_data_cache_local.

The implementation of what used to be copy_user_page (now copy_user_page_asm)
is now fixed. Additionally 64-bit support is now added. Read the preceding
comment which I didn't change.  I left the comment but it is now inaccurate.
Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Signed-off-by: NHelge Deller <deller@gmx.de>

This is the first patch in a series of 4, with which the page cache flushing of
parisc will gets fixed and enhanced. This even fixes the nasty "minifail" bug
(http://wiki.parisc-linux.org/TestCases?highlight=%28minifail%29) which
prevented parisc to stay an official debian port.  Basically the flush in
copy_user_page together with the TLB patch from commit
7139bc15 is what fixes the minifail bug.

This patch still uses the TMPALIAS approach.  The new copy_user_page
implementation calls flush_dcache_page_asm to flush the user dcache page
(crucial for minifail fix) via a kernel TMPALIAS mapping.  After that, it just
copies the page using the kernel mapping.  It does a final flush if needed.
Generally it is hard to avoid doing some cache flushes using the kernel mapping
(e.g., copy_to_user_page and copy_from_user_page).

This patch depends on a subsequent change to pacache.S implementing
clear_page_asm and copy_page_asm.  These are optimized routines to clear and
copy a page.  The calls in clear_user_page and copy_user_page could be replaced
by calls to memset and memcpy, respectively.  I tested prefetch optimizations
in clear_page_asm and copy_page_asm but didn't see any significant performance
improvement on rp3440.  I'm not sure if these are routines are significantly
faster than memset and/or memcpy, but they are there for further performance
evaluation.
Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Signed-off-by: NHelge Deller <deller@gmx.de>

Use WARN rather than printk followed by WARN_ON(1), for conciseness.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NHelge Deller <deller@gmx.de>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NHelge Deller <deller@gmx.de>

pa_pdc_cell has been allocated in this function and so should be
freed before leaving from the error handling cases.

spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NHelge Deller <deller@gmx.de>

When building a 64bit kernel which includes all necessary drivers and
filesystems the vmlinux kernel often gets so huge, that the linker won't
be able to resolve the branch stubs. This patch overcomes this limit by
providing an option to compile the kernel with the -mlong-calls compiler
option.
Signed-off-by: NHelge Deller <deller@gmx.de>

This comment describes incredibly subtle code, so it should be right!
Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Signed-off-by: NHelge Deller <deller@gmx.de>

The current Makefile will only choose the hppa64 cross compiler when
running natively on hppa in a 32bit userspace.
This patch additionally chooses the correct 32/64 bit hppa compiler even
when doing real cross compiling to hppa/hppa64 from another architecture.
Signed-off-by: NHelge Deller <deller@gmx.de>

Merge tag 'parisc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6 into stable-3.8

PARISC fixes on 20130213

This is a couple of patches, one to fix a broken build with HPUX compatibility
and the other to solve a coherency problem we've been seeing in our TLB where
setting a page read only occasionally fails to trigger a COW because of a
stale writeable TLB entry.
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Pull input subsystem fixes from Dmitry Torokhov:
 "Two small driver fixups and a documentation update for managed input
  devices"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: wacom - fix wacom_set_report retry logic
  Input: document that unregistering managed devices is not necessary
  Input: lm8323 - fix checking PWM interrupt status

Commit c060f943 ("mm: use aligned zone start for pfn_to_bitidx
calculation") fixed out calculation of the index into the pageblock
bitmap when a !SPARSEMEM zome was not aligned to pageblock_nr_pages.

However, the _allocation_ of that bitmap had never taken this alignment
requirement into accout, so depending on the exact size and alignment of
the zone, the use of that index could then access past the allocation,
resulting in some very subtle memory corruption.

This was reported (and bisected) by Ingo Molnar: one of his random
config builds would hang with certain very specific kernel command line
options.

In the meantime, commit c060f943 has been marked for stable, so this
fix needs to be back-ported to the stable kernels that backported the
commit to use the right alignment.
Bisected-and-tested-by: NIngo Molnar <mingo@kernel.org>
Acked-by: NMel Gorman <mgorman@suse.de>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Merge tag 'stable/for-linus-3.8-rc7-tag-two' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

Pull xen fixes from Konrad Rzeszutek Wilk:
 "Two fixes:

   - A simple bug-fix for redundant NULL check.

   - CVE-2013-0228/XSA-42: x86/xen: don't assume %ds is usable in
     xen_iret for 32-bit PVOPS

  and two reverts:

   - Revert the PVonHVM kexec.  The patch introduces a regression with
     older hypervisor stacks, such as Xen 4.1."

* tag 'stable/for-linus-3.8-rc7-tag-two' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  Revert "xen PVonHVM: use E820_Reserved area for shared_info"
  Revert "xen/PVonHVM: fix compile warning in init_hvm_pv_info"
  xen: remove redundant NULL check before unregister_and_remove_pcpu().
  x86/xen: don't assume %ds is usable in xen_iret for 32-bit PVOPS.

As reported by Klaus Schmidinger:
 "In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a
  device (using stb0899).  After this call I check 'errno' for
  EOPNOTSUPP to determine whether this device supports this call.  This
  used to work just fine, until a few months ago I noticed that my
  devices using stb0899 didn't display their signal quality in VDR's OSD
  any more.  After further investigation I found that
  ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but
  rather ENOTTY.  And since I stop getting the signal quality in case
  any unknown errno value appears, this broke my signal quality query
  function."

While the changes reflect what is there at:

  http://comments.gmane.org/gmane.linux.kernel/1235728

it does cause regression on userspace.  So, revert it to stop the
damage.

This reverts commit 177ffe50 ("[media] dvb_frontend: return -ENOTTY
for unimplement IOCTL").
Reported-by: NKlaus Schmidinger <Klaus.Schmidinger@tvdr.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull sparc fixes from David Miller:
 "A couple small fixes for sparc including some THP brown-paper-bag
  material:

   1) During the merging of all the THP support for various
      architectures, sparc missed adding a
      HAVE_ARCH_TRANSPARENT_HUGEPAGE to it's Kconfig, oops.

   2) Sparc needs to be mindful of hugepages in get_user_pages_fast().

   3) Fix memory leak in SBUS probe, from Cong Ding.

   4) The sunvdc virtual disk client driver has a test of the bitmask of
      vdisk server supported operations which was off by one bit"

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
  sunvdc: Fix off-by-one in generic_request().
  sparc64: Fix get_user_pages_fast() wrt. THP.
  sparc64: Add missing HAVE_ARCH_TRANSPARENT_HUGEPAGE.
  sparc: kernel/sbus.c: fix memory leakage

Pull one more x86 fix from Peter Anvin:
 "Sigh.  One more patch in the "please don't brick my Samsung" series"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  efi: Clear EFI_RUNTIME_SERVICES rather than EFI_BOOT by "noefi" boot parameter

Pull PCI fix from Bjorn Helgaas:
 "This is another fix for v3.8.  It fixes an oops that happens when a
  Thunderbolt adapter is unplugged (remove device, poll for PME events
  on no-longer-existing device, oops)."

* tag '3.8-pci-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI/PM: Clean up PME state when removing a device

Pull omapdss fixes from Tomi Valkeinen:
 "It'd be great if these two late fixes would still make it into 3.8.
  The other one fixes ARM kernel compilation when using 'allyesconfig',
  and the other makes DPI displays function again on OMAP3630 boards:

   - Fix ARM compilation with "allyesconfig" (omapdrm: fix the
     dependency to omapdss)

   - fix DPI displays on OMAP3630 (OMAPDSS: add FEAT_DPI_USES_VDDS_DSI
     to omap3630_dss_feat_list)"

* tag 'omapdss-for-3.8-rc8' of git://gitorious.org/linux-omap-dss2/linux:
  omapdrm: fix the dependency to omapdss
  OMAPDSS: add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list

Pull i2c maintainer info update from Wolfram Sang:
 "Since my old email and repos are not working anymore, and this already
  caused some confusion, I think a MAINTAINERS update for 3.8 is
  helpful.  So, people trying I2C with the new kernel can properly reach
  me and find my repos."

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  MAINTAINERS: change my email and repos

This reverts commit 9d02b43d.

We are doing this b/c on 32-bit PVonHVM with older hypervisors
(Xen 4.1) it ends up bothing up the start_info. This is bad b/c
we use it for the time keeping, and the timekeeping code loops
forever - as the version field never changes. Olaf says to
revert it, so lets do that.
Acked-by: NOlaf Hering <olaf@aepfle.de>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This reverts commit a7be94ac.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The 'operations' bitmap corresponds one-for-one with the operation
codes, no adjustment is necessary.
Reported-by: NMark Kettenis <mark.kettenis@xs4all.nl>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

omapdrm uses "select" in Kconfig to enable omapdss. This doesn't work
correctly, as "select" forces omapdss to be enabled in the config even
if it normally could not be enabled because of missing Kconfig
dependencies.

This causes a build break on ARM, when using allyesconfig:

drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in

Instead of using select, this patch changes omapdrm to use "depend
on".
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

commit 195e672a
   OMAPDSS: DPI: Remove cpu_is_xxxx checks

made the mistake of assuming that cpu_is_omap34xx() is exclusive of
other cpu_is_* predicates whereas it includes cpu_is_omap3630().

So on an omap3630, code that was previously enabled by
  if (cpu_is_omap34xx())
is now disabled as
  dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
fails.

So add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list.

Cc: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

There was a serious problem in samsung-laptop that its platform driver is
designed to run under BIOS and running under EFI can cause the machine to
become bricked or can cause Machine Check Exceptions.

    Discussion about this problem:
    https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
    https://bugzilla.kernel.org/show_bug.cgi?id=47121

    The patches to fix this problem:
    efi: Make 'efi_enabled' a function to query EFI facilities
    83e68189

    samsung-laptop: Disable on EFI hardware
    e0094244

Unfortunately this problem comes back again if users specify "noefi" option.
This parameter clears EFI_BOOT and that driver continues to run even if running
under EFI. Refer to the document, this parameter should clear
EFI_RUNTIME_SERVICES instead.

Documentation/kernel-parameters.txt:
===============================================================================
...
	noefi		[X86] Disable EFI runtime services support.
...
===============================================================================

Documentation/x86/x86_64/uefi.txt:
===============================================================================
...
- If some or all EFI runtime services don't work, you can try following
  kernel command line parameters to turn off some or all EFI runtime
  services.
	noefi		turn off all EFI runtime services
...
===============================================================================
Signed-off-by: NSatoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Link: http://lkml.kernel.org/r/511C2C04.2070108@jp.fujitsu.com
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

unregister_and_remove_pcpu on a NULL pointer is a no-op, so the NULL check in
sync_pcpu can be removed.
Signed-off-by: NCyril Roelandt <tipecaml@gmail.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This fixes CVE-2013-0228 / XSA-42

Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user
in 32bit PV guest can use to crash the > guest with the panic like this:

-------------
general protection fault: 0000 [#1] SMP
last sysfs file: /sys/devices/vbd-51712/block/xvda/dev
Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_netfront ext4
mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last
unloaded: scsi_wait_scan]

Pid: 1250, comm: r Not tainted 2.6.32-356.el6.i686 #1
EIP: 0061:[<c0407462>] EFLAGS: 00010086 CPU: 0
EIP is at xen_iret+0x12/0x2b
EAX: eb8d0000 EBX: 00000001 ECX: 08049860 EDX: 00000010
ESI: 00000000 EDI: 003d0f00 EBP: b77f8388 ESP: eb8d1fe0
 DS: 0000 ES: 007b FS: 0000 GS: 00e0 SS: 0069
Process r (pid: 1250, ti=eb8d0000 task=c2953550 task.ti=eb8d0000)
Stack:
 00000000 0027f416 00000073 00000206 b77f8364 0000007b 00000000 00000000
Call Trace:
Code: c3 8b 44 24 18 81 4c 24 38 00 02 00 00 8d 64 24 30 e9 03 00 00 00
8d 76 00 f7 44 24 08 00 00 02 80 75 33 50 b8 00 e0 ff ff 21 e0 <8b> 40
10 8b 04 85 a0 f6 ab c0 8b 80 0c b0 b3 c0 f6 44 24 0d 02
EIP: [<c0407462>] xen_iret+0x12/0x2b SS:ESP 0069:eb8d1fe0
general protection fault: 0000 [#2]
---[ end trace ab0d29a492dcd330 ]---
Kernel panic - not syncing: Fatal exception
Pid: 1250, comm: r Tainted: G      D    ---------------
2.6.32-356.el6.i686 #1
Call Trace:
 [<c08476df>] ? panic+0x6e/0x122
 [<c084b63c>] ? oops_end+0xbc/0xd0
 [<c084b260>] ? do_general_protection+0x0/0x210
 [<c084a9b7>] ? error_code+0x73/
-------------

Petr says: "
 I've analysed the bug and I think that xen_iret() cannot cope with
 mangled DS, in this case zeroed out (null selector/descriptor) by either
 xen_failsafe_callback() or RESTORE_REGS because the corresponding LDT
 entry was invalidated by the reproducer. "

Jan took a look at the preliminary patch and came up a fix that solves
this problem:

"This code gets called after all registers other than those handled by
IRET got already restored, hence a null selector in %ds or a non-null
one that got loaded from a code or read-only data descriptor would
cause a kernel mode fault (with the potential of crashing the kernel
as a whole, if panic_on_oops is set)."

The way to fix this is to realize that the we can only relay on the
registers that IRET restores. The two that are guaranteed are the
%cs and %ss as they are always fixed GDT selectors. Also they are
inaccessible from user mode - so they cannot be altered. This is
the approach taken in this patch.

Another alternative option suggested by Jan would be to relay on
the subtle realization that using the %ebp or %esp relative references uses
the %ss segment.  In which case we could switch from using %eax to %ebp and
would not need the %ss over-rides. That would also require one extra
instruction to compensate for the one place where the register is used
as scaled index. However Andrew pointed out that is too subtle and if
further work was to be done in this code-path it could escape folks attention
and lead to accidents.
Reviewed-by: NPetr Matousek <pmatouse@redhat.com>
Reported-by: NPetr Matousek <pmatouse@redhat.com>
Reviewed-by: NAndrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>