Add user pointer annotations.

on the list-head being at the top of the DRI data structures and
using hard casts.

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

All the other GART drivers display what they've found, so make this
one follow suit.

Offering the K7 GARTs on 64bit kernels causes sillyness, like reports of
"unrecognised device, try unsupported".  We don't want people to even try
that, so don't offer it in the first place.

There's really no good reason for offering any of the IA32 era GARTs on a
x86-64 64bit kernel. If Intel (or whoever) ever do an x86-64 clone, a new
gart driver will be started anyways, as has been done for amd-k8-agp.

This optioned saved just a handful of bytes, and uglied up the code 
quite a lot. Saving less than a page of memory is not as important as
maintainable code.

into tetrachloride.(none):/mnt/raid/src/kernel/2.5/agpgart

Also includes various other fixes from Matt Tolentino

 - bad preprocessor test always tested true, even when it shouldn't.
 - annotate user pointers with proper annotations.

Both found by my automatic type checker tool.

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

type evaluation.  This tags the system call interfaces in
fs/open.c, fs/dcache.c and mm/swapfile.c - and tags the path
walking helper functions.

It can miss an fput() if passed the fd of a file which has no ->mapping.

From: Marc Zyngier <mzyngier@freesurf.fr>

The included patch helps 3c59x to display the correct identification
string (3c592 and 3c597 were displayed as 3c590). It also gets rid of
the EISA_bus reference, which is not needed anymore since the driver
has been ported to the EISA probing API.

From: Manfred Spraul <manfred@colorfullife.com>

Update and clarify the incorrect commentary around task_lock()

From: "Martin J. Bligh" <mbligh@aracnet.com>

Fix the commentary around the address_space fields.

MS_ASYNC will currently wait on previously-submitted I/O, then start new I/O
and not wait on it.  This can cause undesirable blocking if msync is called
rapidly against the same memory.

So instead, change msync(MS_ASYNC) to not start any IO at all.  Just flush
the pte dirty bits into the pageframe and leave it at that.

The IO _will_ happen within a kupdate period.  And the application can use
fsync() or fadvise(FADV_DONTNEED) if it actually wants to schedule the IO
immediately.

(This has triggered an ext3 bug - the page's buffers get dirtied so fast
that kjournald keeps writing the buffers over and over for 10-20 seconds
before deciding to give up for some reason)

From: Andreas Gruenbacher <agruen@suse.de>

Missing brelse() in ext2/ext3 extended attribute code

The ext2 and ext3 EA implementations fail to release a buffer_head if
the inode that is being accessed is sharing EAs with another inode, and
an attribute is set to the same value that it has already, like so:

        $ touch f g
	$ setfattr -n user.test -v test f g
	# (Now, both f and g refer to the same EA block.)
	$ setfattr -n user.test -v test f

With the bug, an "invalidate: busy buffer" or "invalidate: dirty
buffer" message will be logged when the file system is unmounted. This
patch fixes the problem.

At the implementation level:

The code was assuming that ext3_xattr_cache_find cannot return the same
block the inode already is associated with, so testing for (old_bh !=
new_bh) would determine whether the old block is resued or an additional
bh is held. This is wrong if the EA block is used by multiple inodes (in
which case it stays in the cache), and the block isn't actually
modified.  Instead of testing for (old_bh != new_bh), the code now does
a get_bh() in the branch that keeps the old block, which assures that
new_bh now is either NULL or a handle that must be released at the end
of ext3_xattr_set_handle2().

From: Davide Libenzi <davidel@xmailserver.org>


This fixes a bug that might happen having a thread doing epoll_wait() with
another thread doing epoll_ctl(EPOLL_CTL_DEL) and close(). The fast check
inside eventpoll_release() is good to not effect performace of code not
using epoll, but it requires get_file() to be called ( that can be avoided
by dropping the fast check ). I opted to keep the fast check and to have
epoll to call get_file() before the event send loop. I tested it on UP and
2SMP with a bug-exploiting program provided by @pivia.com ( thx to them )
and it looks fine. I also update the 2.4.20 epoll patch with this fix :

From: Russell Miller <rmiller@duskglow.com>

A BUG or an oops will often leave a machine in a useless state.  There is no
way to remotely recover the machine from that state.

The patch adds a /proc/sys/kernel/panic_on_oops sysctl which, when set, will
cause the x86 kernel to call panic() at the end of the oops handler.  If the
user has also set /proc/sys/kernel/panic then a reboot will occur.

The implementation will try to sleep for a while before panicing so the oops
info has a chance of hitting the logs.

The implementation is designed so that other architectures can easily do this
in their oops handlers.

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

task_vsize() mysteriously appeared on my profiles.  This should remove it
from them by using the already in-use elsewhere for rlimit checks
mm->total_vm for the benefit of O(1) cachelines touched.

From: "Hua Zhong" <hzhong@cisco.com>

Fix a token-pasting warning from recent gcc's

From: Hugh Dickins <hugh@veritas.com>

try_to_unuse drop mmlist_lock across unuse_process (with pretty dance
of atomic_incs and mmputs of various mmlist markers, and a polite new
cond_resched there), so unuse_process can pte_chain_alloc(GFP_KERNEL)
and pass that down and down and down and down to unuse_pte: which
cannot succeed more than once on a given mm (make that explicit by
returning back up once succeeded).  Preliminary checks moved up from
unuse_pte to unuse_pmd, and done more efficiently (avoid that extra
pte_file test added recently), swapoff spends far too long in here.
Updated locking comments and references to try_to_swap_out.

From: Hugh Dickins <hugh@veritas.com>

Update a few locking comments in rmap.c.

Spinlocks don't have a buslocked unlock and are faster.

On a P4, time to write a 4M file with 4M one-byte-write()s:

Before:
	0.72s user 5.47s system 99% cpu 6.227 total
	0.76s user 5.40s system 100% cpu 6.154 total
	0.77s user 5.38s system 100% cpu 6.146 total

After:
	1.09s user 4.92s system 99% cpu 6.014 total
	0.74s user 5.28s system 99% cpu 6.023 total
	1.03s user 4.97s system 100% cpu 5.991 total