There is currently no clean and efficient way to apply mprotect to all of a
program's stack, i.e. to the moving edge of a GROWSDOWN or GROWSUP mapping.
Some processes want to change these protections, particularly to set or
clear the PROT_EXEC bits on stack space.  As it is, an mprotect done to
cover the precise edge page of the mapping will have the desired effect of
changing the protection for existing pages and having that new protection
carried over to new pages grown later.  But there is no very reasonable way
of ascertaining where the edge of the mapping is if it might have grown in
the past beyond the usage at the moment.  An mprotect call that doesn't
cover the edge page splits the mapping and doesn't do what we need.

This patch adds flags that can be OR'd into the protection bits in an
mprotect system call.  PROT_GROWSDOWN means the memory lies in a GROWSDOWN
mapping and the start address of the region to be changed should be
extended down to the current low page of that mapping.  Similarly,
PROT_GROWSUP means the pages lie in a GROWSUP mapping and the length of the
region to be changed should be extended up to include its highest page.
These flags also explicitly request the (already implicit) behavior that
the protection change applied to the lowest/highest page of a growing
mapping is passed on to new pages grown later.  There are no other changes
to the mprotect behavior; in particular, the boundary in the non-growing
direction (the end address computed from the start+len arguments in the
GROWSDOWN case, and the start argument in the GROWSUP case) is as given by
the arguments to the system call.  This is desireable in the use of this
call by a process on its stack, so it can change the protections of the
growing mapping used for program stack distinctly from the protections on
the arguments, environment, and AT_* data from exec.

glibc assumes that the padding in statvfs() is zeroed. Do this
in the compat layer too for future safety.

Minor changes to Jamie & Hugh's excellent futex patch.
 1) Remove obsolete comment above hash array decl.
 2) Clarify comment about TASK_INTERRUPTIBLE.
 3) Andrew Morton says spurious wakeup is a bug.  Catch it.
 4) Use Jenkins hash.
 5) Make hash function non-inline.

From: "Hu, Boris" <boris.hu@intel.com>

Andrew reminded me of this.

Simple change to split the futex lock into a per-hashchain lock.
Don't bother cacheline aligning: Jamie points out that increasing
FUTEX_HASHBITS would have more payoff.

Ulrich Drepper reports 6% improvement in on a 4way futex-thrashing
benchmark.

Kconfig cleanup megapatch from Nicolas Kaiser <nikai@nikai.net>.

modules.txt no longer exists, and the common wording used to refer to
it sucks.  This is all by Nicolas Kaiser's: at Randy and Matthew's
request, "say M" changed to "choose M" (more sense for graphical front
ends, too).

check that the brk value lies in bounds.

This cleans up the PCI vs AGP GART handling, and turning the
PCI GART hardware on and off.

flush after vmap.

The current seq_file code for resource handling will truncate the output
if it overflows the seq_file buffer (one page).  That's because it tries
to traverse the resource tree in one big blob.

So change that to instead traverse the resource tree one entry at a time
and have a real iterator, and clean it up a bit.

sanity-checking the information more carefully. 

The old code basically just used a random-number approach
to determine how much to read.

This fixes a NULL ptr dereference in md_probe() noted by Helge Hafting.

It even gets the things slightly better than they used to be, but
late-boot magic in md.c is certainly a mess.  Oh, well...

It's _ugly_.  md_probe() is misused there big way.  The minimal fix is
to revert the cleanup in md_probe() - replace

	int unit = *part;
with
	int unit = MINOR(dev);


However, that is crap solution.  The problem is that md_probe() is called
directly with bogus arguments - not only part is NULL (which triggers the
oops), but dev (which is supposed to be dev_t value) is actually mdidx(mddev).

Cleaner fix follows, but we really need to get the situation with gendisk
allocations into the sane shape there.  Sigh...

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

into cantab.net:/home/aia21/ntfs-2.6

	Fix for typo in arch/mips/kernel/sysirix.c (spotted by Milton Miller)

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

I believe that the patch below fixes the legitimate leaks in the SELinux
code.  In some cases, it rearranges the code (moving the allocation later
to reduce the need for further cleanup or linking the object into a
containing structure earlier so that the policydb_destroy will handle it
upon any subsequent errors).

From: Christoph Hellwig <hch@lst.de>

Still three arches keep an unused copy around and quite a few places refer
to it in comments still.

Two of the two arches also include it in their _ksyms.c file, but given
that softirq.h only contains macros (which are in hardirq.c as well) that's
just a leftover as well.

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

Use common (normalized) asm syntax for lidt/lgdt, specifying that the
operand is an input value instead of output.

From: Krzysztof Halasa <khc@pm.waw.pl>

Fix wanxl for older gcc's, and fix a couple of warnings.

From: Dave Olien <dmo@osdl.org>

this patch fixes a bug that appeared only on Alpha hardware with
DAC960 controllers.  The Command->PciDevice structure member was
never initialized.  This was passed to the pci scatter/gather functions.
This didn't cause a problem for x86 platforms because the scatter/gather
funtions never really used that information.  Alpha platforms do use
that pointer.

The Command->PciDevice field was also redundant with the Controller->PCIDevice
field, which IS initialized properly.  So, eliminating the redundant
structure member and substituting the Controller's member fixes the bug.

