Ingo reported that built-in drivers suffered bootup hangs with certain
driver unregistry sequences, due to sysfs breakage.

Do the minimal fix for v2.6.21: only wait if the driver is a module.
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  [CRYPTO] api: Flush the current page right than the next
  [CRYPTO] api: Use the right value when advancing scatterwalk_copychunks

On platforms where flush_dcache_page is needed we're currently flushing
the next page right than the one we've just processed.  This patch fixes
the off-by-one error.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

In the scatterwalk_copychunks loop, We should be advancing by
len_this_page and not nbytes.  The latter is the total length.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There was a typo in commit 7632fc8f,
preventing it from working - 32bit binaries crashed hopelessly before
the below fix and work perfectly now.
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In the scatterwalk_copychunks loop, We should be advancing by
len_this_page and not nbytes.  The latter is the total length.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
  Revert "ACPI: parse 2nd MADT by default"

This reverts commit 09fe5835.
http://bugzilla.kernel.org/show_bug.cgi?id=8283Signed-off-by: NLen Brown <len.brown@intel.com>

I've seen this several times on this drive, completely reproducible.

Once it has hung, power needs to be cut from the drive to recover it, a
simple reboot is not enough.  So I'd suggest disabling NCQ on this
drive.
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
Acked-by: NTejun Heo <htejun@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
  [MIPS] SMTC: Fix recursion in instant IPI replay code.
  [MIPS] BCM1480: Fix setting of irq affinity.
  [MIPS] do_page_fault() needs to use raw_smp_processor_id().
  [MIPS] SMTC: Fix false trigger of debug code on single VPE.
  [MIPS] SMTC: irq_{enter,leave} and kstats keeping for relayed timer ints.
  [MIPS] lockdep: Deal with interrupt disable hazard in TRACE_IRQFLAGS
  [MIPS] lockdep: Handle interrupts in R3000 style c0_status register.
  [MIPS] MV64340: Add missing prototype for mv64340_irq_init().
  [MIPS] MT: MIPS_MT_SMTC_INSTANT_REPLAY currently conflicts with PREEMPT.
  [MIPS] EV64120: Include <asm/irq.h> to fix warning.
  [MIPS] Ocelot: Fix warning.
  [MIPS] Ocelot: Give PMON_v1_setup a proper prototype.

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6:
  [IA64] Fix arch/ia64/pci/pci.c:571: warning: `return' with a value
  [IA64] Speed up boot - skip unnecessary clock calibration
  [IA64] bugfix stack layout upside-down
  [IA64] Fix possible invalid memory access in ia64_setup_msi_irq()

local_irq_restore -> raw_local_irq_restore -> irq_restore_epilog ->
	smtc_ipi_replay -> smtc_ipi_dq -> spin_unlock_irqrestore ->
	_spin_unlock_irqrestore -> local_irq_restore

The recursion does abort when there is no more IPI queued for a CPU, so
this isn't usually fatal which is why we got away with this for so long
until this was discovered by code inspection.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NMark Mason <mason@broadcom.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Original patch posted by Deepak Saxena <dsaxena@plexity.net>.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Make smtc_setup_irq() update the list of interrupts which need to be
watched by the debug code itself.  Also there is no need to initialize the
IPI swint when running with a single VPE, so don't initialize it.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

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

Between the mtc0 or di instruction that disables interrupts and the
following hazard barrier a processor may still take interrupts.  If an
interrupt is taken after interrupts are disabled but before the state
is updated it will appear to restore_all that it is incorrectly returning
with interrupts disabled.
Signed-off-by: NChris Dearman <chris@mips.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Check the IEP bit for R3000 style processors when checking to see if
interrupts will be reenabled in restore_all.
Signed-off-by: NChris Dearman <chris@mips.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

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

So until MIPS_MT_SMTC_INSTANT_REPLAY has been rewritten to solve this
issue, don't allow selecting it with PREEMPT.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

arch/mips/pci/pci-ev64120.c:10: warning: implicit declaration of function 'allocate_irqno'
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

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

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

Typo/thinko in bba6f6fcSigned-off-by: NTony Luck <tony.luck@intel.com>

Skip clock calibration if cpu being brought online is exactly the same
speed, stepping, etc., as the previous cpu. This significantly reduces
the time to boot very large systems.
Signed-off-by: NJack Steiner <steiner@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

ia64 expects following vm layout:

== low memory
[register-stack grows up]
[memory-stack grows down]
== high memory

But the code assigns the base of the register stack at the
maximum stack size offset from the fixed address where the
stack *might* start.  Stack randomization will result in the
memory stack starting at a lower address than this, and if the
user has set a low stack limit with "ulimit -s", then you can
end up with the register stack above the memory stack (or if
you were very unlucky right on top of it!).

Fix: Calculate the base address for the register stack starting
from the actual address of the memory stack.
Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The following 'if' statement in ia64_setup_msi_irq() always fails even
if create_irq() returns <0 value, because variable 'irq' is defined as
unsigned int. It would cause invalid memory access.

        irq = create_irq();
        if (irq < 0)
                return irq;
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6:
  NetXen: Fix hardware access for ppc architecture.
  sis190: new PHY support
  atl1: save mac address on remove

* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
  [IFB]: Fix crash on input device removal
  [BNX2]: Fix link interrupt problem.

The definition of struct ucc_slow puts the guemr register immediately after the
utpt register, when it should be at offset 0x90.  This patch adds the missing
0x52-byte padding.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Correct the alignment of the internal buffer used by the QUICC Engine
SDMA controller to 4Kbytes.  Correct the shift direction in the logic
that sets up the SDMR register for the QUICC Engine SDMA controller.
Signed-off-by: NChuck Meade <chuckmeade@mindspring.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The input_device pointer is not refcounted, which means the device may
disappear while packets are queued, causing a crash when ifb passes packets
with a stale skb->dev pointer to netif_rx().

Fix by storing the interface index instead and do a lookup where neccessary.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Acked-by: NJamal Hadi Salim <hadi@cyberus.ca>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This adds support of suspend/resume on i386 for HPET, which fixes a
number of timer-related failures around STR.
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Acked-by: NMichael S. Tsirkin <mst@dev.mellanox.co.il>
Acked-by: NJeff Chua <jeff.chua.linux@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'for-linus' of git://git.kernel.dk/data/git/linux-2.6-block:
  [PATCH] splice: partial write fix

Fix the bug, that reading into xip mapping from /dev/zero fills the user
page table with ZERO_PAGE() entries.  Later on, xip cannot tell which pages
have been ZERO_PAGE() filled by access to a sparse mapping, and which ones
origin from /dev/zero.  It will unmap ZERO_PAGE from all mappings when
filling the sparse hole with data.  xip does now use its own zeroed page
for its sparse mappings.  Please apply.
Signed-off-by: NCarsten Otte <cotte@de.ibm.com>
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

sys_madvise has down_write of mmap_sem, then madvise_remove calls
vmtruncate_range which takes i_mutex and i_alloc_sem: no, we can easily devise
deadlocks from that ordering.

madvise_remove drop mmap_sem while calling vmtruncate_range: luckily, since
madvise_remove doesn't split or merge vmas, it's easy to handle this case with
a NULL prev, without restructuring sys_madvise.  (Though sad to retake
mmap_sem when it's unlikely to be needed, and certainly down_read is
sufficient for MADV_REMOVE, unlike the other madvices.)
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Nick Piggin <npiggin@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

shmem_truncate_range has its own truncate_inode_pages_range, to free any pages
racily instantiated while it was in progress: a SHMEM_PAGEIN flag is set when
this might have happened.  But holepunching gets no chance to clear that flag
at the start of vmtruncate_range, so it's always set (unless a truncate came
just before), so holepunch almost always does this second
truncate_inode_pages_range.

shmem holepunch has unlikely swap<->file races hereabouts whatever we do
(without a fuller rework than is fit for this release): I was going to skip
the second truncate in the punch_hole case, but Miklos points out that would
make holepunch correctness more vulnerable to swapoff.  So keep the second
truncate, but follow it by an unmap_mapping_range to eliminate the
disconnected pages (freed from pagecache while still mapped in userspace) that
it might have left behind.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Nick Piggin <npiggin@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Miklos Szeredi observes that during truncation of shmem page directories,
info->lock is released to improve latency (after lowering i_size and
next_index to exclude races); but this is quite wrong for holepunching, which
receives no such protection from i_size or next_index, and is left vulnerable
to races with shmem_unuse, shmem_getpage and shmem_writepage.

Hold info->lock throughout when holepunching?  No, any user could prevent
rescheduling for far too long.  Instead take info->lock just when needed: in
shmem_free_swp when removing the swap entries, and whenever removing a
directory page from the level above.  But so long as we remove before
scanning, we can safely skip taking the lock at the lower levels, except at
misaligned start and end of the hole.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Miklos Szeredi observes BUG_ON(!entry) in shmem_writepage() triggered in rare
circumstances, because shmem_truncate_range() erroneously removes partially
truncated directory pages at the end of the range: later reclaim on pages
pointing to these removed directories triggers the BUG.  Indeed, and it can
also cause data loss beyond the hole.

Fix this as in the patch proposed by Miklos, but distinguish between "limit"
(how far we need to search: ignore truncation's next_index optimization in the
holepunch case - if there are races it's more consistent to act on the whole
range specified) and "upper_limit" (how far we can free directory pages:
generally we must be careful to keep partially punched pages, but can relax at
end of file - i_size being held stable by i_mutex).
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Cc: Miklos Szeredi <mszeredi@suse.cs>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>