ext3 transaction batching has been ineffective since the scheduler changes
forced us to replace the yield() with a schedule().

Using schedule_timeout(1) fixes it up again.  Benchmarking is positive with
wither a 1 or 10 millisecond delay in there, so there appears to be no need
to play around with HZ.

From: Kurt Garloff <garloff@suse.de>

A patch to parse the elf binaries for a PT_GNU_STACK section to set the stack
non-executable if possible.  Most parts have been shamelessly stolen from
Ingo Molnar's more ambitious stackshield
http://people.redhat.com/mingo/exec-shield/exec-shield-2.6.4-C9

The toolchain has meanwhile support for marking the binaries with a
PT_GNU_STACK section wwithout x bit as needed.

If no such section is found, we leave the stack to whatever the arch defaults
to.  If there is one, we explicitly disabled the VM_EXEC bit if no x bit is
found, otherwise explicitly enable.

- s/__inline__/inline/

- Remove lots of extraneous andi-was-here trailing whitespace

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

The attached patch improves the documentation of the _rcu list primitives.

From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br>

IBM LAN Adapter/A driver depends on mca-legacy.

From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br>

drivers/net/wan/cycx_drv.c: In function `load_cyc2x':
drivers/net/wan/cycx_drv.c:430: warning: unsigned int format, long unsigned int arg (arg 3)

From: Pavel Machek <pavel@ucw.cz>

This function will break with -mregparm, so mark it asmlinkage.

From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br>

drivers/media/dvb/frontends/tda1004x.c:191: warning: `errno' defined but not used

From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br>

sound/isa/wavefront/wavefront_synth.c:1923: warning: `errno' defined but not used

With CONFIG_LBD=n:

fs/open.c: In function `vfs_statfs_native':
fs/open.c:67: warning: comparison is always true due to limited range of data type
fs/open.c:70: warning: comparison is always true due to limited range of data type

From: Olaf Kirch <okir@suse.de>

The attached patch fixes a problem with the 32bit statfs call on NFS file
systems.  Some NFS servers return a value of -1 for the f_files and f_ffree.
The current code would think this is a 64bit value that cannot be converted
to 32bits.  Consequently, the system call would always fail.

The patch adds two special if() to detect a value of -1 for f_files and
f_ffree.

From: Trond Myklebust <trond.myklebust@fys.uio.no>

Fixes the Oops reported by Paul Blazejowski.  Bug turned out to be in the page
overflow checking for READDIRPLUS.

From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

From: Gerd Knorr <kraxel@bytesex.org>

This is a update for the cx88 driver.  There are *lots* of changes:

  * vbi support was added.
  * plenty of fixes for audio support (there are still problems
    through).
  * new cards added.
  * serveral minor tweaks.

From: Gerd Knorr <kraxel@bytesex.org>

This patch updates the documentation for the v4l drivers.

From: Gerd Knorr <kraxel@bytesex.org>

This patch updates the bttv driver.  Changes:

  (1) several card-specific tweaks.
  (2) make software vs. hardware i2c configurable per TV card.
  (3) reinitialize image parameters after chip reset.
  (4) make bttv quite by default on frame drops.
  (5) new insmod option: "debug_latency=1" to enable frame drop
      debug messages.

bttv is quite sensitive to irq latencies, especially when capturing both
video and vbi.  There are several reports about problems due to this, I don't
see that on my machines through.  (5) dumps a stracktrace if the driver
thinks the frame drop is is caused by high latencies as experiment, lets see
whenever that helps ...

drivers/built-in.o(.text+0x32912b): In function `dsp_buffer_init':
drivers/media/video/saa7134/saa7134-oss.c:77: undefined reference to `videobuf_dma_init'

From: Gerd Knorr <kraxel@bytesex.org>

This is a update for the saa7134 driver.  Changes:

  * add cropping support.
  * fix Makefile to build the saa6752hs module.
  * fix locking bug in oss dsp driver.
  * infrared remote keytable update.
  * some card-specific fixes.

From: Gerd Knorr <kraxel@bytesex.org>

Trivial patch, $subject says all, just a new keytable.

From: Gerd Knorr <kraxel@bytesex.org>

