Call mm_free_cgroup earlier.  Otherwise a reference due to lazy mm switching
can prevent cgroup removal.
Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Paul Menage <menage@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Discourage people from inappropriately using in_atomic()
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drivers/char/drm/ati_pcigart.c: In function 'drm_ati_pcigart_init':
drivers/char/drm/ati_pcigart.c:125: warning: format '%08X' expects type 'unsigned int', but argument 3 has type 'dma_addr_t'

Cc: Dave Airlie <airlied@linux.ie>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

This has been forgotten in commit f5bbdacc ("[MTD] NAND Modularize
read function") and nobody compiled the driver.
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joern Engel <joern@wh.fh-wedel.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

I believe http://bugzilla.kernel.org/show_bug.cgi?id=10318 is a false
positive.  There's no way in which networking will be using highmem pages
here, so it won't be taking the KM_USER0 kmap slot, so there's no point in
performing these checks.

Cc: Pawel Staszewski <pstaszewski@artcom.pl>
Cc: Ingo Molnar <mingo@elte.hu>
Acked-by: Christoph Lameter <clameter@sgi.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
 [ Really sad.  We lose almost all real-life coverage of the debug tests
   with this patch. Now it will only report problems for the cases where
   people actually end up using a HIGHMEM page, not when they just _might_
   use one.    - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Because of a typo in iwch_accept_cr(), the cxgb3 connection handling
code programs the hardware IRD (incoming RDMA read queue depth) with
the value that is passed in for the ORD (outgoing RDMA read queue
depth).  In particular this means that if an application passes in IRD
> 0 and ORD = 0 (which is a completely sane and valid thing to do for
an app that expects only incoming RDMA read requests), then the
hardware will end up programmed with IRD = 0 and the app will fail in
a mysterious way.

Fix this by using "ep->ird" instead of "ep->ord" in the intended place.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Acked-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
  [POWERPC] Fix missed hardware breakpoints across multiple threads

Revert commit 1192aeb9 ("ACPI:
drivers/acpi: elide a non-zero test on a result that is never 0")
because it turns out that thermal_cooling_device_register() does
actually return NULL if CONFIG_THERMAL is turned off (then the routine
turns into a dummy inline routine in the header files that returns NULL
unconditionally).

This was found with randconfig testing, causing a crash during bootup:

  initcall 0x78878534 ran for 13 msecs: acpi_button_init+0x0/0x51()
  Calling initcall 0x78878585: acpi_fan_init+0x0/0x2c()
  BUG: unable to handle kernel NULL pointer dereference at 00000000
  IP: [<782b8ad0>] acpi_fan_add+0x7d/0xfd
  *pde = 00000000
  Oops: 0000 [#1]
  Modules linked in:

  Pid: 1, comm: swapper Not tainted (2.6.25-rc7-sched-devel.git-x86-latest.git #14)
  EIP: 0060:[<782b8ad0>] EFLAGS: 00010246 CPU: 0
  EIP is at acpi_fan_add+0x7d/0xfd
  EAX: b787c718 EBX: b787c400 ECX: b782ceb4 EDX: 00000007
  ESI: 00000000 EDI: b787c6f4 EBP: b782cee0 ESP: b782cecc
   DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
  Process swapper (pid: 1, ti=b782c000 task=b7846000 task.ti=b782c000)
  Stack: b787c459 00000000 b787c400 78790888 b787c60c b782cef8 782b6fb8 ffffffda
         b787c60c 00000000 78790958 b782cf0c 783005d7 b787c60c 78790958 78790584
         b782cf1c 783007f6 b782cf28 00000000 b782cf40 782ffc4a 78790958 b794d558
  Call Trace:
   [<782b6fb8>] ? acpi_device_probe+0x3e/0xdb
   [<783005d7>] ? driver_probe_device+0x82/0xfc
   [<783007f6>] ? __driver_attach+0x3a/0x70
   [<782ffc4a>] ? bus_for_each_dev+0x3e/0x60
   [<7830048c>] ? driver_attach+0x14/0x16
   [<783007bc>] ? __driver_attach+0x0/0x70
   [<7830006a>] ? bus_add_driver+0x9d/0x1b0
   [<783008c3>] ? driver_register+0x47/0xa3
   [<7813db00>] ? timespec_to_ktime+0x9/0xc
   [<782b7331>] ? acpi_bus_register_driver+0x3a/0x3c
   [<78878592>] ? acpi_fan_init+0xd/0x2c
   [<78863656>] ? kernel_init+0xac/0x1f9
   [<788635aa>] ? kernel_init+0x0/0x1f9
   [<78114563>] ? kernel_thread_helper+0x7/0x10
   =======================
  Code: 6e 78 e8 57 44 e7 ff 58 e9 93 00 00 00 8b 55 f0 8d bb f4 02 00 00 80 4b 2d 10 8b 03 e8 87 cb ff ff 8d 83 18 03 00 00 80 63 2d ef <ff> 35 00 00 00 00 50 68 e8 9c 6e 78 e8 22 44 e7 ff b9 b6 9c 6e
  EIP: [<782b8ad0>] acpi_fan_add+0x7d/0xfd SS:ESP 0068:b782cecc
  ---[ end trace 778e504de7e3b1e3 ]---
  Kernel panic - not syncing: Attempted to kill init!
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

There is a bug in the powerpc DABR (data access breakpoint) handling,
which can result in us missing breakpoints if several threads are trying
to break on the same address.

The circumstances are that do_page_fault() calls do_dabr(), this clears
the DABR (sets it to 0) and sets up the signal which will report to
userspace that the DABR was hit. The do_signal() code will restore the DABR
value on the way out to userspace.

If we reschedule before calling do_signal(), __switch_to() will check the
cached DABR value and compare it to the new thread's value, if they match
we don't set the DABR in hardware.

So if two threads have the same DABR value, and we schedule from one to
the other after taking the interrupt for the first thread hitting the DABR,
the second thread will run without the DABR set in hardware.

The cleanest fix is to move the cache update into set_dabr(), that way we
can't forget to do it.
Reported-by: Jan Kratochvil <jan.kratochvil@redhat.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>

This reverts commit 3811dbf6.

The masking was not at all useless, and it was sensible.  We handle
GFP_ZERO in the caller, and passing it down to any page allocator logic
is buggy and wrong.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

* git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
  lguest: comment documentation update.
  lguest: Don't need comment terminator before disk section.
  lguest: lguest.txt documentation fix
  lguest: Add puppies which where previously missing.
  virtio_pci: unregister virtio device at device remove

Took some cycles to re-read the Lguest Journey end-to-end, fix some
rot and tighten some phrases.

Only comments change.  No new jokes, but a couple of recycled old jokes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Mention the config options for the Virtio drivers and move the Virtualization
menu to the toplevel.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

lguest doesn't have features, it has puppies!
Signed-off-by: Timothy R Ansell <mithro@mithis.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Make sure to call unregister_virtio_device() when a virtio device is removed.
Otherwise, virtio_pci.ko cannot be rmmod'd.

This was spotted by Marcelo Tosatti.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
  [POWERPC] update pasemi_defconfig

Linus noticed a second bug and an uncleanliness:

 - we'd return on any instruction fetch fault

 - we'd use both the value of 16 and the PF_INSTR symbol which are
   the same and make no sense

the cleanup nicely unifies this piece of logic.
Signed-off-by: Ingo Molnar <mingo@elte.hu>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
  xen: fix UP setup of shared_info
  xen: fix RMW when unmasking events
  x86, documentation: nmi_watchdog=2 works on x86_64
  x86: stricter check in follow_huge_addr()
  rdc321x: GPIO routines bugfixes
  x86: ptrace.c: fix defined-but-unused warnings
  x86: fix prefetch workaround

* 'avr32-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/avr32-2.6:
  avr32: Fix bug in early resource allocation code
  avr32: Build fix for CONFIG_BUG=n
  avr32: Work around byteswap bug in gcc < 4.2

We need to set up the shared_info pointer once we've mapped the real
shared_info into its fixmap slot.  That needs to happen once the general
pagetable setup has been done.  Previously, the UP shared_info was set
up one in xen_start_kernel, but that was left pointing to the dummy
shared info.  Unfortunately there's no really good place to do a later
setup of the shared_info in UP, so just do it once the pagetable setup
has been done.

[ Stable: needed in 2.6.24.x ]
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stable Kernel <stable@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

xen_irq_enable_direct and xen_sysexit were using "andw $0x00ff,
XEN_vcpu_info_pending(vcpu)" to unmask events and test for pending ones
in one instuction.

Unfortunately, the pending flag must be modified with a locked operation
since it can be set by another CPU, and the unlocked form of this
operation was causing the pending flag to get lost, allowing the processor
to return to usermode with pending events and ultimately deadlock.

The simple fix would be to make it a locked operation, but that's rather
costly and unnecessary.  The fix here is to split the mask-clearing and
pending-testing into two instructions; the interrupt window between
them is of no concern because either way pending or new events will
be processed.

This should fix lingering bugs in using direct vcpu structure access too.

[ Stable: needed in 2.6.24.x ]
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stable <stable@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

The first page of the compound page is determined in follow_huge_addr()
but then PageCompound() only checks if the page is part of a compound page.
PageHead() allows checking if this is indeed the first page of the
compound.

Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

This patch fixes the use of GPIO routines which are in the PCI
configuration space of the RDC321x, therefore reading/writing
to this space without spinlock protection can be problematic.

We also now request and free GPIOs and support the MGB100
board, previous code was very AR525W-centric.
Signed-off-by: Volker Weiss <volker@tintuc.de>
Signed-off-by: Florian Fainelli <florian.fainelli@telecomint.eu>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

arch/x86/kernel/ptrace.c:548: warning: 'ptrace_bts_get_size' defined but not used
arch/x86/kernel/ptrace.c:558: warning: 'ptrace_bts_read_record' defined but not used
arch/x86/kernel/ptrace.c:607: warning: 'ptrace_bts_clear' defined but not used
arch/x86/kernel/ptrace.c:617: warning: 'ptrace_bts_drain' defined but not used
arch/x86/kernel/ptrace.c:720: warning: 'ptrace_bts_config' defined but not used
arch/x86/kernel/ptrace.c:788: warning: 'ptrace_bts_status' defined but not used

Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

some early Athlon XP's and Opterons generate bogus faults on prefetch
instructions. The workaround for this regressed over .24 - reinstate it.
Signed-off-by: Ingo Molnar <mingo@elte.hu>

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
  ACPI: drivers/acpi: elide a non-zero test on a result that is never 0
  pnpacpi: reduce printk severity for "pnpacpi: exceeded the max number of ..."
  cpuidle: fix 100% C0 statistics regression
  cpuidle: fix cpuidle time and usage overflow
  ACPI: fix mis-merge -- invoke acpi_unlazy_tlb() only on C3 entry
  ACPI: fix a regression of ACPI device driver autoloading
  ACPI: SBS: remove typo from sbchc.c

The futex init function is called init(). This is a pain in the neck
when debugging when you code dies in ... init :-)

This renames it to futex_init().
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

add_reserved_region() tries to keep the resource list sorted, so when
looking for a place to insert the new resource, it may break out
before the last entry.

When this happens, the list is broken in two because the sibling field
of the new entry doesn't point to the next resource. Fix it by
updating the new resource's sibling field appropriately.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>

The function thermal_cooling_device_register always returns either a valid
pointer or a value made with ERR_PTR, so a test for non-zero on the result
will always succeed.

The problem was found using the following semantic match.
(http://www.emn.fr/x-info/coccinelle/)

//<smpl>
@a@
expression E, E1;
statement S,S1;
position p;
@@

E = thermal_cooling_device_register(...)
... when != E = E1
if@p (E) S else S1

@n@
position a.p;
expression E,E1;
statement S,S1;
@@

E = NULL
... when != E = E1
if@p (E) S else S1

@depends on !n@
expression E;
statement S,S1;
position a.p;
@@

* if@p (E)
  S else S1
//</smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (43 commits)
  [IPSEC]: Fix BEET output
  [ICMP]: Dst entry leak in icmp_send host re-lookup code (v2).
  [AX25]: Remove obsolete references to BKL from TODO file.
  [NET]: Fix multicast device ioctl checks
  [IRDA]: Store irnet_socket termios properly.
  [UML]: uml-net: don't set IFF_ALLMULTI in set_multicast_list
  [VLAN]: Don't copy ALLMULTI/PROMISC flags from underlying device
  netxen, phy/marvell, skge: minor checkpatch fixes
  S2io: Handle TX completions on the same CPU as the sender for MIS-X interrupts
  b44: Truncate PHY address
  skge napi->poll() locking bug
  rndis_host: fix oops when query for OID_GEN_PHYSICAL_MEDIUM fails
  cxgb3: Fix lockdep problems with sge.reg_lock
  ehea: Fix IPv6 support
  dm9000: Support promisc and all-multi modes
  dm9601: configure MAC to drop invalid (crc/length) packets
  dm9601: add Hirose USB-100 device ID
  Marvell PHY m88e1111 driver fix
  netxen: fix rx dropped stats
  netxen: remove low level tx lock
  ...

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
  [SPARC64]: Define TASK_SIZE_OF()
  [SPARC64]: flush_ptrace_access() needs preemption disable.
  [SPARC64]: Update defconfig.
  [SPARC64]: Fix allnoconfig build, ptrace.c missing CONFIG_COMPAT checks.
  [SPARC64]: Fix __get_cpu_var in preemption-enabled area.
  [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/signal.c
  [SPARC64]: Fix most sparse warnings in arch/sparc64/kernel/sys_sparc.c
  [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/time.c
  [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/ptrace.c
  [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/irq.c
  [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/iommu.c
  [SPARC64]: Fix sparse errors in arch/sparc64/kernel/traps.c
  [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/{cpu,setup}.c
  [SPARC64]: Adjust {TLBTEMP,TSBMAP}_BASE.
  [SPARC64]: Make save_stack_trace() more efficient.

This make "cat /proc/${PID}/pagemap" more efficient for
32-bit tasks.

Based upon a report by Mariusz Kozlowski.
Signed-off-by: David S. Miller <davem@davemloft.net>

The IPv6 BEET output function is incorrectly including the inner
header in the payload to be protected.  This causes a crash as
the packet doesn't actually have that many bytes for a second
header.

The IPv4 BEET output on the other hand is broken when it comes
to handling an inner IPv6 header since it always assumes an
inner IPv4 header.

This patch fixes both by making sure that neither BEET output
function touches the inner header at all.  All access is now
done through the protocol-independent cb structure.  Two new
attributes are added to make this work, the IP header length
and the IPv4 option length.  They're filled in by the inner
mode's output function.

Thanks to Joakim Koskela for finding this problem.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
  x86: fix performance drop for glx
  x86: fix trim mtrr not to setup_memory two times
  x86: GEODE: add missing module.h include
  x86, cpufreq: fix Speedfreq-SMI call that clobbers ECX
  x86: fix memoryless node oops during boot
  x86: add dmi quirk for io_delay
  x86: convert mtrr/generic.c to kernel-doc
  x86: Documentation/i386/IO-APIC.txt: fix description

Running the counters testcase from libhugetlbfs results in on 2.6.25-rc5
and 2.6.25-rc5-mm1:

    BUG: soft lockup - CPU#3 stuck for 61s! [counters:10531]
    NIP: c0000000000d1f3c LR: c0000000000d1f2c CTR: c0000000001b5088
    REGS: c000005db12cb360 TRAP: 0901   Not tainted  (2.6.25-rc5-autokern1)
    MSR: 8000000000009032 <EE,ME,IR,DR>  CR: 48008448  XER: 20000000
    TASK = c000005dbf3d6000[10531] 'counters' THREAD: c000005db12c8000 CPU: 3
    GPR00: 0000000000000004 c000005db12cb5e0 c000000000879228 0000000000000004
    GPR04: 0000000000000010 0000000000000000 0000000000200200 0000000000100100
    GPR08: c0000000008aba10 000000000000ffff 0000000000000004 0000000000000000
    GPR12: 0000000028000442 c000000000770080
    NIP [c0000000000d1f3c] .return_unused_surplus_pages+0x84/0x18c
    LR [c0000000000d1f2c] .return_unused_surplus_pages+0x74/0x18c
    Call Trace:
    [c000005db12cb5e0] [c000005db12cb670] 0xc000005db12cb670 (unreliable)
    [c000005db12cb670] [c0000000000d24c4] .hugetlb_acct_memory+0x2e0/0x354
    [c000005db12cb740] [c0000000001b5048] .truncate_hugepages+0x1d4/0x214
    [c000005db12cb890] [c0000000001b50a4] .hugetlbfs_delete_inode+0x1c/0x3c
    [c000005db12cb920] [c000000000103fd8] .generic_delete_inode+0xf8/0x1c0
    [c000005db12cb9b0] [c0000000001b5100] .hugetlbfs_drop_inode+0x3c/0x24c
    [c000005db12cba50] [c00000000010287c] .iput+0xdc/0xf8
    [c000005db12cbad0] [c0000000000fee54] .dentry_iput+0x12c/0x194
    [c000005db12cbb60] [c0000000000ff050] .d_kill+0x6c/0xa4
    [c000005db12cbbf0] [c0000000000ffb74] .dput+0x18c/0x1b0
    [c000005db12cbc70] [c0000000000e9e98] .__fput+0x1a4/0x1e8
    [c000005db12cbd10] [c0000000000e61ec] .filp_close+0xb8/0xe0
    [c000005db12cbda0] [c0000000000e62d0] .sys_close+0xbc/0x134
    [c000005db12cbe30] [c00000000000872c] syscall_exit+0x0/0x40
    Instruction dump:
    ebbe8038 38800010 e8bf0002 3bbd0008 7fa3eb78 38a50001 7ca507b4 4818df25
    60000000 38800010 38a00000 7c601b78 <7fa3eb78> 2f800010 409d0008 38000010

This was tracked down to a potential livelock in
return_unused_surplus_hugepages().  In the case where we have surplus
pages on some node, but no free pages on the same node, we may never
break out of the loop. To avoid this livelock, terminate the search if
we iterate a number of times equal to the number of online nodes without
freeing a page.

Thanks to Andy Whitcroft and Adam Litke for helping with debugging and
the patch.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Currently we show the surplus hugetlb pool state in /proc/meminfo, but
not in the per-node meminfo files, even though we track the information
on a per-node basis. Printing it there can help track down dynamic pool
bugs including the one in the follow-on patch.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>