I had second thoughts on this.

Reporting background writeout errors via close() only really makes sense if
allthe IO has completed anyway: ie, the app has had the fd open without
writing to it for many tens of seconds.

It would be OK if it was harmless, but it is not.  Changes are, applications
ignore errors from close().  So if an application does a fork/exit and the
child correctly does an fsync() of the fd, the close-on-exit will have wiped
out any accumulated EIO/ENOSPC errors.

Or if someone does dup()/close()/fsync(), the fsync() could fail to detect
earlier errors, thanks to the close.


So.  The clear-and-report of errors on close() makes the reporting of errors
on fsync/msync/fdatasync less reliable.

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

The patch below fixes a 2.6 mm problem.  Without this patch, zeromapped
pages are not flushed properly when they are swapped out.

What happens is that the page->index field is zero for page table pages
corresponding to the zeromapped range.  This causes ptep_to_address() to
return an incorrect virtual address with the result that PTEs are never
invalidated at swap-out...

The fix below mirrors the remap_pmd_range() case.

From: Andi Kleen <ak@muc.de>

Another a bit ugly but necessary patch for 32bit emulation.

Some applications including some versions of java break when the stack is
beyond the i386 standard 3GB boundary.  For these add a 3GB personality
that moves the stack to 3GB and fixes the beginning of the mmap area.  It's
a bit ugly, but better than not running these applications at all (e.g. 
the Oracle installer depends on such a buggy java :-().  It's also not only
Java, but some other programs as well.

From: "Randy.Dunlap" <rddunlap@osdl.org>

prepare_write() and commit_write() return `int'.

Fixes an ia64 compile warning.

From: Chris Heath <chris@heathens.co.nz>

Here's a patch which fixes this warning:

drivers/char/ftape/lowlevel/fdc-io.c: In function `ftape_interrupt':
drivers/char/ftape/lowlevel/fdc-io.c:1299: warning: unused variable `_tracing'

From: "Randy.Dunlap" <rddunlap@osdl.org>

Please merge this makefile update from Sam.
From: Sam Ravnborg <sam@ravnborg.org>

Remark, I removed dependencies for configs.o - the are generated by kbuild
anyway. Only generated files needs explicit dependencies.

From: Greg KH <greg@kroah.com>

When working on converting the usb v4l drivers to the new v4l class
changes, I ran into this nasty bug.  Seems that the core was using a
structure after it had been freed.  The patch below fixes it.

From: Maciej Soltysiak <solt@dns.toxicfilms.tv>

this patches updates Documentation/ide.txt to reflect more options that
really are supported by the IDE driver (drivers/ide.c)

From: "Randy.Dunlap" <rddunlap@osdl.org>

Add the Kernel Janitors project to MAINTAINERS.

Probably the trivial patch monkey should be there too.

From: Dave Olien <dmo@osdl.org>

The DAC960 driver uses an ugly overloading of the O_NONBLOCK flag to
support the controller's RAID configuration features.

Opening "/dev/rd/c0d0" with the O_NONBLOCK flag set returns a file
descriptor that can be used to do RAID control operations using ioctl().
The normal ioctl operations are not availabe with that file descriptor.

This patch removes that O_NONBLOCK overloading from DAC960_open() and
DAC960_ioctl() functions.  It introduces a new "miscellaneous" device
named /dev/dac960_gam.  It uses minor device number 252 of the miscellaneous
character devices.

The currently distrubted "Global Array Manager" server distrubted by
LSIlogic on their web page page works only on RH7.3 or earlier.  It doesn't
work under RH9.  There are probably some library incompatabilities.
So, I don't view this patch as breaking anything that currently works.
If this software package is ever brought up to date (which I doubt),
then it can be modified to use this new device at that time.

From: Stephen Smalley <sds@epoch.ncsc.mil>

This patch against 2.6.0-test3-mm3 adds calls to the security_task_to_inode
hook to the pid*_revalidate functions to ensure that the inode security field
is also updated appropriately for /proc/pid inodes.  This corresponds with
the uid/gid update performed by the proc-pid-setuid-ownership-fix.patch that
is already in -mm3.

From: "B. D. Elliott" <bde@nwlink.com>

There's a bug:

- Someone reads a (say) root-owned process's /proc/pid/fd directory

  The inodes are instantiated owned by root.

- That process does a setuid

- The /proc/pid/* files still have the old ownerships.

This happened because we are now caching the proc entries.

The patch rewrites the ownership of the inodes under /proc/pid in the
d_revalidate() handler.

K7's (at least) are faulting in the prefetch instruction.  The AMD
engineers have said they will be getting back to us on it, and the fix is
looking complex, and nobody seems to be standing up to work on it.

So hum.  The usual manifestation is an oops in hlist_for_each(), down in
the VFS inode lookup code.  Disrupting our testers in this way is very bad,
so this patch just disables prefetch on all AMD parts in a rather stupid
way.

From: Oliver Xymoron <oxymoron@waste.org>

This fixes several calculation errors and races in entropy accounting
that would allow /dev/random output to greatly exceed the measured
entropy collection. This doesn't include any of my more controversial
hardening, it just makes it behave as intended.

It also corrects the operation of the 'catastrophic reseeding' feature
so that it will actually prevent the state extension attack it's meant
to guard against.

And finally, it also fixes a couple missed wake-up and accidental
sleep bugs uncovered by the above fixes.

Debug instrumentation has been improved to help verify correctness.

From: Oliver Xymoron <oxymoron@waste.org>

This patch adds locking for SMP. Apparently Willy never managed to
revive his laptop with his version so I revived mine.

The batch pool is copied as a block to avoid long lock hold times
while mixing it into the primary pool. 

Two locks are added:

gobal batch_lock
   batch_entropy_store can be called from any context, and typically from
   interrupts -> spin_lock_irqsave

   batch_entropy_process is called called via schedule_delayed_work and
   runs in process context -> spin_lock_irq

entropy_store.lock
   the mixing process is too expensive to be called from an interrupt
   context and the basic worker function extract_entropy can sleep, so
   all this stuff can be under a normal spin_lock

From: Sam Ravnborg <sam@ravnborg.org>

When building a kernel right after 'make mrproper' resulted in a very short
run, and no sign that .config was missing.  This has been fixed by adding a
new rule for .config in the top-level Makefile, and a new target
'silentoldconfig' in scripts/kconfig/Makefile.

Cleaned up a bit in scripts/kconfig/Makefile

into home.osdl.org:/home/torvalds/v2.5/linux

The free_netdev fixes in 2.6.0-test4 broke drivers/net/wan/cosa.c.
This fixes it.

The current cu3088 ccwgroup write code overwrite the last char of the
given arguments.  This fixes the problem.  It is been tested and applies
on latest bk.

Somewhere in the transition of task queue to the work queue, in
stallion.c, some of the schedule_task were left out from being converted
to schedule_work.  This fixes it.

	I wrote this driver a long time ago, and now, playing with my
brand new PARISC machine I found these problems, could you please apply
this patch?

	Ah, the "& more" refers to some alignment problems also solved
in this patch.

This patch removes the PCMCIA timer release functionality which is no
longer required (or supported).

Enable the Hammer specific events by giving the correct cpu string.
From, and tested by, Will Cohen.

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

    The thread for was unneeded on chips other than CH_8139_K/8129. So,
    this patch doesn't create the thread on chips other than
    CH_8139_K/8129.

Harmless in 2.4, but causes oopses on rmmod in 2.6.

slab poisoning can take care of this for us, anyway.

into redhat.com:/spare/repo/net-drivers-2.6

* removed ancient-kernel compat code from sk_mca.h.  I leave
  it to janitors to remove the now-useless SKMCA_xxx wrappers.
* removed ancient-kernel compat code from sk_mca.c.
* s/SKMCA_NETDEV/net_device/
* fixed static net_device initialization (this will go away
  when dynamic-alloc patches land)

Anybody with hardware, that can test this driver?

While it would be nice to keep using the generic version of RODATA, the
v850's linker-script structure is sufficiently different from that of
typical archs that it's not possible to use RODATA as it's currently
defined.  I earlier suggested splitting the generic definition of RODATA
into `RODATA_CONTENTS' and `RODATA' (a wrapper around RODATA_CONTENTS)
where most archs would use RODATA, and the v850 would use
RODATA_CONTENTS, however Kai didn't like that idea.

It _may_ be possible to rewrite the v850's linker scripts into something
more typical (using lots of individual output sections), but it doesn't
seem at all straightforward, so I don't have the time to do it right
now.

Anyway, this is the short-term work-around so that Linus's kernel works
on the v850.

o driver support headers update
o fix warnings

typo fixed.

In order to bring the 2.4 and 2.6 versions in sync, here is the
missing bit for the meye driver :)