into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into uml.karaya.com:/home/jdike/linux/2.5/highmem-2.5

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

This fixes a procfs crash noticed by Anton Blanchard.

The procfs code can have a reference even to an already exited task, so
it needs to follow special rules accessing p->sig.  The atomic-signals
patch made this bug happen at a much higher frequency, but procfs i
believe was buggy ever since, it potentially used the freed signal
structure - which just did not result in a crash like it does today.

The proper fix is to take the tasklist read-lock in
collect_sigign_sigcatch(), this excludes __exit_sighand() freeing the
signal structure prematurely.

due to synchronize_irq() becoming a no-op when !CONFIG_SMP.

uml.ld.S.

into nuts.ninka.net:/home/davem/src/BK/net-2.5

into nuts.ninka.net:/home/davem/src/BK/net-2.5

With this we avoid doing skb_clone on skbs that will not be kept on
unacked lists.

Thanks do Andries Brouwer for reporting the problem and suggesting a
way to fix it.

Thanks to Andries Brouwer for providing a patch.

Crud.  Looks like my patch making script was borken, so orinoco_pci.c
wasn't updated properly.  The patch below should fix that, and adds
some other minor updates (driver version 0.13a) as well.

Fix pci_pool_create() from calling device_create_file() under
pools_lock.

Found by the new "may_sleep" infrastructure.

into nuts.ninka.net:/home/davem/src/BK/net-2.5

into home.transmeta.com:/home/torvalds/v2.5/linux

into mandrakesoft.com:/home/jgarzik/repo/net-drivers-2.5

into mandrakesoft.com:/home/jgarzik/repo/net-drivers-2.5

(contributed by Francois Romieu)

(contributed by James Blackwell)

into home.transmeta.com:/home/torvalds/v2.5/linux

Keeping track of dialing / auto hangup is per ISDN channel, so should
go into isdn_net_dev.

Again, ipppd has one kernel connection per channel in a MPPP
setting, so we should keep track in isdn_net_dev.

Dialing happens per channel / isdn_net_dev, so the move the
corresponding members there.

This is the first step of a long series moving members between
isdn_net_local and isdn_net_dev.

Today, a one-to-one relationship between these both structures exist, so
it does not really matter where the members live. However, the goal
is to get a correspondence like

net_device -> isdn_net_local -> master isdn_net_device
                                           |
                                slave  isdn_net_device
                                           |
                                slave  isdn_net_device

where more than one isdn_net_device can exist per actual net_device,
due to channel bundling.