acpi_memhotplug.c: fix memory leak when memory device is unbound from the module acpi_memhotplug

We allocate memory to store acpi_memory_info, so we should free it before
freeing mem_device.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Cc: Len Brown <lenb@kernel.org>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: Yasuaki ISIMATU <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

x86 cpu_hotplug: unmap cpu2node when the cpu is hotremoved

When a cpu is hotplugged, we call acpi_map_cpu2node() in
_acpi_map_lsapic() to store the cpu's node.  But we don't clear the cpu's
node in acpi_unmap_lsapic() when this cpu is hotremoved.  If the node is
also hotremoved, We will get the following messages:

[ 1646.771485] kernel BUG at include/linux/gfp.h:329!
[ 1646.828729] invalid opcode: 0000 [#1] SMP
[ 1646.877872] Modules linked in: ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge stp llc sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel microcode pcspkr i2c_i801 i2c_core lpc_ich mfd_core ioatdma e1000e i7core_edac edac_core sg acpi_memhotplug igb dca sd_mod crc_t10dif megaraid_sas mptsas mptscsih mptbase scsi_transport_sas scsi_mod
[ 1647.588773] Pid: 3126, comm: init Not tainted 3.6.0-rc3-tangchen-hostbridge+ #13 FUJITSU-SV PRIMEQUEST 1800E/SB
[ 1647.711545] RIP: 0010:[<ffffffff811bc3fd>]  [<ffffffff811bc3fd>] allocate_slab+0x28d/0x300
[ 1647.810492] RSP: 0018:ffff88078a049cf8  EFLAGS: 00010246
[ 1647.874028] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
[ 1647.959339] RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000246
[ 1648.044659] RBP: ffff88078a049d38 R08: 00000000000040d0 R09: 0000000000000001
[ 1648.129953] R10: 0000000000000000 R11: 0000000000000b5f R12: 00000000000052d0
[ 1648.215259] R13: ffff8807c1417300 R14: 0000000000030038 R15: 0000000000000003
[ 1648.300572] FS:  00007fa9b1b44700(0000) GS:ffff8807c3800000(0000) knlGS:0000000000000000
[ 1648.397272] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1648.465985] CR2: 00007fa9b09acca0 CR3: 000000078b855000 CR4: 00000000000007e0
[ 1648.551265] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1648.636565] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1648.721838] Process init (pid: 3126, threadinfo ffff88078a048000, task ffff8807bb6f2650)
[ 1648.818534] Stack:
[ 1648.842548]  ffff8807c39d7fa0 ffffffff000040d0 00000000000000bb 00000000000080d0
[ 1648.931469]  ffff8807c1417300 ffff8807c39d7fa0 ffff8807c1417300 0000000000000001
[ 1649.020410]  ffff88078a049d88 ffffffff811bc4a0 ffff8807c1410c80 0000000000000000
[ 1649.109464] Call Trace:
[ 1649.138713]  [<ffffffff811bc4a0>] new_slab+0x30/0x1b0
[ 1649.199075]  [<ffffffff811bc978>] __slab_alloc+0x358/0x4c0
[ 1649.264683]  [<ffffffff810b71c0>] ? alloc_fair_sched_group+0xd0/0x1b0
[ 1649.341695]  [<ffffffff811be7d4>] kmem_cache_alloc_node_trace+0xb4/0x1e0
[ 1649.421824]  [<ffffffff8109d188>] ? hrtimer_init+0x48/0x100
[ 1649.488414]  [<ffffffff810b71c0>] ? alloc_fair_sched_group+0xd0/0x1b0
[ 1649.565402]  [<ffffffff810b71c0>] alloc_fair_sched_group+0xd0/0x1b0
[ 1649.640297]  [<ffffffff810a8bce>] sched_create_group+0x3e/0x110
[ 1649.711040]  [<ffffffff810bdbcd>] sched_autogroup_create_attach+0x4d/0x180
[ 1649.793260]  [<ffffffff81089614>] sys_setsid+0xd4/0xf0
[ 1649.854694]  [<ffffffff8167a029>] system_call_fastpath+0x16/0x1b
[ 1649.926483] Code: 89 c4 e9 73 fe ff ff 31 c0 89 de 48 c7 c7 45 de 9e 81 44 89 45 c8 e8 22 05 4b 00 85 db 44 8b 45 c8 0f 89 4f ff ff ff 0f 0b eb fe <0f> 0b 90 eb fd 0f 0b eb fe 89 de 48 c7 c7 45 de 9e 81 31 c0 44
[ 1650.161454] RIP  [<ffffffff811bc3fd>] allocate_slab+0x28d/0x300
[ 1650.232348]  RSP <ffff88078a049cf8>
[ 1650.274029] ---[ end trace adf84c90f3fea3e5 ]---

