* 'for-linus/samsung' of git://git.fluff.org/bjdooks/linux:
  ARM: S3C64XX: Fix possible clock look in EPLL and MPLL clock chains

Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip

* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip:
  x86, irq: Check move_in_progress before freeing the vector mapping
  x86: copy_from_user() should not return -EFAULT
  Revert "x86: Side-step lguest problem by only building cmpxchg8b_emu for pre-Pentium"
  x86/pci: Intel ioh bus num reg accessing fix
  x86: Fix size for ex trampoline with 32bit

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
  PCIe AER: prevent AER injection if hardware masks error reporting
  PCI/PM: Use per-device D3 delays
  PCI: Check the node argument passed to cpumask_of_node
  PCI: AER: fix aer inject result in kernel oops
  PCI: pcie portdrv: style cleanup

* 'bugfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6:
  nfs: fix oops in nfs_rename()
  sunrpc: fix build-time warning
  sunrpc: on successful gss error pipe write, don't return error
  SUNRPC: Fix the return value in gss_import_sec_context()
  SUNRPC: Fix up an error return value in gss_import_sec_context_kerberos()

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
  hp-wmi: remove double free caused by merge conflict

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6:
  [IA64] __per_cpu_idtrs[] is a memory hog
  [IA64] sanity in #include files.  Move fnptr to types.h
  [IA64] use helpers for rlimits
  [IA64] cpumask_of_node() should handle -1 as a node

__per_cpu_idtrs is statically allocated ... on CONFIG_NR_CPUS=4096
systems it hogs 16MB of memory. This is way too much for a quite
probably unused facility (only KVM uses dynamic TR registers).