This patch allows to use switch to the second external input of the msp34xx
chips.  Also has some minor cleanups and more verbose debug info.

From: Gerd Knorr <kraxel@bytesex.org>

This patch fixes a bug in the tuner descriptions and prepares for the removal
of the type= insmod option by printing a warning when it is used.

From: Gerd Knorr <kraxel@bytesex.org>

Minor tweak in the v4l1 compatibility layer: Make sure that capture actually
is active before going to wait for a frame so we don't block forever.

From: Gerd Knorr <kraxel@bytesex.org>

The VIDIOC_CROPCAP ioctl had wrong R/W bits, this patch fixes it.

From: Andreas Gruenbacher <agruen@suse.de>

Return EOPNOTSUPP rather than EINVAL when we discover an ACL version
mismatch.

From: Olaf Kirch <okir@suse.de>

Some NFS clients respond badly to a TCP connection being reset immediately
after it has been accepted so:

- Accept more connections before starting to drop them

- Always drop the oldest connection - Random Early Drop doesn't really help
  here, and can hurt

- ratelimit the friendly warnings.

From: Andrea Arcangeli <andrea@suse.de>

We need a barrier before checking for kthread_should_stop in do_stop.

From: Davide Libenzi <davidel@xmailserver.org>

When I split evenpoll_release() in an inline fast path plus an
eventpoll_release_file() slow path, I forgot to change comments.

From: Romain Francoise <romain@orebokech.com>

arch/sparc64/mm/hugetlbpage.c does not include linux/module.h so
EXPORT_SYMBOL prints out warnings, and since sparc64 Makefiles have
-Werror, the build fails.

From: Olof Johansson <olof@austin.ibm.com>

As discussed on the ppc64 list yesterday and today:

On some ppc64 systems, Open Firmware will give memory device nodes that are
only 16MB in size, instead of the 256MB that our NUMA code currently
expects (see MEMORY_INCREMENT in mmzone.h).

Just changing the defines from 256MB to 16MB makes the table blow up from
32KB to 512KB, so this patch also makes it dynamically allocated based on
actual memory size.  Since all this is done before (well, during) bootmem
init so we need to use lmb_alloc().

Finally, there's no need to use a full int for node ID. Current max is 16
nodes, so a signed char still leaves plenty of room to grow.

From: Ingo Molnar <mingo@elte.hu>