The reason is that: the cpu's node is not NUMA_NO_NODE, we will call
alloc_pages_exact_node() to alloc memory on the node, but the node is
offlined.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

vfs: d_obtain_alias() needs to use "/" as default name.

NFS appears to use d_obtain_alias() to create the root dentry rather than
d_make_root.  This can cause 'prepend_path()' to complain that the root
has a weird name if an NFS filesystem is lazily unmounted.  e.g.  if
"/mnt" is an NFS mount then

 { cd /mnt; umount -l /mnt ; ls -l /proc/self/cwd; }

will cause a WARN message like
   WARNING: at /home/git/linux/fs/dcache.c:2624 prepend_path+0x1d7/0x1e0()
   ...
   Root dentry has weird name <>

to appear in kernel logs.

So change d_obtain_alias() to use "/" rather than "" as the anonymous
name.

Signed-off-by: NeilBrown <neilb@suse.de>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

selinux: fix sel_netnode_insert() suspicious rcu dereference

===============================
[ INFO: suspicious RCU usage. ]
3.5.0-rc1+ #63 Not tainted
-------------------------------
security/selinux/netnode.c:178 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
1 lock held by trinity-child1/8750:
 #0:  (sel_netnode_lock){+.....}, at: [<ffffffff812d8f8a>] sel_netnode_sid+0x16a/0x3e0

stack backtrace:
Pid: 8750, comm: trinity-child1 Not tainted 3.5.0-rc1+ #63
Call Trace:
 [<ffffffff810cec2d>] lockdep_rcu_suspicious+0xfd/0x130
 [<ffffffff812d91d1>] sel_netnode_sid+0x3b1/0x3e0
 [<ffffffff812d8e20>] ? sel_netnode_find+0x1a0/0x1a0
 [<ffffffff812d24a6>] selinux_socket_bind+0xf6/0x2c0
 [<ffffffff810cd1dd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff810cdb55>] ? lock_release_holdtime.part.9+0x15/0x1a0
 [<ffffffff81093841>] ? lock_hrtimer_base+0x31/0x60
 [<ffffffff812c9536>] security_socket_bind+0x16/0x20
 [<ffffffff815550ca>] sys_bind+0x7a/0x100
 [<ffffffff816c03d5>] ? sysret_check+0x22/0x5d
 [<ffffffff810d392d>] ? trace_hardirqs_on_caller+0x10d/0x1a0
 [<ffffffff8133b09e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff816c03a9>] system_call_fastpath+0x16/0x1b

This patch below does what Paul McKenney suggested in the previous thread.

Signed-off-by: Dave Jones <davej@redhat.com>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Paul Moore <paul@paul-moore.com>
Cc: Eric Paris <eparis@parisplace.org>
Cc: James Morris <jmorris@namei.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

drivers/scsi/ipr.c: missing unlock before a return

We recently changed the locking in this function, but this return was
missed.  It needs an unlock and the IRQs need to be restored.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Brian King <brking@linux.vnet.ibm.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

CRIS: Fix I/O macros

The inb/outb macros for CRIS are broken from a number of points of view,
missing () around parameters and they have an unprotected if statement in
them.  This was breaking the compile of IPMI on CRIS and thus I was being
annoyed by build regressions, so I fixed them.

Plus I don't think they would have worked at all, since the data values
were missing "&" and the outsl had a "3" instead of a "4" for the size.
From what I can tell, this stuff is not used at all, so this can't be any
more broken than it was before, anyway.

Signed-off-by: Corey Minyard <cminyard@mvista.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Mikael Starvik <starvik@axis.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

