* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
  sparc64: Sync FPU state in VIS emulation handler.
  sparc64: Fix VIS emulation bugs
  sparc: asm/bitops.h should define __fls
  sparc64: Fix bug in PTRACE_SETFPREGS64 handling.

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

* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  x86: fix early panic with boot option "nosmp"
  x86/oprofile: fix Intel cpu family 6 detection
  oprofile: fix CPU unplug panic in ppro_stop()
  AMD IOMMU: fix possible race while accessing iommu->need_sync
  AMD IOMMU: set device table entry for aliased devices
  AMD IOMMU: struct amd_iommu remove padding on 64 bit
  x86: fix broken flushing in GART nofullflush path
  x86: fix dma_mapping_error for 32bit x86

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

* 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  sched: don't export sched_mc_power_savings in laptops

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

* 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  check_hung_task(): unsigned sysctl_hung_task_warnings cannot be less than 0
  documentation: local_ops fix on_each_cpu

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
  MIPS: Return ENOSYS from sys32_syscall on 64bit kernels like elsewhere.
  MIPS: 64-bit: vmsplice needs to use the compat wrapper for o32 and N32.
  MIPS: o32: Fix number of arguments to splice(2).
  MIPS: Malta: Consolidate platform device code.
  MIPS: IP22, Fulong, Malta: Update defconfigs.
  MIPS: Malta: Add back RTC support
  MIPS: Fix potential DOS by untrusted user app.

* 'for-linus' of git://oss.sgi.com/xfs/xfs:
  [XFS] Fix hang after disallowed rename across directory quota domains

When project quota is active and is being used for directory tree
quota control, we disallow rename outside the current directory
tree. This requires a check to be made after all the inodes
involved in the rename are locked. We fail to unlock the inodes
correctly if we disallow the rename when the target is outside the
current directory tree. This results in a hang on the next access
to the inodes involved in failed rename.
Reported-by: NArkadiusz Miskiewicz <arekm@maven.pl>
Signed-off-by: NDave Chinner <david@fromorbit.com>
Tested-by: NArkadiusz Miskiewicz <arekm@maven.pl>
Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>

When the o32 errno was changed to ENOSYS, we forgot to update the code
for 64bit kernels.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Acked-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The syscall code was assuming splice only takes 4 arguments so no stack
arguments were being copied from the userspace stack to the kernel stack.
As the result splice was likely to fail with EINVAL.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

After adding the RTC platform device to malta-platform.c malta-mtd.c should
get unified with the rest of the platform device code.

These haven't seen much attention for too long but particularly important
enable RTC_CLASS and CONFIG_RTC_HCTOSYS so the wall clock time is set on
kernel startup.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

With the conversion of MIPS to RTC_LIB the old RTC driver CONFIG_RTC became
unselectable.  Fix by setting up a platform device.  Also enable
RTC_CLASS so system time gets set from RTC on kernel initialization.

[Ralf: Original patch by Tiejun; polished nice and shiny by me]
Signed-off-by: NTiejun Chen <tiejun.chen@windriver.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

On a 64 bit kernel if an o32 syscall was made with a syscall number less
than 4000, we would read the function from outside of the bounds of the
syscall table.  This led to non-deterministic behavior including system
crashes.

While we were at it we reworked the 32 bit version as well to use fewer
instructions.  Both 32 and 64 bit versions are use the same code now.
Signed-off-by: NVlad Malov <Vlad.Malov@caviumnetworks.com>
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Copy the FPU state to the task's thread_info->fpregs for the VIS emulation
functions to access.
Signed-off-by: NHong H. Pham <hong.pham@windriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Impact: fix boot crash with numcpus=0 on certain systems

Fix early exception in __get_smp_config with nosmp.

Bail out early when there is no MP table.
Reported-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Tested-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

This patch fixes some bugs in VIS emulation that cause the GCC test
failure

FAIL: gcc.target/sparc/pdist-3.c execution test

for both 32-bit and 64-bit testing on hardware lacking these
instructions.  The emulation code for the pdist instruction uses
RS1(insn) for both source registers rs1 and rs2, which is obviously
wrong and leads to the instruction doing nothing (the observed
problem), and further inspection of the code shows that RS1 uses a
shift of 24 and RD a shift of 25, which clearly cannot both be right;
examining SPARC documentation indicates the correct shift for RS1 is
14.