Change to an array of pointers, and allocate entries as needed on
a per cpu basis.  Change the name too as the __per_cpu_ prefix is
confusing (this isn't a classic <linux/percpu.h> type object).
Signed-off-by: Tony Luck <tony.luck@intel.com>

* 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
  drm/radeon/kms: rs600: use correct mask for SW interrupt
  gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test
  drm/radeon/radeon_device.c: move a dereference below a NULL test
  drm/radeon/radeon_fence.c: move a dereference below the NULL test
  drm/radeon/radeon_connectors.c: add a NULL test before dereference
  drm/radeon/kms: fix memory leak
  drm/kms: Fix &&/|| confusion in drm_fb_helper_connector_parse_command_line()
  drm/edid: Fix CVT width/height decode
  drm/edid: Skip empty CVT codepoints
  drm: remove address mask param for drm_pci_alloc()
  drm/radeon/kms: add missing breaks in i2c and ss lookups
  drm/radeon/kms: add primary dac adj values table
  drm/radeon/kms: fallback to default connector table

* korg/drm-radeon-next:
  drm/radeon/kms: rs600: use correct mask for SW interrupt
  gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test
  drm/radeon/radeon_device.c: move a dereference below a NULL test
  drm/radeon/radeon_fence.c: move a dereference below the NULL test
  drm/radeon/radeon_connectors.c: add a NULL test before dereference
  drm/radeon/kms: fix memory leak
  drm/radeon/kms: add missing breaks in i2c and ss lookups
  drm/radeon/kms: add primary dac adj values table
  drm/radeon/kms: fallback to default connector table

The mask happens to be the same, but the IH is reading the status, not the
not the control register.
Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

If a NULL value is possible, the dereference should only occur after the
NULL test.

Coverity CID: 13338
Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

If a NULL value is possible, the dereference should only occur after the
NULL test.

Coverity CID: 13335
Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

If a NULL value is possible, the dereference should only occur after the
NULL test.

Coverity CID: 13334
Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

The encoder variable can be NULL in this function so I believe it should
be checked before dereference.

Coverity CID: 13253

[airlied: extremely unlikely to happen]
Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Stanse found a memory leak in radeon_master_create. master_priv is not
freed/assigned on all paths. Fix that.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Dave Airlie <airlied@redhat.com>

* drm-core-next:
  drm/kms: Fix &&/|| confusion in drm_fb_helper_connector_parse_command_line()
  drm/edid: Fix CVT width/height decode
  drm/edid: Skip empty CVT codepoints
  drm: remove address mask param for drm_pci_alloc()

This always evaluates to true.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm_pci_alloc() has input of address mask for setting pci dma
mask on the device, which should be properly setup by drm driver.
And leave it as a param for drm_pci_alloc() would cause confusion
or mistake would corrupt the correct dma mask setting, as seen on
intel hw which set wrong dma mask for hw status page. So remove
it from drm_pci_alloc() function.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

There is a possibility of a loop happening in the PLL output clock
chain on the S3C64XX series. clk_mpll's parent was set to be
clk_mout_mpll, but this is fed from clk_fout_epll (which is also
clk_mpll).

clk_mpll is meant to be the output from the MPLL, and clk_mout_mpll
is a seperate clock derived from the mux of clk_mpll and clk_fin_mpll
and thus should be considered a seperate clock.

Anything using clk_mpll directly really should not be relying on this
being the clock that is eventually routed to a peripheral, so remove the
loop and ensure that the clocks accurately represent the clock chain
in the device.

The clk_mpll is not being used outside of the s3c6400-clock.c code, so
this change should not break anything else.

Do the same for the EPLL.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

* 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: (23 commits)
  drm/i915: remove full registers dump debug
  drm/i915: Add DP dpll limit on ironlake and use existing DPLL search function
  drm/i915: Select the correct BPC for LVDS on Ironlake
  drm/i915: Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake
  drm/i915: Enable/disable the dithering for LVDS based on VBT setting
  drm/i915: Permit pinning whilst the device is 'suspended'
  drm/i915: Hold struct mutex whilst pinning power context bo.
  drm/i915: fix unused var
  drm/i915: Storage class should be before const qualifier
  drm/i915: remove render reclock support
  drm/i915: Fix RC6 suspend/resume
  drm/i915: execbuf2 support
  drm/i915: Reload hangcheck timer too for Ironlake
  drm/i915: only enable hotplug for detected outputs
  drm/i915: Track whether cursor needs physical address in intel_device_info
  drm/i915: Implement IS_* macros using static tables
  drm/i915: Move PCI IDs into i915 driver
  drm/i915: Update LVDS connector status when receiving ACPI LID event
  drm/i915: Add MALATA PC-81005 to ACPI LID quirk list
  drm/i915: implement new pm ops for i915
  ...

The MMU code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush.  This
is important when doing things like setting software breakpoints with
gdb.  So switch the NOMMU code over to do the same.

This patch makes the reasonable assumption that copy_from_user_page()
won't fail - which is probably fine, as we've checked the VMA from which
we're copying is usable, and the copy is not allowed to cross VMAs.  The
one case where it might go wrong is if the VMA is a device rather than
RAM, and that device returns an error which - in which case rubbish will
be returned rather than EIO.
Signed-off-by: Jie Zhang <jie.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: David McCullough <david_mccullough@mcafee.com>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

When working with FDPIC, there are many shared mappings of read-only
code regions between applications (the C library, applet packages like
busybox, etc.), but the current do_mmap_pgoff() function will issue an
icache flush whenever a VMA is added to an MM instead of only doing it
when the map is initially created.

The flush can instead be done when a region is first mmapped PROT_EXEC.
Note that we may not rely on the first mapping of a region being
executable - it's possible for it to be PROT_READ only, so we have to
remember whether we've flushed the region or not, and then flush the
entire region when a bit of it is made executable.

However, this also affects the brk area.  That will no longer be
executable.  We can mprotect() it to PROT_EXEC on MPU-mode kernels, but
for NOMMU mode kernels, when it increases the brk allocation, making
sys_brk() flush the extra from the icache should suffice.  The brk area
probably isn't used by NOMMU programs since the brk area can only use up
the leavings from the stack allocation, where the stack allocation is
larger than requested.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

The current code will load the stack size and protection markings, but
then only use the markings in the MMU code path.  The NOMMU code path
always passes PROT_EXEC to the mmap() call.  While this doesn't matter
to most people whilst the code is running, it will cause a pointless
icache flush when starting every FDPIC application.  Typically this
icache flush will be of a region on the order of 128KB in size, or may
be the entire icache, depending on the facilities available on the CPU.

In the case where the arch default behaviour seems to be desired
(EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine
whether we should be setting PROT_EXEC or not.

For arches that support an MPU (Memory Protection Unit - an MMU without
the virtual mapping capability), setting PROT_EXEC or not will make an
important difference.

It should be noted that this change also affects the executability of
the brk region, since ELF-FDPIC has that share with the stack.  However,
this is probably irrelevant as NOMMU programs aren't likely to use the
brk region, preferring instead allocation via mmap().
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

* 'for-2.6.33' of git://linux-nfs.org/~bfields/linux:
  sunrpc: fix peername failed on closed listener
  nfsd: make sure data is on disk before calling ->fsync
  nfsd: fix "insecure" export option

Signed-off-by: Tony Luck <tony.luck@intel.com>

Make sure compiler won't do weird things with limits. E.g. fetching
them twice may return 2 different values after writable limits are
implemented.

I.e. either use rlimit helpers added in
3e10e716
or ACCESS_ONCE if not applicable.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>

Recent change is missing to update "rehash".  With that change, it will
become the cause of adding dentry to hash twice.

This explains the reason of Oops (dereference the freed dentry in
__d_lookup()) on my machine.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Reported-by: Marvin <marvin24@gmx.de>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

pcibus_to_node can return -1 if we cannot determine which node a pci bus
is on. If passed -1, cpumask_of_node will negatively index the lookup array
and pull in random data:

# cat /sys/devices/pci0000:00/0000:00:01.0/local_cpus
00000000,00000003,00000000,00000000
# cat /sys/devices/pci0000:00/0000:00:01.0/local_cpulist
64-65

Change cpumask_of_node to check for -1 and return cpu_all_mask in this
case:

# cat /sys/devices/pci0000:00/0000:00:01.0/local_cpus
ffffffff,ffffffff,ffffffff,ffffffff
# cat /sys/devices/pci0000:00/0000:00:01.0/local_cpulist
0-127
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Tony Luck <tony.luck@intel.com>

There're some warnings of "nfsd: peername failed (err 107)!"
socket error -107 means Transport endpoint is not connected.
This warning message was outputed by svc_tcp_accept() [net/sunrpc/svcsock.c],
when kernel_getpeername returns -107. This means socket might be CLOSED.

And svc_tcp_accept was called by svc_recv() [net/sunrpc/svc_xprt.c]

        if (test_bit(XPT_LISTENER, &xprt->xpt_flags)) {
        <snip>
                newxpt = xprt->xpt_ops->xpo_accept(xprt);
        <snip>

So this might happen when xprt->xpt_flags has both XPT_LISTENER and XPT_CLOSE.

Let's take a look at commit b0401d72, this commit has moved the close
processing after do recvfrom method, but this commit also introduces this
warnings, if the xpt_flags has both XPT_LISTENER and XPT_CLOSED, we should
close it, not accpet then close.
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
Cc: J. Bruce Fields <bfields@fieldses.org>
Cc: Neil Brown <neilb@suse.de>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: stable@kernel.org
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>

nfsd is not using vfs_fsync, so I missed it when changing the calling
convention during the 2.6.32 window.  This patch fixes it to not only
start the data writeout, but also wait for it to complete before calling
into ->fsync.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: stable@kernel.org
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>

Fix auth_gss printk format warning:

net/sunrpc/auth_gss/auth_gss.c:660: warning: format '%ld' expects type 'long int', but argument 3 has type 'ssize_t'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

With the recent irq migration fixes (post 2.6.32), Gary Hade has noticed
"No IRQ handler for vector" messages during the 2.6.33-rc1 kernel boot on IBM
AMD platforms and root caused the issue to this commit:

> commit 23359a88
> Author: Suresh Siddha <suresh.b.siddha@intel.com>
> Date:   Mon Oct 26 14:24:33 2009 -0800
>
>    x86: Remove move_cleanup_count from irq_cfg

As part of this patch, we have removed the move_cleanup_count check
in smp_irq_move_cleanup_interrupt(). With this change, we can run into a
situation where an irq cleanup interrupt on a cpu can cleanup the vector
mappings associated with multiple irqs, of which one of the irq's migration
might be still in progress. As such when that irq hits the old cpu, we get
the "No IRQ handler" messages.

Fix this by checking for the irq_cfg's move_in_progress and if the move
is still in progress delay the vector cleanup to another irq cleanup
interrupt request (which will happen when the irq starts arriving at the
new cpu destination).
Reported-and-tested-by: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <1262804191.2732.7.camel@sbs-t61.sc.intel.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>

* 'davinci-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci:
  DaVinci: DM365: Add the device_enable for the DaVinci Keyscan
  davinci: enable ARCH_HAS_HOLES_MEMORYMODEL for DaVinci
  davinci: da8xx/omap-l1: mark RTC as a wakeup source
  davinci: cp_intc: provide set_wake function
  Davinci VPFE Capture: Take i2c adapter id through platform data

* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
  [SCSI] lpfc 8.3.7: Update Driver version to 8.3.7
  [SCSI] lpfc 8.3.7: Fix discovery failures.
  [SCSI] lpfc 8.3.7: Fix SCSI protocol related errors.
  [SCSI] lpfc 8.3.7: Fix hardware/SLI relates issues
  [SCSI] lpfc 8.3.7: Fix NPIV operation errors
  [SCSI] lpfc 8.3.7: Fix FC protocol errors
  [SCSI] stex: fix scan of nonexistent lun
  [SCSI] pmcraid: fix to avoid twice scsi_dma_unmap for a command
  [SCSI] qla2xxx: Update version number to 8.03.01-k9.
  [SCSI] qla2xxx: Added to EEH support.
  [SCSI] qla2xxx: Extend base EEH support in qla2xxx.
  [SCSI] qla2xxx: Fix for a multiqueue bug in CPU affinity mode
  [SCSI] qla2xxx: Get the link data rate explicitly during device resync.
  [SCSI] cxgb3i: Fix a login over vlan issue

This one reverts 9e3a6d15.
As reported by http://bugzilla.kernel.org/show_bug.cgi?id=14485,
this dump will cause hang problem on some machine. If something
really needs this kind of full registers dump, that could be done
within intel-gpu-tools.

Cc: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>

For some clocks, the old Ironlake DPLL calculator wold give m/n/p
combinations that didn't match the spreadsheet of what HW validation
tests.  Instead, use the G4X DPLL calculator, which does a better job
at it.

So we use the intel_g4x_find_best_pll to calculate the DPLL for CRT/HDMI/LVDS
on ironlake. At the same time to consider the dpll setting for display port, we
add the display port DPLL limit on ironlake, which will directly use the
function of intel_find_pll_ironlake_dp to get the corresponding dpll setting.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>

Select the correct BPC for LVDS on Ironlake. If it is 18-bit LVDS panel,
the BPC will be 6. When it is 24-bit LVDS panel, the BPC will 8.
At the same time the BPC will be 8 when the output device is CRT/HDMI/DP.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>

Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>