From: Adrian Bunk <bunk@fs.tum.de>

CONFIG_SERIAL_21285_OLD depends on the non-existent option CONFIG_OBSOLETE,
IOW it's not selectable, and the help text says "This is obsolete and will
be removed during later 2.5 development.".

From: Andries.Brouwer@cwi.nl

jpcartal@free.fr writes:

	I noticed that contrary to what was happening with 2.4.x kernel, suid
	root files don't loose their suid bit when they get overwritten by a
	normal user (see example below)

	Is this the intended behaviour or a bug ?

	Example :

	[root@localhost test]# chown root ~cartaljp/test/suid_test
	[root@localhost test]# chmod 4775 ~cartaljp/test/suid_test
	[root@localhost test]# exit
	[cartaljp@localhost test]$ cp /bin/ls suid_test
	[cartaljp@localhost test]$ ls -l
	total 72
	-rwsrwxr-x    1 root     cartaljp    67668 Sep 19 07:56 suid_test <-
	Suid bit is still set whereas with 2.4.x kernel it was reset.

Yes. Here 2.4 had the terrible code

     mode = (inode->i_mode & S_IXGRP)*(S_ISGID/S_IXGRP) | S_ISUID;

while 2.6 does things via notify_change().  However, in 2.6 notify_change()
does not allow removal of the SUID bit because you are not owner of the
file :-).  So, we have to convince inode_change_ok() to do it anyway.

At present you can set CONFIG_HUGETLB_PAGE and not CONFIG_HUGETLBFS, which
give the kernel low-level hugepage support, but no userspace API with which
to access it.

And with the recent hugetlbfs-accounting fix, the low-level code needs
functions which are in hugetlbfs, so CONFIG_HUGETLBFS=n,
CONFIG_HUGETLB_PAGE=y doesn't even link.

So we flip things around: CONFIG_HUGETLB_PAGE is set if CONFIG_HUGETLBFS is
set and CONFIG_HUGETLB_PAGE is unset if CONFIG_HUGETLBFS is unset.  The
CONFIG_HUGETLB_PAGE option hence disappears from the per-arch configuration
menus.

From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>

We found a problem in hugetlbfs file system quota when using huge page
via mmap.  The mmap method in hugetlbfs_file_operation always takes
quota for every mmap even for pages that are already allocated on that
inode.  This results in taxing the same hugepage multiple times and
causing mmap to fail on existing file when quota mistakenly runs out.

- modules need blk_rq_prep_restart()  (Florian Schanda <ma1flfs@bath.ac.uk>)

- Remove unneeded inclusions from configs.c (Randy Dunlap)

- The agp_setup() ifdef was backwards (Stephen Hemminger <shemminger@osdl.org>)

- makefiles.txt typo fix (Paolo Ornati <ornati@despammed.com>)

From: Christoph Hellwig <hch@lst.de>

All drivers that compile on ppc with CONFIG_ISA set (= all but
some m68-only drivers), I looked at the compile warnings very
closely and there are no new warnings or even errors this time :)

drivers/char/Makefile needed to be reordered big time to keep
the intialization order the same.

From: Ethan Benson <erbenson@alaska.net>

Currently Linux allows the use of the utime() and utimes() syscalls on
immutable or append-only files, this is incorrect.

utime{s}() is not supposed to work if you lack write access to a file,
in the case of an immutable file NOBODY has write access.

for an append-only file it only makes sense to be able to update its
time to present, not the past.

I have checked BSD, and they implement the behavior I propose, for
immutable files utime() and utimes() fail.  for append-only files they
fail if the time argument is not NULL.

From: John Levon <levon@movementarian.org>

Not that many people are going to be using GCC 3.4 currently, but it
might help a bit to prevent compilation bugs like that just witnessed
in procfs.

(And it consolidates the check_gcc implementation nicely)

From: Christoph Hellwig <hch@lst.de>

Some junk which was needed before we did the big cleansweep for the sysrq
syncing stuff.

From: Christoph Hellwig <hch@lst.de>

Richard hasn't touched it for about a year and since then only bugfixes and
my changes to the kernel interface went in.  No one has stepped up to
maintain it and with udev we have a proper replacement now.

I will do some more work before 2.6 (mainly trying to implement Al's
refcounting scheme to avoid stale entries), but that's it.

From: "David S. Miller" <davem@redhat.com>

It's from Ingo Molnar.  ksoftirqd kicks in way too early, so do more work in
interrupt context before falling back.

We can probably sysctl this thing, that way everyone gets what they want
probably...

(has been in -mm since 2.5.71 and I haven't heard a peep).

From: Manfred Spraul <manfred@colorfullife.com>

- Remove cache_alloc_one_tail and cache_alloc_listfixup - there is no
  reason for their existance.

- Print a bit more debugging info when slab corruption is detected.

	Argh.  A couple of places where we needed ..._encode_dev() had
been lost in reordering the patchset - the most notable being ctty number in
/proc/<pid>/stat.  Fix follows:

into cantab.net:/home/aia21/ntfs-2.6

This fixes several things including fixing the character ioctl polling
to use wait_event_interruptible_timeout() instead of
interruptible_sleep_on_timeout() and several other fixes.

These changes were already applied to 2.4.22.

Necessary due to company name change.

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

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