Dave reported that /proc/*/status sometimes shows 101% as LoadAVG, which
makes no sense.

the reason of the bug is slightly incorrect scaling of the load_avg value. 
The patch below fixes this.

From: Arjan van de Ven <arjanv@redhat.com>

Below is a patch to enable 4Kb stacks for x86. The goal of this is to

1) Reduce footprint per thread so that systems can run many more threads
   (for the java people)

2) Reduce the pressure on the VM for order > 0 allocations. We see real life
   workloads (granted with 2.4 but the fundamental fragmentation issue isn't
   solved in 2.6 and isn't solvable in theory) where this can be a problem.
   In addition order > 0 allocations can make the VM "stutter" and give more
   latency due to having to do much much more work trying to defragment

The first 2 bits of the patch actually affect compiler options in a generic
way: I propose to disable the -funit-at-a-time feature from gcc.  With this
enabled (and it's default with -O2), gcc will very agressively inline
functions, which is nice and all for userspace, but for the kernel this makes
us suffer a gcc deficiency more: gcc is extremely bad at sharing stackslots,
for example a situation like this:

if (some_condition)
	function_A();
else
	function_B();

with -funit-at-a-time, both function_A() and _B() might get inlined, however
the stack usage of both functions of the parent function grows the stack
usage of both functions COMBINED instead of the maximum of the two.  Even
with the normal 8Kb stacks this is a danger since we see some functions grow
3Kb to 4Kb of stack use this way.  With 4Kb stacks, 4Kb of stack usage growth
obviously is deadly ;-( but even with 8Kb stacks it's pure lottery.
Disabling -funit-at-a-time also exposes another thing in the -mm tree; the
attribute always_inline is considered harmful by gcc folks in that when gcc
makes a decision to NOT inline a function marked this way, it throws an
error.  Disabling -funit-at-a-time disables some of the agressive inlining
(eg of large functions that come later in the .c file) so this would make
your tree not compile.

The 4k stackness of the kernel is included in modversions, so people don't
load 4k-stack modules into 8k-stack kernels.

At present 4k stacks are selectable in config.  When the feature has settled
in we should remove the 8k option.  This will break the nvidia modules.  But
Fedora uses 4k stacks so a new nvidia driver is expected soon.

drivers/acpi/events/evmisc.c: In function `acpi_ev_queue_notify_request':
drivers/acpi/events/evmisc.c:143: warning: too many arguments for format

The filempa_nopage() logic will go into a tight loop if
do_page_cache_readahead() doesn't actually start I/O against the target page.
This can happen if the disk is read-congested, or if the filesystem doesn't
want to read that part of the file for some reason.

We will accidentally break out of the loop because

	 (ra->mmap_miss > ra->mmap_hit + MMAP_LOTSAMISS)

will eventually become true.

Fix that up.

Remove the hardwired pagefault readaround distance in filemap_nopage() and
use the per-file readahead setting.

The main reason for this is in fact laptop-mode.  If you want to prevent the
disk from spinning up then you want all of your application's pages to be
pulled into memory in one hit.  Otherwise the disk will spin up each time you
use a new part of whatever application(s) you are running.

From: Bart Samwel <bart@samwel.tk>

Add support for the value "0" to ext3's "commit" option.  When this value
is given, ext3 substitutes it by the default commit interval.  Introduce a
constant JBD_DEFAULT_MAX_COMMIT_AGE for this.

From: Bart Samwel <bart@samwel.tk>

Adds /proc/sys/vm/laptop-mode: a special knob which says "this is a laptop".
In this mode the kernel will attempt to avoid spinning disks up.

Algorithm: the idea is to hold dirty data in memory for a long time, but to
flush everything which has been accumulated if the disk happens to spin up
for other reasons.

- Whenever a disk request completes (read or write), schedule a timer a few
  seconds hence.  If the timer was already pending, reset it to a few seconds
  hence.

- When the timer expires, write back the whole world.  We use
  sync_filesystems() for this because it will force ext3 journal commits as
  well.

- In balance_dirty_pages(), kick off background writeback when we hit the
  high threshold (dirty_ratio), not when we hit the low threshold.  This has
  the effect of causing "lumpy" writeback which is something I spent a year
  fixing, but in laptop mode, it is desirable.

- In try_to_free_pages(), only kick pdflush if the VM is getting into
  distress: we want to keep scanning for clean pages, deferring writeback.

- In page reclaim, avoid writing back the odd random dirty page off the
  LRU: only start I/O if the scanning is working harder.

The effect is to perform a sync() a few seconds after all I/O has ceased.

The value which was written into /proc/sys/vm/laptop-mode determines, in
seconds, the delay between the final I/O and the flush.

Additionally, the patch adds tools which help answer the question "why the
heck does my disk spin up all the time?".  The user may set
/proc/sys/vm/block_dump to a non-zero value and the kernel will print out
information which will identify the process which is performing disk reads or
which is dirtying pagecache.

The user should probably disable syslogd before setting block-dump.

This is always equal to constant zero.

From: Hugh Dickins <hugh@veritas.com>

rmap's try_to_unmap_one comments on find_vma failure, that a page may
temporarily be absent from a vma during mremap: no longer, though it is still
possible for this find_vma to fail, while unmap_vmas drops page_table_lock
(but that is no problem for file truncation).

From: Hugh Dickins <hugh@veritas.com>

mremap's move_vma should think ahead to lessen the chance of failure during
its rewind on failure: running out of memory always possible, but it's silly
for it to embark when it's near the map_count limit.

From: Hugh Dickins <hugh@veritas.com>

Subtle point from Rajesh Venkatasubramanian: when mremap's move_vma fails and
so rewinds, before moving the file-based ptes back, we must move new_vma
before old vma in the i_mmap or i_mmap_shared list, so that when racing
against vmtruncate we cannot propagate pages to be truncated back from
new_vma into the just cleaned old_vma.