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 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.

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.

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

ioctl_by_bdev() passes in a NULL file*, so we had better not dereference it.

From: William Lee Irwin III <wli@holomorphy.com>

put_page_testzero() does BUG_ON(page_count(page)) when its argument is p.

From: William Lee Irwin III <wli@holomorphy.com>

To handle sparse physical APIC ID's properly the phys_cpu_present_map must
be scanned beyond bit NR_CPUS while ensuring no more than NR_CPUS are woken
in order not to attempt to wake non-addressible cpus.

The following patch adds that logic to smp_boot_cpus() and corrects the
failure to wake secondaries reported by dhowells, with successful wakeup,
runtime, reboot, and halting reported after it was applied.

From: mikpe@csd.uu.se

When I grepped for these variables I failed to notice the references in
acpi/wakeup.S.  This patch fixes this.

A couple of new PCI IDs which were found in 3com's driver by Xose Vazquez
Perez <xose@wanadoo.es>.

We don't know if these work, but if they are really 905B's and 920's it
should be OK.

From: davej@codemonkey.org.uk

Various performance critical sections.

The increased cache footprint may be a pessimisation, especially on earlier
CPUs where unlikely() doesn't do anything useful, and we fall back to
trusting gcc to DTRT.

Fix some places which were doing

	memcpy(to, from, sizeof(to));
and
	memset(to, 0, sizeof(to));

Found by the Stanford checker.