into kroah.com:/home/greg/linux/BK/usb-2.6

Rusty decided to preprocess a *.lds.S file in parallele with the new *.lds infrastructure
being added to kbuild. Fix that up.
Also added the file to targets so we do not see recompile each time the kernel is build.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

A bug that slipped through when introducing Makefile.host.
A good way to check if people actually uses make O= ;-)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

Gadgetfs updates:

 - Resolve a problem that came from a change in the API to AIO:
   kiocb->private type and size changed, but the name remained
   the same ... so GCC wouldn't report pending memory-corruption.

 - Probe the controller at runtime, eliminatingting config-specific
   defines which need to be updated for each new controller.  Rip
   out the old #defines.

 - Use newish APIs to let VBUS current be used to recharge
   batteries (or whatever).

 - Use no_llseek() ... endpoints are pure data streams.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Fix tty layer sleep/locking problem (again) ... when this is
called through the network stack (PPP) sleeping isn't allowed.
There's some bugtraq ID for this.

From: Oliver Neukum <oliver@neukum.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The previous workaround didn't enable the BTIC bit on CPUs where it is
broken.  However, it seems some firmwares will unconditionally set it,
so this new patch will actually _clear_ it on CPUs where it is broken.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Recent yenta_socket (and maybe others) rely on some pcibios_* functions
to be available to modules.  This exports them.

The trackpad on recent Apple laptops tend to emmit spurrious 'right
clicks' apparently.  This patch from Alex Clausen fixes it, please
apply.  The trackpad cannot normally emit a right click, so just filter
those out.
Signed-off-by: Alexander Clausen <alex@skip86.com>
Signed-off-by: Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

msnd #defined outb to outb_p, which wasn't a good idea on platforms
that had outb_p #defined to outb ;-)
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

qd65xx assumed that char is always signed
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

"v" and "r" are not good names for variables local in macro...
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

That was a nasty one - missing include of config.h in a file that has
non-trivial ifdefs.  With some configs it ended up with very odd conflicts
(we get included early, take the wrong branch of ifdef, then get another
file included, it pulls in config.h and picks the right branch of its
ifdef; surprise, surprise, they conflict).
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

arm forgot to export memchr(); everybody else does export it and it's used
in modules.
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Forgot to switch return type from ssize_t to int when switching to seq_file
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into kernel.bkbits.net:/home/davem/sparc-2.6

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: David S. Miller <davem@redhat.com>

Benh says: "Please revert that for now, I need to figure out what they
were exactly trying to do and will come up with something if it makes
sense but the patch as-is doesn't"

Cset exclude: khali@linux-fr.org|ChangeSet|20040825202122|07524

into kernel.bkbits.net:/home/davem/net-2.6

into nuts.davemloft.net:/disk1/BK/sparc-2.6

Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@redhat.com>

It looks fine to me, except that I decided to play chicken as far as the
give_sigsegv update of sa_handler is concerned.

Arun, I hope I got the ia32 emulation parts right, but you may want to
double-check.

The patch seems to work fine as far as I have tested.  I'm seeing some
oddity in context-switch overhead and pipe latency as reported by LMbench,
but I suspect that's due to another change that happened somewhere between
2.6.5-rc1 and Linus' bk tree as of this morning.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

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

Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Ok, here are the sparc64 and sparc32 versions.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

  Add the signal race changes to x86-64 to make it compile again.

  Didn't merge the more pointless changes from i386.

  Also remove the special SA_ONESHOT handling, doesn't seem to be needed
  anymore.

From: Mikael Pettersson <mikpe@csd.uu.se>

  The signal-race-fixes patch in 2.6.8-rc2-mm1 appears to have broken
  x86-64's ia32 emulation.

  When forcing a SIGSEGV the old code updated "*ka", where ka was a pointer
  to current's k_sigaction for SIGSEGV.  Now "ka_copy" points to a copy of
  that structure, so assigning "*ka_copy" doesn't do what we want.  Instead do
  the assignment via current->...  just like the normal signal delivery code
  does.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

