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.

From: Christoph Hellwig <hch@lst.de>

This is a really old patch from the IA64 tree and as Cirrus Logic doesn't
maintain the driver anymore for about two years now no one picked it up..

From: David Mosberger <davidm@napali.hpl.hp.com>

Don't truncate the ioremap return value to 32-bits.

From: Shane Shrybman <shrybman@sympatico.ca>

Attached are two patches that make bttv compile and work in 2.5.69-mm6.  I
think this broke in -mm4.

From: Gerd Knorr <kraxel@bytesex.org>

Yet another big one (due to not being updated for a long time) -- saa7134
driver update.  Changes:

 * various bugfixes / cleanups.

 * new cards added to the cardlist.

 * started support for saa7133/35 chips.

 * make the driver check pci quirks.

From: Gerd Knorr <kraxel@bytesex.org>

This patch updates the tv card tuner module.  It adds support for a new tuner
and has some minor fixes + cleanups.  Also deletes some dead code.

From: Gerd Knorr <kraxel@bytesex.org>

This patch updates a number of video4linux-related i2c modules.  There are a
number of bugfixes which accumulated over time, also some no-op i2c changes
due to merging the i2c cleanups back into my tree and tweak them to make the
modules compile on both 2.5.x and 2.4.x.

From: Gerd Knorr <kraxel@bytesex.org>

This patch updates the bttv documentation.

From: Gerd Knorr <kraxel@bytesex.org>

This patch updates the v4l1-compat module.  Changes:

 * use f_op->poll() instead of do_select()

 * reduce stack usage of the v4l1_translate_ioctl() function.

 * misc minor fixes here and there.

From: Gerd Knorr <kraxel@bytesex.org>

This minor patch updates the video-buf module.  It just adds a export
for the videobuf_next_field function and adds some debug printk's.

From: "Paul E. McKenney" <paulmck@us.ibm.com>

The vmtruncate() function shifts down by PAGE_CACHE_SHIFT, then calls
vmtruncate_list(), which deals in terms of PAGE_SHIFT instead.  Currently,
no harm done, since PAGE_CACHE_SHIFT and PAGE_SHIFT are identical.  Some
day they might not be, hence this patch.

I also took the liberty of modifying a hand-coded "if" that seems to
optimize for files that are not mapped to instead use unlikely().

From: mikpe@csd.uu.se

Here is a patch to fix CONFIG_APM=m in 2.5.69-bk11.  My patch to have APM
restore the systenter MSRs failed to handle the modular case, which fails
with unresolved symbols.

Since suspend.o is used from both APM (module or built-in) and ACPI sleep
(built-in), I made suspend.o built-in and dependent on CONFIG_PM.

From: Oleg Drokin <green@namesys.com>

With the current 'one block at a time' algorithm, writes past the end of a
file are slow because each new file block is separately added into the tree
causing shifting of other items which is CPU expensive.

With this new implementation if you write into file with big enough chunks,
it uses half as much CPU.  Also this version is more SMP friendly than the
current one.

There are some known-bad applications that break with this patch (ie.  start
to work very slow or even hang).

This is because the filesystem returns a large value in the stat.st_blocksize
hint (128k instead of 4k).  This tickles a small number of application bugs.
One is KDE's kmail 3.04 (fixed by upgrading to 3.1+) and the other is
sleepycat's database from before 1997.

If you hit a slowdown problem that you believe is related to the increased
"recommended i/o size" value, try to mount your fs with nolargeio=1 mount
option (remount should work too).

This patch exports block_commit_write(), generic_osync_inode() and
remove_suid() to modules.

I've had these reiserfs patches in -mm for many months.  We've been
undecided because they trigger bugs in a couple of apps.  But those apps
are now fixed, so it's best to get these speedups in.


From: Oleg Drokin <green@namesys.com>

This patch allows insertion of more than one "indirect" block pointer into
the tree in reiserfs.  (with all the necessary balancing code changes).
The first user of that feature is hole-creation code that is now ~1000
times more cpu-efficient for the case of large holes.

Apparently boomerang_interrupt() is generating lots of "nobody cared"
warnings - one per packet it seems.  Frankly, I don't have a clue why.

These are ancient cards and the driver is otherwise stable, so just
change it to return IRQ_HANDLED and move on...

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

I was just looking over this and noticed 2.4.x makes u64 dma_addr_t
conditional on CONFIG_HIGHMEM64G where 2.5.x uses CONFIG_HIGHMEM.  It's
clearly not necessary on CONFIG_HIGHMEM4G, hence this obvious patch.

 - generic_file_open() comment fix (Bill Irwin)

 - kerneldoc fix in truncate.c (Aniruddha M Marathe)

 - remove truncate debug check.

 - page_lock comment fix (Robert Love)

 - remove unused device mapper label.

 - 3c509 docco fix ("Mark Tranchant" <mark@tranchant.freeserve.co.uk>)

--

 Documentation/networking/3c509.txt |    2 +-
 drivers/md/dm-ioctl.c              |    1 -
 fs/open.c                          |    2 +-
 include/linux/fs.h                 |    2 +-
 mm/truncate.c                      |    8 +++-----
 5 files changed, 6 insertions(+), 9 deletions(-)

Fix an accidentally negated comparison.

From: Martin Bligh

Change the defn of cpu_callout_map for voyager to volatile to match other
stuff.

From: Martin Bligh

Add cpu_mask_to_apicid to generic arch to fit with Keith's changes.

From: john stultz <johnstul@us.ibm.com>

This patch fixes a circular dependency (a function in mach_apic.h requires
hard_smp_processor_id() and hard_smp_processor_id() requires macros from
mach_apic.h) that has been in the subarch code for a bit, but was hacked
around with some #ifdefs.

With the inclusion of the generic-subarch the hack was dropped and bigsmp
and summit promptly broke.  So this makes things compile again.

It is incorrectly precalculating the string's length.

This fixes a race condition in the RiscPC DMA code, which causes
DMA for a channel to halt due to a race condition between the
hardware state machine and the software programming the next DMA
buffer.