This patch fixes the bug if single-stepping over the affected
instruction in the debugger, but not if the testcase is run
standalone.  For that, Wind River has another patch I hope they will
send as a followup to this patch submission.
Signed-off-by: NJoseph Myers <joseph@codesourcery.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Introduce into the MN10300 gdbstub 16550 driver a couple of barrier() calls to
replace the removed volatility of the input/output index variables for the Rx
ring buffer.  A previous patch added them into the on-chip serial port driver.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add myself as overall maintainer of the security subsystem (generally,
components under the top-level security directory).  This addresses
the lack of an official maintainer for the increasing number of
security projects being incorporated into the kernel.
Signed-off-by: NJames Morris <jmorris@namei.org>
Acked-by: NChris Wright <chrisw@sous-sol.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
  block: fix setting of max_segment_size and seg_boundary mask
  block: internal dequeue shouldn't start timer
  block: set disk->node_id before it's being used
  When block layer fails to map iov, it calls bio_unmap_user to undo

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
  powerpc/83xx: Fix MCU support merge issue in mpc8349emitx.dts
  powerpc: Fix dma_map_sg() cache flushing on non coherent platforms

* 'for-2.6.28' of git://linux-nfs.org/~bfields/linux:
  NLM: client-side nlm_lookup_host() should avoid matching on srcaddr
  nfsd: use of unitialized list head on error exit in nfs4recover.c
  Add a reference to sunrpc in svc_addsock
  nfsd: clean up grace period on early exit

The code used '&= 0x00002000' when it tried to set the TCO_EN bit, which
obviously didn't set that bit at all, but instead just reset all the
other bits in the SMI_EN register.

This bug seemingly caused various random behavior, with Frans Pop
reporting that X.org just silently hung at startup and Rafael Wysocki
reports the fan spinning with full speed.

See
	http://lkml.org/lkml/2008/12/3/178
	http://bugzilla.kernel.org/show_bug.cgi?id=12162

The problem seems to have been triggered by "[WATCHDOG] iTCO_wdt :
problem with rebooting on new ICH9 based motherboards" (commit
7cd5b08b), but the bogus code existed
before that too (in the "supermicro_old_pre_stop()" function), it just
apparently never showed up due to different logic.

In that commit the broken code got moved around and now gets executed
much more.
Reported-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NFrans Pop <elendil@planet.nl>
Cc: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

bitops_64.h includes the generic one; pretty sure 32 should too.

(Found by using __fls in generic code and breaking sparc defconfig build:
 thanks Stephen and linux-next!)
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Merge branch 'oprofile-for-tip' of git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile into x86/urgent

Alan Jenkins wrote:
> This is on an EeePC 701, /proc/cpuinfo as attached.
>
> Is this expected?  Will the next release work?
>
> Thanks, Alan
>
> # opcontrol --setup --no-vmlinux
> cpu_type 'unset' is not valid
> you should upgrade oprofile or force the use of timer mode
>
> # opcontrol -v
> opcontrol: oprofile 0.9.4 compiled on Nov 29 2008 22:44:10
>
> # cat /dev/oprofile/cpu_type
> i386/p6
> # uname -r
> 2.6.28-rc6eeepc

Hi Alan,

Looking at the kernel driver code for oprofile it can return the "i386/p6" for
the cpu_type. However, looking at the user-space oprofile code there isn't the
matching entry in libop/op_cpu_type.c or the events/unit_mask files in
events/i386 directory.

The Intel AP-485 says this is a "Intel Pentium M processor model D". Seems like
the oprofile kernel driver should be identifying the processor as "i386/p6_mobile"

The driver identification code doesn't look quite right in nmi_init.c

http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=blob;f=arch/x86/oprofile/nmi_int.c;h=022cd41ea9b4106e5884277096e80e9088a7c7a9;hb=HEAD

has:

409         case 10 ... 13:
410                 *cpu_type = "i386/p6";
411                 break;

Referring to the Intel AP-485:
case 10 and 11 should produce "i386/piii"
case 13 should produce "i386/p6_mobile"

I didn't see anything for case 12.

Something like the attached patch. I don't have a celeron machine to verify that
changes in this area of the kernel fix thing.

-Will
Signed-off-by: NWilliam Cohen <wcohen@redhat.com>
Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>

Just found the merge issue in 44274698
("powerpc/83xx: Add support for MCU microcontroller in .dts files"):
the commit adds the MCU controller node into the DMA node, which is
wrong because the MCU sits on the I2C bus. Fix this by moving the MCU
node into the I2C controller node.

The original patch[1] was OK though. ;-)
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

If oprofile statically compiled in kernel, a cpu unplug triggers
a panic in ppro_stop(), because a NULL pointer is dereferenced.
Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>

Fix setting of max_segment_size and seg_boundary mask for stacked md/dm
devices.

When stacking devices (LVM over MD over SCSI) some of the request queue
parameters are not set up correctly in some cases by default, namely
max_segment_size and and seg_boundary mask.

If you create MD device over SCSI, these attributes are zeroed.

Problem become when there is over this mapping next device-mapper mapping
- queue attributes are set in DM this way:

request_queue   max_segment_size  seg_boundary_mask
SCSI                65536             0xffffffff
MD RAID1                0                      0
LVM                 65536                 -1 (64bit)