2.6.8-rc2-mm1 reintroduced the signal-race-fixes patch for i386, x86_64,
s390, and ia64, breaking all other archs.

The patch below updates ppc, following the pattern of i386.  Compiled &
runtime tested.  No observable breakage.
Signed-off-by: Mikael Pettersson <mikpe@csd.uu.se>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

  Update s30 for the signal race fix

From: Mikael Pettersson <mikpe@csd.uu.se>

  The signal-race-fixes patch in 2.6.8-rc2-mm1 appears to be a bit broken on
  s390.

  When forcing a SIGSEGV the old code updated "*ka", where ka was a pointer
  to current's k_sigaction for SIGSEGV.  Now "ka_copy" points to a copy of
  that structure, so assigning "*ka_copy" doesn't do what we want.  Instead do
  the assignment via current->...  just like i386 and x86_64 do.

  Furthermore, the SA_ONESHOT handling wasn't deleted.  That is now handled
  by generic code in the kernel.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The problem:

  In arch/i386/signal.c, in the do_signal() function, it calls
  get_signal_to_deliver() which returns the signal number to deliver (along
  with siginfo).  get_signal_to_deliver() grabs and releases the lock, so
  the signal handler lock is not held in do_signal().  Then the do_signal()
  calls handle_signal(), which uses the signal number to extract the
  sa_handler, etc.

  Since no lock is held, it seems like another thread with the same
  signal handler set can come in and call sigaction(), it can change
  sa_handler between the call to get_signal_to_deliver() and fetching the
  value of sa_handler.  If the sigaction() call set it to SIG_IGN, SIG_DFL,
  or some other fundamental change, that bad things can happen.

The patch:

  You have to get the sigaction information that will be delivered while
  holding sighand->siglock in get_signal_to_deliver().

  In 2.4, it can be fixed per-arch and requires no change to the
  arch-independent code because the arch fetches the signal with
  dequeue_signal() and does all the checking.

The test app:

  The program below has three threads that share signal handlers.  Thread
  1 changes the signal handler for a signal from a handler to SIG_IGN and
  back.  Thread 0 sends signals to thread 3, which just receives them.
  What I believe is happening is that thread 1 changes the signal handler
  in the process of thread 3 receiving the signal, between the time that
  thread 3 fetches the signal info using get_signal_to_deliver() and
  actually delivers the signal with handle_signal().

  Although the program is obvously an extreme case, it seems like any
  time you set the handler value of a signal to SIG_IGN or SIG_DFL, you can
  have this happen.  Changing signal attributes might also cause problems,
  although I am not so sure about that.

  (akpm: this test app segv'd on SMP within milliseconds for me)


#include <signal.h>
#include <stdio.h>
#include <sched.h>

char stack1[16384];
char stack2[16384];

void sighnd(int sig)
{
}

int child1(void *data)
{
	struct sigaction act;

	sigemptyset(&act.sa_mask);
	act.sa_flags = 0;
	for (;;) {
		act.sa_handler = sighnd;
		sigaction(45, &act, NULL);
		act.sa_handler = SIG_IGN;
		sigaction(45, &act, NULL);
	}
}

int child2(void *data)
{
	for (;;) {
		sleep(100);
	}
}

int main(int argc, char *argv[])
{
	int pid1, pid2;

	signal(45, SIG_IGN);
	pid2 = clone(child2, stack2 + sizeof(stack2) - 8,
			CLONE_SIGHAND | CLONE_VM, NULL);
	pid1 = clone(child1, stack1 + sizeof(stack2) - 8,
			CLONE_SIGHAND | CLONE_VM, NULL);

	for (;;) {
		kill(pid2, 45);
	}
}
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

And don't accept UTF translations as the start of a control
state either.

The ebtables brouting chain, traversed through the call
br_should_route_hook(), can alter a packet. The redirect target
does this, f.e., to change the MAC destination.

Bart discovered this and proposed a patch; this is a revised version.
This version cleans up the handle_bridge code in net/core/dev.c as well
as getting rid of extra rcu_read_lock and only does the br_port checking
once.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@redhat.com>

MDA is ISA-only ;-)