compiler.h: add __visible

gcc 4.6+ has support for a externally_visible attribute that prevents the
optimizer from optimizing unused symbols away.  Add a __visible macro to
use it with that compiler version or later.

This is used (at least) by the "Link Time Optimization" patchset.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

pid-namespace: limit value of ns_last_pid to (0, max_pid)

The kernel doesn't check the pid for negative values, so if you try to
write -2 to /proc/sys/kernel/ns_last_pid, you will get a kernel panic.

The crash happens because the next pid is -1, and alloc_pidmap() will try
to access to a nonexistent pidmap.

map = &pid_ns->pidmap[pid/BITS_PER_PAGE];

Signed-off-by: Andrew Vagin <avagin@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

include/net/sock.h: squelch compiler warning in sk_rmem_schedule()

In file included from linux/include/linux/tcp.h:227:0,
                 from linux/include/linux/ipv6.h:221,
                 from linux/include/net/ipv6.h:16,
                 from linux/include/linux/sunrpc/clnt.h:26,
                 from linux/net/sunrpc/stats.c:22:
linux/include/net/sock.h: In function `sk_rmem_schedule':
linux/nfs-2.6/include/net/sock.h:1339:13: warning: comparison between
  signed and unsigned integer expressions [-Wsign-compare]

Seen with gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2) using the
-Wextra option.

c76562b6 ("netvm: prevent a stream-specific deadlock") accidentally
replaced the "size" parameter of sk_rmem_schedule() with an unsigned int.
This changes the semantics of the comparison in the return statement.

In sk_wmem_schedule we have syntactically the same comparison, but "size"
is a signed integer.  In addition, __sk_mem_schedule() takes a signed
integer for its "size" parameter, so there is an implicit type conversion
in sk_rmem_schedule() anyway.

Revert the "size" parameter back to a signed integer so that the semantics
of the expressions in both sk_[rw]mem_schedule() are exactly the same.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Cc: David Miller <davem@davemloft.net>
Cc: Joonsoo Kim <js1304@gmail.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

slub: consider pfmemalloc_match() in get_partial_node()

get_partial() is currently not checking pfmemalloc_match() meaning that it
is possible for pfmemalloc pages to leak to non-pfmemalloc users.  This is
a problem in the following situation.  Assume that there is a request from
normal allocation and there are no objects in the per-cpu cache and no
node-partial slab.

In this case, slab_alloc enters the slow path and new_slab_objects() is
called which may return a PFMEMALLOC page.  As the current user is not
allowed to access PFMEMALLOC page, deactivate_slab() is called ([5091b74a:
mm: slub: optimise the SLUB fast path to avoid pfmemalloc checks]) and
returns an object from PFMEMALLOC page.

Next time, when we get another request from normal allocation,
slab_alloc() enters the slow-path and calls new_slab_objects().  In
new_slab_objects(), we call get_partial() and get a partial slab which was
just deactivated but is a pfmemalloc page.  We extract one object from it
and re-deactivate.

"deactivate -> re-get in get_partial -> re-deactivate" occures repeatedly.

As a result, access to PFMEMALLOC page is not properly restricted and it
can cause a performance degradation due to frequent deactivation.
deactivation frequently.

This patch changes get_partial_node() to take pfmemalloc_match() into
account and prevents the "deactivate -> re-get in get_partial() scenario.
Instead, new_slab() is called.

Signed-off-by: Joonsoo Kim <js1304@gmail.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Cc: David Miller <davem@davemloft.net>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

slab: fix starting index for finding another object

In array cache, there is a object at index 0, check it.

Signed-off-by: Joonsoo Kim <js1304@gmail.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Cc: David Miller <davem@davemloft.net>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

slab: do ClearSlabPfmemalloc() for all pages of slab

Right now, we call ClearSlabPfmemalloc() for first page of slab when we
clear SlabPfmemalloc flag.  This is fine for most swap-over-network use
cases as it is expected that order-0 pages are in use.  Unfortunately it
is possible that that __ac_put_obj() checks SlabPfmemalloc on a tail page
and while this is harmless, it is sloppy.  This patch ensures that the
head page is always used.

This problem was originally identified by Joonsoo Kim.

[js1304@gmail.com: Original implementation and problem identification]
Signed-off-by: Mel Gorman <mgorman@suse.de>
Cc: David Miller <davem@davemloft.net>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Joonsoo Kim <js1304@gmail.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

nbd: clear waiting_queue on shutdown

Fix a serious but uncommon bug in nbd which occurs when there is heavy I/O
going to the nbd device while, at the same time, a failure (server,
network) or manual disconnect of the nbd connection occurs.

There is a small window between the time that the nbd_thread is stopped
and the socket is shutdown where requests can continue to be queued to
nbd's internal waiting_queue.  When this happens, those requests are never
completed or freed.

The fix is to clear the waiting_queue on shutdown of the nbd device, in
the same way that the nbd request queue (queue_head) is already being cleared.

Signed-off-by: Paul Clements <paul.clements@steeleye.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

MAINTAINERS: fix TXT maintainer list and source repo path

Signed-off-by: Gang Wei <gang.wei@intel.com>
Cc: Richard L Maliszewski <richard.l.maliszewski@intel.com>
Cc: Gang Wei <gang.wei@intel.com>
Cc: Shane Wang <shane.wang@intel.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

mm/ia64: fix a memory block size bug

I found following definition in include/linux/memory.h, in my IA64
platform, SECTION_SIZE_BITS is equal to 32, and MIN_MEMORY_BLOCK_SIZE will
be 0.

#define MIN_MEMORY_BLOCK_SIZE     (1 << SECTION_SIZE_BITS)

will equal to 0.  This will cause wrong system memory infomation in sysfs.
 I think it should be:

#define MIN_MEMORY_BLOCK_SIZE     (1UL << SECTION_SIZE_BITS)

linux-drf:/sys/devices/system/memory # ll
total 0
-r--r--r-- 1 root root 65536 Aug 20 02:35 block_size_bytes
drwxr-xr-x 3 root root     0 Aug 20 02:19 memory0
drwxr-xr-x 2 root root     0 Aug 20 02:35 power
-rw-r--r-- 1 root root 65536 Aug 20 02:35 uevent

linux-drf:/sys/devices/system/memory # cat block_size_bytes
0

linux-drf:/sys/devices/system/memory/memory0 # cat *
8000000000000000
cat: node0: Is a directory
cat: node1: Is a directory
cat: node2: Is a directory
cat: node3: Is a directory
0
8000000000000000
cat: power: Is a directory
1
online
cat: subsystem: Is a directory

And "echo offline > memory0/state" will cause following call trace:

kernel BUG at mm/memory_hotplug.c:885!
sh[6455]: bugcheck! 0 [1]

Pid: 6455, CPU 0, comm:                   sh
psr : 0000101008526030 ifs : 8000000000000fa4 ip  : [<a0000001008c40f0>]    Not tainted (3.6.0-rc1)
ip is at offline_pages+0x210/0xee0
unat: 0000000000000000 pfs : 0000000000000fa4 rsc : 0000000000000003
rnat: a0000001008f2d50 bsps: 0000000000000000 pr  : 65519a96659a9565
ldrs: 0000000000000000 ccv : 0000010b9263f310 fpsr: 0009804c0270033f
csd : 0000000000000000 ssd : 0000000000000000
b0  : a0000001008c40f0 b6  : a000000100473980 b7  : a0000001000106d0
f6  : 000000000000000000000 f7  : 1003e0000000085c9354c
f8  : 1003e0044b82fa09b5a53 f9  : 1003e000000d65cd62abf
f10 : 1003efd02efdec682803d f11 : 1003e0000000000000042
r1  : a00000010152c2e0 r2  : 0000000000006ada r3  : 000000000000fffe
r8  : 0000000000000026 r9  : a00000010121cc18 r10 : a0000001013309f0
r11 : 65519a96659a19e9 r12 : e00000070a91fdf0 r13 : e00000070a910000
r14 : 0000000000006ada r15 : 0000000000004000 r16 : 000000006ad8356c
r17 : a0000001019a525e r18 : 0000000000007fff r19 : 0000000000000000
r20 : 0000000000006ad6 r21 : 0000000000006ad6 r22 : a00000010133bec8
r23 : 0000000000006ad4 r24 : 0000000000000002 r25 : 8200000000260038
r26 : 00000000000004f9 r27 : 00000000000004f8 r28 : 000000000001cf98
r29 : 0000000000000038 r30 : a0000001019a5ae0 r31 : 000000000001cf60

Call Trace:
 [<a0000001000163e0>] show_stack+0x80/0xa0
                                sp=e00000070a91f9b0 bsp=e00000070a9115e0
 [<a000000100016a40>] show_regs+0x640/0x920
                                sp=e00000070a91fb80 bsp=e00000070a911588
 [<a000000100040590>] die+0x190/0x2c0
                                sp=e00000070a91fb90 bsp=e00000070a911548
 [<a000000100040710>] die_if_kernel+0x50/0x80
                                sp=e00000070a91fb90 bsp=e00000070a911518
 [<a0000001008f8030>] ia64_bad_break+0x3d0/0x6e0
                                sp=e00000070a91fb90 bsp=e00000070a9114f0
 [<a00000010000c0c0>] ia64_native_leave_kernel+0x0/0x270
                                sp=e00000070a91fc20 bsp=e00000070a9114f0
 [<a0000001008c40f0>] offline_pages+0x210/0xee0
                                sp=e00000070a91fdf0 bsp=e00000070a9113c8
 [<a00000010022d580>] alloc_pages_current+0x180/0x2a0
                                sp=e00000070a91fe20 bsp=e00000070a9113a

Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

memory hotplug: reset pgdat->kswapd to NULL if creating kernel thread fails

If kthread_run() fails, pgdat->kswapd contains errno.  When we stop this
thread, we only check whether pgdat->kswapd is NULL and access it.  If it
contains errno, it will cause page fault.  Reset pgdat->kswapd to NULL
when creating kernel thread fails can avoid this problem.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Reviewed-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Merge remote-tracking branch 'clk/clk-next'

Merge remote-tracking branch 'signal/for-next'

Conflicts:
arch/cris/include/asm/Kbuild
arch/h8300/include/asm/Kbuild
arch/m32r/include/asm/Kbuild
arch/x86/kernel/signal.c

Merge remote-tracking branch 'pwm/for-next'

Merge remote-tracking branch 'dma-mapping/dma-mapping-next'

Merge remote-tracking branch 'tegra/for-next'

Merge remote-tracking branch 'samsung/for-next'

Merge remote-tracking branch 'renesas/next'

Merge remote-tracking branch 'ep93xx/ep93xx-for-next'

Merge remote-tracking branch 'arm-soc/for-next'

Conflicts:
arch/arm/mach-ux500/cpu-db8500.c
drivers/mtd/nand/Kconfig
drivers/usb/host/Kconfig

Merge remote-tracking branch 'gpio-lw/for-next'

Merge remote-tracking branch 'vhost/linux-next'

Conflicts:
drivers/net/tun.c

Merge remote-tracking branch 'pinctrl/for-next'

Merge remote-tracking branch 'writeback/writeback-for-next'

Merge remote-tracking branch 'tmem/linux-next'

Merge remote-tracking branch 'char-misc/char-misc-next'

Merge remote-tracking branch 'staging/staging-next'

Merge remote-tracking branch 'usb/usb-next'

Merge remote-tracking branch 'tty/tty-next'

Merge remote-tracking branch 'driver-core/driver-core-next'

Merge remote-tracking branch 'leds/for-next'

Merge remote-tracking branch 'regmap/for-next'

Merge remote-tracking branch 'drivers-x86/linux-next'

Merge remote-tracking branch 'workqueues/for-next'

Conflicts:
drivers/hid/hid-picolcd.c

Merge remote-tracking branch 'xen-two/linux-next'

Merge remote-tracking branch 'kvm-ppc/kvm-ppc-next'

Conflicts:
arch/powerpc/include/asm/kvm_ppc.h
arch/powerpc/kvm/e500_tlb.c
include/linux/kvm.h

Merge remote-tracking branch 'kvm/linux-next'

Conflicts:
arch/s390/include/asm/processor.h

Merge remote-tracking branch 'kmemleak/kmemleak'

Merge remote-tracking branch 'rcu/rcu/next'

Conflicts:
arch/Kconfig
arch/x86/Kconfig
kernel/rcutree.h
kernel/rcutree_plugin.h
kernel/sched/core.c

Merge remote-tracking branch 'tip/auto-latest'

Conflicts:
arch/Kconfig

Merge commit 'refs/next/20120905/spi-mb'

Conflicts:
drivers/mmc/host/mxs-mmc.c

Merge remote-tracking branch 'dt-rh/for-next'

Merge remote-tracking branch 'edac-amd/for-next'

Conflicts:
Documentation/edac.txt
drivers/edac/amd64_edac.c

Merge remote-tracking branch 'edac/linux_next'

Merge remote-tracking branch 'fsnotify/for-next'

Conflicts:
kernel/audit_tree.c

Merge remote-tracking branch 'apm/for-next'

Merge remote-tracking branch 'pm/linux-next'

Merge remote-tracking branch 'trivial/for-next'

Conflicts:
drivers/scsi/ipr.c

Merge remote-tracking branch 'osd/linux-next'

Merge remote-tracking branch 'iommu/next'

Merge remote-tracking branch 'selinux/master'

Merge remote-tracking branch 'security/next'

Merge remote-tracking branch 'regulator/for-next'

Merge remote-tracking branch 'omap_dss2/for-next'

Conflicts:
drivers/video/omap2/dss/sdi.c

Merge remote-tracking branch 'fbdev/fbdev-next'

Merge remote-tracking branch 'battery/master'

Merge remote-tracking branch 'mfd/for-next'

Merge remote-tracking branch 'md/for-next'

Merge commit 'refs/next/20120905/slab'

Merge remote-tracking branch 'kgdb/kgdb-next'

Merge remote-tracking branch 'mmc/mmc-next'

Merge branch 'quilt/device-mapper'

Merge remote-tracking branch 'cgroup/for-next'

Merge remote-tracking branch 'input/next'

Merge branch 'quilt/rr'

Conflicts:
arch/alpha/Kconfig
arch/mips/kernel/module.c
arch/s390/Kconfig
arch/xtensa/Kconfig

Merge remote-tracking branch 'sound-asoc/for-next'

Merge remote-tracking branch 'sound/for-next'

Merge remote-tracking branch 'drm/drm-next'

Merge remote-tracking branch 'crypto/master'

Conflicts:
crypto/Kconfig

Merge remote-tracking branch 'l2-mtd/master'

Merge remote-tracking branch 'mtd/master'

Merge remote-tracking branch 'bluetooth/master'

Merge remote-tracking branch 'net-next/master'

Conflicts:
net/socket.c

Merge remote-tracking branch 'slave-dma/next'

Merge remote-tracking branch 'isci/all'

Merge remote-tracking branch 'target-updates/for-next'

Merge remote-tracking branch 'scsi/for-next'

Merge remote-tracking branch 'dlm/next'

Merge remote-tracking branch 'ubi/linux-next'

Merge remote-tracking branch 'thermal/next'

Merge remote-tracking branch 'cpuidle/cpuidle-next'

Conflicts:
drivers/cpuidle/coupled.c
include/linux/cpuidle.h

Merge remote-tracking branch 'pstore/master'

Merge remote-tracking branch 'libata/NEXT'

Merge remote-tracking branch 'kconfig/for-next'

Merge remote-tracking branch 'kbuild/for-next'

Merge remote-tracking branch 'v4l-dvb/master'

Conflicts:
arch/arm/mach-imx/mach-imx27_visstrim_m10.c

Merge remote-tracking branch 'hwmon-staging/hwmon-next'

Merge branch 'quilt/jdelvare-hwmon'

Merge remote-tracking branch 'i2c-embedded/i2c-embedded/for-next'

Merge branch 'quilt/i2c'

Merge remote-tracking branch 'hid/for-next'

Merge remote-tracking branch 'pci/next'

Conflicts:
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
drivers/rapidio/devices/tsi721.c

Merge remote-tracking branch 'vfs/for-next'

Merge remote-tracking branch 'xfs/for-next'

Merge remote-tracking branch 'ubifs/linux-next'