Unfortunately bio_add_page (resp.  bio_phys_segments) calculates number of
physical segments according to these parameters.

During the generic_make_request() is segment cout recalculated and can
increase bio->bi_phys_segments count over the allowed limit.  (After
bio_clone() in stack operation.)

Thi is specially problem in CCISS driver, where it produce OOPS here

    BUG_ON(creq->nr_phys_segments > MAXSGENTRIES);

(MAXSEGENTRIES is 31 by default.)

Sometimes even this command is enough to cause oops:

  dd iflag=direct if=/dev/<vg>/<lv> of=/dev/null bs=128000 count=10

This command generates bios with 250 sectors, allocated in 32 4k-pages
(last page uses only 1024 bytes).

For LVM layer, it allocates bio with 31 segments (still OK for CCISS),
unfortunatelly on lower layer it is recalculated to 32 segments and this
violates CCISS restriction and triggers BUG_ON().

The patch tries to fix it by:

 * initializing attributes above in queue request constructor
   blk_queue_make_request()

 * make sure that blk_queue_stack_limits() inherits setting

 (DM uses its own function to set the limits because it
 blk_queue_stack_limits() was introduced later.  It should probably switch
 to use generic stack limit function too.)

 * sets the default seg_boundary value in one place (blkdev.h)

 * use this mask as default in DM (instead of -1, which differs in 64bit)

Bugs related to this:
https://bugzilla.redhat.com/show_bug.cgi?id=471639
http://bugzilla.kernel.org/show_bug.cgi?id=8672Signed-off-by: NMilan Broz <mbroz@redhat.com>
Reviewed-by: NAlasdair G Kergon <agk@redhat.com>
Cc: Neil Brown <neilb@suse.de>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Tejun Heo <htejun@gmail.com>
Cc: Mike Miller <mike.miller@hp.com>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

Merge branch 'iommu-fixes-2.6.28' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/linux-2.6-iommu into x86/urgent

blkdev_dequeue_request() and elv_dequeue_request() are equivalent and
both start the timeout timer.  Barrier code dequeues the original
barrier request but doesn't passes the request itself to lower level
driver, only broken down proxy requests; however, as the original
barrier code goes through the same dequeue path and timeout timer is
started on it.  If barrier sequence takes long enough, this timer
expires but the low level driver has no idea about this request and
oops follows.

Timeout timer shouldn't have been started on the original barrier
request as it never goes through actual IO.  This patch unexports
elv_dequeue_request(), which has no external user anyway, and makes it
operate on elevator proper w/o adding the timer and make
blkdev_dequeue_request() call elv_dequeue_request() and add timer.
Internal users which don't pass the request to driver - barrier code
and end_that_request_last() - are converted to use
elv_dequeue_request().
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Mike Anderson <andmike@linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

disk->node_id will be refered in allocating in disk_expand_part_tbl, so we
should set it before disk->node_id is refered.
Signed-off-by: NCheng Renquan <crquan@gmail.com>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

mapping.  Which is good if pages were mapped - but if they were provided
by someone else and just copied then bad things happen - pages are
released once here, and once by caller, leading to user triggerable BUG
at include/linux/mm.h:246.
Signed-off-by: NPetr Vandrovec <petr@vandrovec.name>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

The access to the iommu->need_sync member needs to be protected by the
iommu->lock. Otherwise this is a possible race condition. Fix it with
this patch.
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

In some rare cases a request can arrive an IOMMU with its originial
requestor id even it is aliased. Handle this by setting the device table
entry to the same protection domain for the original and the aliased
requestor id.
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

Remove 16 bytes of padding from struct amd_iommu on 64bit builds
reducing its size to 120 bytes, allowing it to span one fewer
cachelines.
Signed-off-by: NRichard Kennedy <richard@rsk.demon.co.uk>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

Impact: fix warnings-limit cutoff check for debug feature

unsigned sysctl_hung_task_warnings cannot be less than 0
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: remove stale IOTLB entries

In the non-default nofullflush case the GART is only flushed when
next_bit wraps around. But it can happen that an unmap operation unmaps
memory which is behind the current next_bit location. If these addresses
are reused it may result in stale GART IO/TLB entries. Fix this by
setting the GART next_bit always behind an unmapped location.
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

From: Chris Torek <chris.torek@windriver.com>

>The SPARC64 kernel code for PTRACE_SETFPREGS64 appears to be an exact copy 
>of that for PTRACE_GETFPREGS64.  This means that gdbserver and native 
>64-bit GDB cannot set floating-point registers.

It looks like a simple typo.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On PowerPC 4xx or other non cache-coherent platforms, we lost the
appropriate cache flushing in dma_map_sg() when merging the 32 and
64-bit DMA code (commit 4fc665b8,
"powerpc: Merge 32 and 64-bit dma code").  This restores it.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NBecky Bruce <beckyb@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>