Fixes for big-endian systems in soundcard.h and awe_voice.h

This patch fixes the AFMT_S16_NE (include/linux/soundcard.h) and AWE_PATCH
(awe_voice.h) macros on big-endian systems.

It also moves _PATCHKEY into a new file, patchkey.h, in order to remove a
duplicate definition of it from awe_voice.h.
Signed-off-by: Stuart Brady <sdbrady@ntlworld.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Fix bug #4509
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch fixes a typo in the Intel AC'97 audio driver intel8x0.c for
Intel ESB2.
Signed-off-by: Jason Gaston <Jason.d.gaston@intel.com>
Cc: <tiwai@suse.de>
Cc: <perex@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This makes sure that reclaimable buffer headers and reclaimable inodes
are accounted properly during the overcommit checks.
Signed-off-by: Andrea Arcangeli <andrea@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The recent change fix-crash-in-entrys-restore_all.patch

 	childregs->esp = esp;

 	p->thread.esp = (unsigned long) childregs;
-	p->thread.esp0 = (unsigned long) (childregs+1);
+	p->thread.esp0 = (unsigned long) (childregs+1) - 8;

 	p->thread.eip = (unsigned long) ret_from_fork;

introduces an inconsistency between esp and esp0 before the task is run the
first time.  esp0 is no longer the actual start of the stack, but 8 bytes
off.

This shows itself clearly in a scenario when a ptracer that is set to also
ptrace eventual children traces program1 which then clones thread1.  Now
the ptracer wants to modify the registers of thread1.  The x86 ptrace
implementation bases it's knowledge about saved user-space registers upon
p->thread.esp0.  But this will be a few bytes off causing certain writes to
the kernel stack to overwrite a saved kernel function address making the
kernel when actually running thread1 jump out into user-space.  Very
spectacular.

The testcase I've used is:
/* start with strace -f ./a.out */
#include <pthread.h>
#include <stdio.h>

void *do_thread(void *p)
{
	for (;;);
}

int main()
{
	pthread_t one;
	pthread_create(&one, NULL, &do_thread, NULL);
	for (;;);
	return 0;
}

So, my solution is to instead of just adjusting esp0 that creates an
inconsitent state I adjust where the user-space registers are saved with -8
bytes.  This gives us the wanted extra bytes on the start of the stack and
esp0 is now correct.  This solves the issues I saw from the original
testcase from Mateusz Berezecki and has survived testing here.  I think
this should go into -mm a round or two first however as there might be some
cruft around depending on pt_regs lying on the start of the stack.  That
however would have broken with the first change too!

It's actually a 2-line diff but I had to move the comment of why the -8 bytes
are there a few lines up. Thanks to Zwane for helping me with this.
Signed-off-by: Alexander Nyberg <alexn@telia.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Patch from Nicolas Pitre

Signed-off-by: Nicolas Pitre
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Patch from Nicolas Pitre

This better express things, and should cover RMK's weird SMP toys.

Signed-off-by: Nicolas Pitre
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This patch adds i18n support for make *config, allowing users to have the
config process in their own language.

No printk was harmed in the process, don't worry, so all the bug reports,
kernel messages, etc, remain in english, just the user tools to configure
the kernel are internationalized.

Users not interested in translations can just unset the related LANG,
LC_ALL, etc env variables and have the config process in plain english,
something like:

LANG= make menuconfig

is enough for having the whole config process in english. Or just don't
install any translation file.

Translations for brazilian portuguese are being done by a team of
volunteers at:

http://www.visionflex.inf.br/kernel_ptbr/pmwiki.php/Principal/Traducoes

To start the translation process:

  make update-po-config

  This will generate the pot template named scripts/kconfig/linux.pot,
  copy it to, say, ~/es.po, to start the translation for spanish.

To test your translation, as root issue this command:

  msgfmt -o /usr/share/locale/es/LC_MESSAGES/linux.mo ~/es.po

  Replace "es" with your language code.

  Then execute, for instance:

  make menuconfig

The current patch doesn't use any optimization to reduce the size of the
generated .mo file, it is possible to use the config option as a key, but
this doesn't prevent the current patch from being used or the translations
done under the current scheme to be in any way lost if we chose to do any
kind of keying.

Thanks to Fabricio Vaccari for starting the pt_BR (brazilian portuguese)
translation effort, Thiago Maciera for helping me with the gconf.cc (QT
frontent) i18n coding and to all the volunteers that are already working on
the first translation, to pt_BR.

