* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
  [MIPS] Terminally fix local_{dec,sub}_if_positive
  [MIPS] Type proof reimplementation of cmpxchg.
  [MIPS] pg-r4k.c: Fix a typo in an R4600 v2 erratum workaround

* 'for-linus' of master.kernel.org:/pub/scm/linux/kernel/git/cooloney/blackfin-2.6:
  Blackfin arch: fix PORT_J BUG for BF537/6 EMAC driver reported by Kalle Pokki <kalle.pokki@iki.fi>
  Blackfin arch: gpio pinmux and resource allocation API required by BF537 on chip ethernet mac driver
  Blackfin arch: add some missing syscall
  binfmt_flat: checkpatch fixing minimum support for the blackfin relocations
  Binfmt_flat: Add minimum support for the Blackfin relocations

The fs was not unlocking the local alloc inode mutex in the code path in
which it failed to find a window of free bits in the global bitmap.
Signed-off-by: NSunil Mushran <sunil.mushran@oracle.com>
Signed-off-by: NMark Fasheh <mark.fasheh@oracle.com>

Cc: Kalle Pokki <kalle.pokki@iki.fi>
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NBryan Wu <bryan.wu@analog.com>

Blackfin arch: gpio pinmux and resource allocation API required by BF537 on chip ethernet mac driver
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NBryan Wu <bryan.wu@analog.com>

They contain 64-bit instructions so wouldn't work on 32-bit kernels or
32-bit hardware.  Since there are no users, blow them away.  They
probably were only ever created because there are atomic_sub_if_positive
and atomic_dec_if_positive which exist only for sake of semaphores.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

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

Restore a load from KSEG1 done as a workaround for an R4600 v2
erratum, dropped with 211be16de99a7424e66c0b6c0d00e2c970508ac2.
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

* 'sas-fixes' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6:
  aic94xx: fix DMA data direction for SMP requests

* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6:
  dm9601: Fix receive MTU
  mv643xx_eth: Do not modify struct netdev tx_queue_len
  qla3xxx: bugfix: Fix VLAN rx completion handling.
  qla3xxx: bugfix: Add memory barrier before accessing rx completion.

* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev:
  ata_piix: add another TECRA M3 entry to broken suspend list

* git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched:
  sched: fix profile=sleep

* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
  [SPARC64]: Fix missing load-twin usage in Niagara-1 memcpy.
  [SPARC64]: Fix put_user() calls in binfmt_aout32.c
  [SPARC]: Fix EBUS use of uninitialized variable.

* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
  [IEEE80211]: avoid integer underflow for runt rx frames
  [TCP]: secure_tcp_sequence_number() should not use a too fast clock
  [SFQ]: Remove artificial limitation for queue limit.

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
  [POWERPC] Fix xics set_affinity code

DMA-mapped SMP (scsi management protocol) requests going /to/ the device
need the PCI DMA data direction to indicate such.
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

dm9601 didn't take the ethernet header into account when calculating
RX MTU, causing packets bigger than 1486 to fail.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This driver erroneously zeros dev->tx_queue_len, since
mp->tx_ring_size has not yet been initialized.  Actually,
the driver shouldn't modify tx_queue_len at all and should
leave the value set by alloc_etherdev(), currently 1000.
Signed-off-by: NDale Farnsworth <dale@farnsworth.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Fix 4032 chip undocumented "feature" where bit-8 is set
if the inbound completion is for a VLAN.
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

There's a different version of DMI table for TECRA M3 where it has
proper vendor and product name entry.  Add the entry to the broken
suspend list.

Angus Turnbull reported and provided initial patch.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Cc: Angus Turnbull <angus@twinhelix.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

fix sleep profiling - we lost this chunk in the CFS merge.
Found-by: NMel Gorman <mel@csn.ul.ie>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

For the case where the source is not aligned modulo 8
we don't use load-twins to suck the data in and this
kills performance since normal loads allocate in the
L1 cache (unlike load-twin) and thus big memcpys swipe
the entire L1 D-cache.

We need to allocate a register window to implement this
properly, but that actually simplifies a lot of things
as a nice side-effect.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Reported by Chris Evans <scarybeasts@gmail.com>:

> The summary is that an evil 80211 frame can crash out a victim's
> machine. It only applies to drivers using the 80211 wireless code, and
> only then to certain drivers (and even then depends on a card's
> firmware not dropping a dubious packet). I must confess I'm not
> keeping track of Linux wireless support, and the different protocol
> stacks etc.
>
> Details are as follows:
>
> ieee80211_rx() does not explicitly check that "skb->len >= hdrlen".
> There are other skb->len checks, but not enough to prevent a subtle
> off-by-two error if the frame has the IEEE80211_STYPE_QOS_DATA flag
> set.
>
> This leads to integer underflow and crash here:
>
> if (frag != 0)
>    flen -= hdrlen;
>
> (flen is subsequently used as a memcpy length parameter).

How about this?
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

TCP V4 sequence numbers are 32bits, and RFC 793 assumed a 250 KHz clock.
In order to follow network speed increase, we can use a faster clock, but
we should limit this clock so that the delay between two rollovers is
greater than MSL (TCP Maximum Segment Lifetime : 2 minutes)

