If someone runs page_address() before page_address_init(), the kernel locks
up over uninitialised spinlocks.

This only happens with the 4:4 patch, but it is more robust to run
page_address_init() before setup_arch().  page_address_init() simply
initialises statically allocated storage.

From: Chris Mason <mason@suse.com>

I think Andrew and I managed to mismerge the loop setup race fix. 
loop_set_fd is using get_capacity() to read the size of the disk and
sending that to bd_set_size.

But, it is doing this before calling set_capacity, so the size being used
is wrong.  This should clean things up.

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

Below is a warmed up version of a patch originally done by Werner Almesberger
(see http://tinyurl.com/25zra) to replace the MAX_MAP_COUNT limit with a
sysctl variable.  I thought this had gone into the tree a long time ago but
alas it has not and as luck would have it, the hard limit bit someone today
once again with a large app on a large machine.

Here is a small test app:

Spotted by Andrea: we need the barriers in there to prevent reads passing
ahead of the setting of current->state.

All architectures now make this `long', so we can remove the arch override.

From: Andy Whitcroft <apw@shadowen.org>

Two problems:

a) The memory overcommit code fails oto take into account all the pages
   which are pinned by being reserved for the hugetlbpage pool

b) We're performing overcommit accounting and checking on behalf of
   hugetlbpage vmas.

The main thrust is to ensure that VM_ACCOUNT actually only gets set on
vma's which are indeed accountable.  With that ensured much of the rest
comes out in the wash.  It also removes the hugetlb memory for the
overcommit_memory=2 case.

From: Marcus Meissner <meissner@suse.de>

After discussion on the glibc list the result was that=20 si_band is "long
int" according to POSIX:

	http://www.opengroup.org/onlinepubs/007904975/basedefs/signal.h.html

Ulrich Drepper refused a patch to fix glibc due to this reason:
	http://sources.redhat.com/ml/libc-alpha/2004-03/msg00254.html

so here is the patch to fix it in the kernel.

ppc64 and s390x were broken before and are fixed by this patch too.

From: David Gibson <david@gibson.dropbear.id.au>

This patch adds a debugging message to the ppc64 hugepage code when we
attempt to open the "low" (32-bit) hugepage window on PPC64, but can't
because a (non-hugepage) mapping already exists in the region.

From: David Gibson <david@gibson.dropbear.id.au>

On PowerPC64 the "low" hugepage range (at 2-3G for use by 32-bit processes)
needs to be activated before it can be used.  hugetlb_get_unmapped_area()
automatically activates the range for hugepage mappings in 32-bit processes
which are not MAP_FIXED.  However for MAP_FIXED mmap()s, even at a suitable
address will fail if the region is not already activated, because there is
no suitable callback from the generic MAP_FIXED code path into the arch
code.

This patch corrects this problem and allows PPC64 to do MAP_FIXED hugepage
mappings in the low hugepage range.

From: David Gibson <david@gibson.dropbear.id.au>

Due to a misunderstanding of pmd_offset() the PPC64 hugepage code could end
up looking at bogus pages as if they were PMD pages.

From: Anton Blanchard <anton@samba.org>

From: Stephen Rothwell <sfr@canb.auug.org.au>

This creates DMA_ERROR_CODE and uses it everywhere instead of
PCI_DMA_ERROR_CODE as we really want the three DMA mapping API's to return
a single error code.  Also we now have dma_mapping_error and
vio_dma_mapping_error - and this latter and pci_dma_mapping_error both just
call the former.

Also a small fix in the vscsi - dma_map_sg returns 0 to indicate an error.

From: Matt Porter <mporter@kernel.crashing.org>

This fixes the build on non cache coherent PPC32 platforms.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into austin.ibm.com:/shaggy/bk/jfs-2.5

into kernel.bkbits.net:/home/davem/net-2.6

into ppc970.osdl.org:/home/torvalds/v2.6/linux

estimate.  We must add in for the worst case of a log stripe taking us the
full distance for a log stripe boundary.

SGI Modid: xfs-linux:xfs-kern:169304a

SGI Modid: xfs-linux:xfs-kern:169300a

SGI Modid: xfs-linux:xfs-kern:169208a

else we panic.

SGI Modid: xfs-linux:xfs-kern:169200a

SGI Modid: xfs-linux:xfs-kern:169199a

SGI Modid: xfs-linux:xfs-kern:169135a

SGI Modid: xfs-linux:xfs-kern:169048a

SGI Modid: xfs-linux:xfs-kern:169038a

SGI Modid: xfs-linux:xfs-kern:168809a

SGI Modid: xfs-linux:xfs-kern:168693a

feature bit in sb_versionnum to use to indicate that the new feature bit
field is to be used.

SGI Modid: xfs-linux:xfs-kern:168665a

Add XFS_ALLOCFREE_LOG_RES to IFREE log reservation.

SGI Modid: xfs-linux:xfs-kern:168597a

SGI Modid: xfs-linux:xfs-kern:168167a

previously saved FSTRANS state.  Otherwise we can lose process flags.

SGI Modid: xfs-linux:xfs-kern:168082a

take the iolock here, and readers no longer conflict with concurrent
fsync activity.  Kudos to Steve!

SGI Modid: xfs-linux:xfs-kern:167949a

SGI Modid: xfs-linux:xfs-kern:167944a

People need the global wake events even when not sleeping:
they are used for lid open events at least on some laptops.
As such, they should be enabled by default.

You can disable them with "acpi_leave_gpes_disabled" if
your machine doesn't need them, and you want to get a few
less GPE's.

Spotted by Suparna: if the first range check fails, we leak a ref on the io
context.

Currently, to be able to send a reset in the FORWARD chain of iptables
for bridged traffic, ip forwarding must be enabled. This causes confusion
and in some situations people really don't want to enable ip forwarding.
The patch below lets the user send reset packets for bridged frames in
the FORWARD chain, with ip forwarding disabled (as long as there is a
route).