I left the question on whether to ship the translations with the stock kernel
sources to be discussed here, please share your suggestions.
Signed-off-by: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org
Signed-off-by: Andrew Morton <akpm@osdl.org>

Currently sparc and sparc64's UP cpu_idle() checks current pid. This
is old time legacy. Now it's paranoia.
Signed-off-by: Coywolf Qi Hunt <coywolf@lovecn.org>
Acked-by: William Irwin <wli@holomorphy.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

tg3_stop_block() errors can be safely ignored since tg3_chip_reset()
always follows tg3_stop_block() calls.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

multipath_wrandom needs to use GFP_ATOMIC.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

warning: untested, but it there's not too much chance for screwups
Signed-off-by: David S. Miller <davem@davemloft.net>

this matches the API used by other link layer like ethernet or token
ring.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

This causes sk->sk_prot to change, which makes the socket
release free the sock into the wrong SLAB cache.  Fix this
by introducing sk_prot_creator so that we always remember
where the sock came from.
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

SGI Modid: xfs-linux:xfs-kern:22378a
Signed-off-by: Nathan Scott <nathans@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>

[XFS] Use the right offset when ensuring a delayed allocate conversion has covered the offset originally requested.  Can cause data corruption when multiple processes are performing writeout on different areas of the same file.  Quite difficult to hit though.

SGI Modid: xfs-linux:xfs-kern:22377a
Signed-off-by: Nathan Scott <nathans@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>
.

SGI Modid: xfs-linux:xfs-kern:22376a
Signed-off-by: Nathan Scott <nathans@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>

SGI Modid: xfs-linux:xfs-kern:191625a
Signed-off-by: Eric Sandeen <sandeen@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>

SGI Modid: xfs-linux:xfs-kern:191586a
Signed-off-by: Daniel Moore <dxm@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>

handling for unwritten extents can be moved out of interrupt context.

SGI Modid: xfs-linux:xfs-kern:22343a
Signed-off-by: Nathan Scott <nathans@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>

SGI Modid: xfs-linux:xfs-kern:22342a
Signed-off-by: Nathan Scott <nathans@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>

SGI Modid: xfs-linux:xfs-kern:191411a
Signed-off-by: Eric Sandeen <sandeen@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>

SGI Modid: xfs-linux:xfs-kern:22261a
Signed-off-by: Nathan Scott <nathans@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>

SGI Modid: xfs-linux:xfs-kern:190711a
Signed-off-by: Dean Roehrich <roehrich@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>
.

SGI Modid: xfs-linux:xfs-kern:190725a
Signed-off-by: Eric Sandeen <sandeen@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>
.

SGI Modid: xfs-linux:xfs-kern:22032a
Signed-off-by: Nathan Scott <nathans@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>

SGI Modid: xfs-linux:xfs-kern:21937a
Signed-off-by: Nathan Scott <nathans@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>

SGI Modid: xfs-linux:xfs-kern:21915a
Signed-off-by: Nathan Scott <nathans@sgi.com>
Signed-off-by: Christoph Hellwig <hch@sgi.com>

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>

Rather than using a long "depends on..." and "default y" lines for
these options, use select instead.
Signed-off-by: Russell King <rmk@arm.linux.org.uk>

This file got missed in the commit of patch 2661/1 thanks to a buggy
script.
Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Various places in the ARM kernel implicitly assumed that kernel
stacks are always 8K due to hard coded constants.  Replace these
constants with definitions.

Correct the allowable range of kernel stack pointer values within
the allocation.  Arrange for the entire kernel stack to be zeroed,
not just the upper 4K if CONFIG_DEBUG_STACK_USAGE is set.
Signed-off-by: Russell King <rmk@arm.linux.org.uk>

With 2.6.11 and 2.6.12-rc2 (and perhaps a few versions before) usb
drivers for multi-interface devices, which do
usb_driver_release_interface() in their disconnect(), make rmmod hang.

It turns out to be due to a bug in drivers/base/bus.c:driver_detach(),
that iterates over the list of attached devices with
list_for_each_safe() under an assumption that device_release_driver()
only releases the current device, while it may also call
device_release_driver() for other devices on the same list.

The following patch fixes it.  Please consider applying.
Signed-off-by: Roman Kagan <rkagan@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Earlier in the same function dev->bus is checked before dereferenced,
make consistent although I honestly don't know if dev->bus could
ever be NULL

Found by the Coverity tool
Signed-off-by: Alexander Nyberg <alexn@dsv.su.se>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>