Choosing a 64 nsec clock should be OK, since the rollovers occur every
274 seconds.

Problem spotted by Denys Fedoryshchenko

[ This bug was introduced by f8595815 ]
Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is followup to Patrick's patch. A little optimization to enqueue
routine allows to remove artificial limitation on queue length.

Plus, testing showed that hash function used by SFQ is too bad or even worse.
It does not even sweep the whole range of hash values.
Switched to Jenkins' hash.
Signed-off-by: NAlexey Kuznetsov <kaber@ms2.inr.ac.ru>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

No, I didn't want to do this, but we had more stuff go in after -rc8
than we had in the previous -rc. Gaah.

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
  [MIPS] vmlinux.lds.S: Handle note sections
  [MIPS] Fix value of O_TRUNC

For some reason old binutils genertate larger headers so increase the text
offset of the vdso to avoid linker errors.

Roland McGrath explains:
  "There are extra symbols in the '.dynsym' section that are responsible
   for the size difference (They also cause corresponding inflation in
   '.gnu.version')

   Older ld's wrongly generated these unneeded symbols in .dynsym.  This
   was fixed not all that long ago (2006); binutils-2.17.50.0.6 might be
   the first fixed version, but I have not verified for sure where the
   cutoff was.

   The unneeded symbols et al from old ld add almost 700 bytes excess.
   This limits fairly tightly the amount by which the actual text and
   data in the vDSO can grow in the future without pushing the whole
   file over 4kb.  If it does grow later on, we should consider changing
   the layout with a config option or something to pack it better
   without that padding, when building the kernel with newer binutils."
Signed-off-by: NAndi Kleen <ak@suse.de>
Cc: Roland McGrath <roland@redhat.com>
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>

On a POWER6 machine running 2.6.23-rc8 I sometimes see the following error:

xics_set_affinity: No online cpus in the mask 00000000,00000000,00000000,00000001 for irq 20

In a desperate attempt to get a changelog entry in 2.6.23, I took a look
into it.

It turns out we are passing a real and not a virtual irq into
get_irq_server.  This works for the case where hwirq < NR_IRQS and we
set virq = hwirq.  In my case however hwirq = 590082 and we try and
access irq_desc[590082], slightly past the end at 512 entries.

Lucky we ship lots of memory with our machines.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Nick Piggin points out that splice isn't being good about the mmap
semaphore: while two readers can nest inside each others, it does leave
a possible deadlock if a writer (ie a new mmap()) comes in during that
nesting.

Original "just move the locking" patch by Nick, replaced by one by me
based on an optimistic pagefault_disable().  And then Jens tested and
updated that patch.
Reported-by: NNick Piggin <npiggin@suse.de>
Tested-by: NJens Axboe <jens.axboe@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'fixes-jgarzik' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6:
  [PATCH] libertas: build problems when partially modular

* master.kernel.org:/home/rmk/linux-2.6-arm:
  [ARM] Resolve PCI section warnings

* 'master' of ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb:
  V4L/DVB (6052): ivtv: fix udma yuv bug

* 'for-linus' of git://oss.sgi.com:8090/xfs/xfs-2.6:
  Revert "[XFS] Avoid replaying inode buffer initialisation log items if ..

[ Fixed it and added some commit messages by hand to that branch   - Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit b394e43e.

Lachlan McIlroy says:
    It tried to fix an issue where log replay is replaying an inode cluster
    initialisation transaction that should not be replayed because the inode
    cluster on disk is more up to date.  Since we don't log file sizes (we
    rely on inode flushing to get them to disk) then we can't just replay
    all the transations in the log and expect the inode to be completely
    restored.  We lose file size updates.  Unfortunately this fix is causing
    more (serious) problems than it is fixing.

SGI-PV: 969656
SGI-Modid: xfs-linux-melb:xfs-kern:29804a
Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
Signed-off-by: NTim Shimmin <tes@sgi.com>

Calling handle_futex_death in exit_robust_list for the different robust
mutexes of a thread basically frees the mutex.  Another thread might grab
the lock immediately which updates the next pointer of the mutex.
fetch_robust_entry over the next pointer might therefore branch into the
robust mutex list of a different thread.  This can cause two problems: 1)
some mutexes held by the dead thread are not getting freed and 2) some
mutexs held by a different thread are freed.

The next point need to be read before calling handle_futex_death.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Acked-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When calling the RELDISP VT ioctl, we are reading vt_newvt while the
console workqueue could be messing with it (through change_console()).  We
fix this race by taking the console semaphore before reading vt_newvt.
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
Acked-by: NAntonino Daplas <adaplas@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We need to disable all CPUs other than the boot CPU (usually 0) before
attempting to power-off modern SMP machines.  This fixes the
hang-on-poweroff issue on my MythTV SMP box, and also on Thomas Gleixner's
new toybox.
Signed-off-by: NMark Lord <mlord@pobox.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The virtual address space argument of clear_user_highpage is supposed to be
the virtual address where the page being cleared will eventually be mapped.
 This allows architectures with virtually indexed caches a few clever
tricks.  That sort of trick falls over in painful ways if the virtual
address argument is wrong.
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>