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

Support more chips and split out all the complex PHY
handling into a seperate file.

Revert the rtnl_lock API change, it is totally unneeded.
Instead we manage the todo work inside of net/core/dev.c

Also, we have to move sbin hotplug invocation outside of
the RTNL semaphore as well, both for register and unregister.

We had two major issues when unregistering networking devices.
1) Even trying to run hotplug asynchronously could deadlock
   if keventd was currently trying to get the RTNL semaphore
   in order to process linkwatch events.
2) Unregister needs to wait for the last reference to go away
   before the finalization of the unregister can execute.  This
   cannot occur under the RTNL semaphore as this is deadlock
   prone as well.

The solution is to do all of this stuff after dropping the
RTNL semaphore.  rtnl_lock, if it is about to protect a region
of code that could unregister network devices, registers a list
to which unregistered netdevs are attached.  At rtnl_unlock time
this list is processed to wait for refcounts to drop to zero and
then finalize the unregister.

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

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

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

SGI Modid: 2.5.x-xfs:slinx:149409a

SGI Modid: 2.5.x-xfs:slinx:149400a

the rest of XFS.  Fix numerous crimes against whitespace.

SGI Modid: 2.5.x-xfs:slinx:149398a

which is unnecessary in log recovery, clarify some recovery debug code.

SGI Modid: 2.5.x-xfs:slinx:149396a

field from the xfs_mount structure to the log structure (saves a couple
of pointer dereferences when writing to the log, with v2 logs only).

SGI Modid: 2.5.x-xfs:slinx:149395a

SGI Modid: 2.5.x-xfs:slinx:149232a

one spot, which lets us keep more common code in sync, 2.4/2.5 and is
slightly cleaner anyway.

SGI Modid: 2.5.x-xfs:slinx:149231a

changes to make log recovery respect the log device sector size.

SGI Modid: 2.5.x-xfs:slinx:149230a

basically turned it off.

SGI Modid: 2.5.x-xfs:slinx:148955a

SGI Modid: 2.5.x-xfs:slinx:148940a

SGI Modid: 2.5.x-xfs:slinx:148933a

record write during log recovery head/tail calculations.

SGI Modid: 2.5.x-xfs:slinx:148895a

SGI Modid: 2.5.x-xfs:slinx:148598a

SGI Modid: 2.5.x-xfs:slinx:148433a

SGI Modid: 2.5.x-xfs:slinx:148595a

SGI Modid: 2.5.x-xfs:slinx:148415a

SGI Modid: 2.5.x-xfs:slinx:148285a

SGI Modid: 2.5.x-xfs:slinx:132737a

SGI Modid: 2.5.x-xfs:slinx:147932a

Noticed by Julie DeWandel <jdewand@redhat.com>.

do_fork() needs to return the pid (or error), not the pointer to the
resulting process structure.  The process structure may not even be
valid any more, since do_fork() has already woken the process up (and as
a result it might already have done its thing and gone away).

Besides, doing it this way cleans up the users, which all really just
wanted the pid or error number _anyway_.

This fixes the x86 users, other architectures need to be fixed up as
well.

A familar type of Oops: d_path() can return an error ENAMETOOLONG, and
if we fail to test a segfault occurs.

So we must test.  What we do is a different matter.  Rather arbitrarily
I return the string " (too long)" for use in /proc/mounts.

Several SCSI drivers confuse CHECK_CONDITION and CHECK_CONDITION << 1.
One of them is NCR5380.c. Below a patch adding status_byte() twice.

(On the other hand, sun3_NCR5380.c does this right, and generally
looks better. Maybe they can be merged eventually.)

After

    # mount --rbind /tmp /mnt

(on 2.5.68) I have a corrupted namespace. Umounting /mnt fails,
and /proc/mounts contains

    ...
    /dev/root /mnt ext3 rw 0 0
    proc /mnt/proc proc rw 0 0
    usbfs /mnt/proc/bus/usb usbfs rw 0 0
    /dev/hdb5 /mnt/usr reiserfs rw 0 0
    ...

where of course no directories /mnt/proc or /mnt/usr exist.

This is caused by the fact that copy_tree() thinks that the dentry
it is called with is the root of the filesystem. If it is not,
confusion arose.

This patch fixes this confusion.

- Fix possible memory leak in iso.c
- Added handling for more than 1 Logical_Unit_Number entry in a unit
  directory for SBP-2. This allows for handling the second type of LUN
  that we didn't support yet.

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