into kroah.com:/home/greg/linux/BK/gregkh-2.5

Alan Stern wrote:
> I finally got tired of my computer locking up when I tried to rmmod the
> low-level host controller driver.  It turns out the problem lies in the
> root-hub status urb code in core/hcd.c -- primarily a result of
> rh_report_status() not calling hcd_giveback_urb()...

Or in short:  your patch removes some old logic for the "automagic
interrupt transfer" special casing ... which recently started to
break that rmmod path.

With automagic, the only time an interrupt urb (like the root hub
status urb) could legitimately be given back was for unlink.  But
that unlink doesn't seem to be issued in the same way lately during
the rmmod paths.  (If they're less bizarre lately, that's good!)


> If this patch seems all right, will you please let Greg know it's okay to
> apply it?

I changed a couple minor things below ... basically (a) fixing the
issue Duncan Sands pointed out (always call completions with irqs
disabled, even if hub driver currently doesn't care), (b) better
logic to avoid retriggering the timer during shutdown, (c) not
doing del_timer_sync() while holding that lock, plus (d) a minor
linewrap fix.

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

This patch removes a single-line inline function and replaces it with it's
expansion everywhere.   The inline function was really only there for a
transitional step.

This patch forces the generation of a bulk-transport reset after a command
abort.  Careful reading of the bulk-only specification shows that a reset
must be done after an abort to get the host and target back into phase.

I tried compiling USB gadget support on ppc64 (why not :). Looks like Im
seeing a conflict between const and __devinitdata:

drivers/usb/gadget/net2280.c:2645: pci_ids causes a section type conflict

usb-skelteon doesn't compile after recent changes.

This fixes a race noticed by Mike Galbraith: the scheduler can lose a
rebalance tick if some task happens to not be rescheduled in time.  This
is not a fatal condition, but an inconsistency nevertheless.

Supports some user-mode testing "firmware".

This fixes the scheduler's sync-wakeup code to be consistent on UP as
well.

Right now there's a behavioral difference between an UP kernel and an
SMP kernel running on a UP box: sync wakeups (which are only activated
on SMP) can cause a wakeup of a higher prio task, without preemption.
On UP kernels this does not happen.  This difference in wakeup behavior
is bad.

This patch activates sync wakeups on UP as well - in the cases sync
wakeups are done the waker knows that it will schedule away soon, so
this 'delay preemption' decision is correct on UP as well.

This removes the unused requeueing code.

This fixes an SMP window where the kernel could miss to handle a signal,
and increase signal delivery latency up to 200 msecs.  Sun has reported
to Ulrich that their JVM sees occasional unexpected signal delays under
Linux.  The more CPUs, the more delays.

The cause of the problem is that the current signal wakeup
implementation is racy in kernel/signal.c:signal_wake_up():

        if (t->state == TASK_RUNNING)
                kick_if_running(t);
	...
        if (t->state & mask) {
                wake_up_process(t);
                return;
        }

If thread (or process) 't' is woken up on another CPU right after the
TASK_RUNNING check, and thread starts to run, then the wake_up_process()
here will do nothing, and the signal stays pending up until the thread
will call into the kernel next time - which can be up to 200 msecs
later.

The solution is to do the 'kicking' of a running thread on a remote CPU
atomically with the wakeup.  For this i've added wake_up_process_kick().
There is no slowdown for the other wakeup codepaths, the new flag to
try_to_wake_up() is compiled off for them.  Some other subsystems might
want to use this wakeup facility as well in the future (eg.  AIO).

In fact this race triggers quite often under Volanomark rusg, with this
change added, Volanomark performance is up from 500-800 to 2000-3000, on
a 4-way x86 box.