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

Even a BUG_ON() makes a measurable difference.  So remove some gratuitous
ones which will just trigger a null pointer deref anyway.

Also remove some debug code which isn't really being maintained any more.

Also replace (effectively):

	test_bit(N, foo);
	set_bit(N, foo);

with

	set_bit(N, foo);
	test_bit(N, foo);

In the first case we'll go onto the bus twice: once for the cache miss and
once to get exclusive write access.  In the second case we only go on the bus
once.  I think.  Certainly this trick chaved 40% off the cost of
shrink_list() when I did it there...

This patch is worth 1% or so on the bash script testing.

several functions in rmap.c are searching the ptes[] array fo find the first
non-null entry.

Despite the fact tha the whole lot is in L1 cache, it is expensive,
especially on 128-byte cacheline machines.

We can encode the index of the first non-null pte entry inside the
pte_chain's `next' field and remove those searches altogether.

This reduces the rmap CPU tax by about 25% on a P4.  For a total runtime
reduction of around 5% in the bash-script intensive test which I use.

Maintaining the `nr_reverse_maps' provides makes a small but
measurable decrease in page_add_rmap() overhead.

I don't think it's a very useful metric, and it can be sort-of inferred from
slabinfo.

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

The cache_sizes array needs to be NULL terminated, otherwise an oversized
kmalloc request runs off the end of the table.

Now that sparc64 is using gcc-3.x we can disallow gcc-2.91, etc.

Documentation/Changes already says 2.95.3, which is working fine for me.

With this change, we no longer require that per-cpu data definitions be
initialised.  That was a workaround for a bug in older gccs.  So remove the
build infrastructure which was checking for that.

Also, mention that nfs-utils-1.0.3 is required.  It isn't required yet, but
will be once we enable larger dev_t: there is an interface for exportfs which
passes dev_t's into the kernel which breaks with larger dev_t.  That
interface is old, deprecated and is not used in nfs-utils-1.0.3.

The wait_on_buffer() debug code is generating false warnings when called from
__block_prepare_write().  It is legal to wait on a zero-ref buffer when its
page is locked.  The page lock keeps try_to_free_buffers() away.

This debug code hasn't found any bugs yet.

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

must never be dereferenced directly. Make that clear in the
attribute.

magic C promotion to silently do so for us.

was the first file tested with my type checker with the anal
pointer attribute checking turned on.

user space access functions. This allows the type checker
to check proper usage.

checking, these end up being no-ops, but they get enabled
by the type checker as special address_space attributes.

There is a stunning bug.

Previously, it was done automatically by the `reti' isntruction upon
returning from the kernel, but that doesn't do the correct thing in
various cases, for instance if there's a context switch, or a softirq.