<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/include/linux, branch v3.17.4</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>mm, thp: fix collapsing of hugepages on madvise</title>
<updated>2014-11-21T17:23:15+00:00</updated>
<author>
<name>David Rientjes</name>
<email>rientjes@google.com</email>
</author>
<published>2014-10-29T21:50:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1cc4ca2591fd14d2899dcf4f409a3f76febf9103'/>
<id>1cc4ca2591fd14d2899dcf4f409a3f76febf9103</id>
<content type='text'>
commit 6d50e60cd2edb5a57154db5a6f64eef5aa59b751 upstream.

If an anonymous mapping is not allowed to fault thp memory and then
madvise(MADV_HUGEPAGE) is used after fault, khugepaged will never
collapse this memory into thp memory.

This occurs because the madvise(2) handler for thp, hugepage_madvise(),
clears VM_NOHUGEPAGE on the stack and it isn't stored in vma-&gt;vm_flags
until the final action of madvise_behavior().  This causes the
khugepaged_enter_vma_merge() to be a no-op in hugepage_madvise() when
the vma had previously had VM_NOHUGEPAGE set.

Fix this by passing the correct vma flags to the khugepaged mm slot
handler.  There's no chance khugepaged can run on this vma until after
madvise_behavior() returns since we hold mm-&gt;mmap_sem.

It would be possible to clear VM_NOHUGEPAGE directly from vma-&gt;vm_flags
in hugepage_advise(), but I didn't want to introduce special case
behavior into madvise_behavior().  I think it's best to just let it
always set vma-&gt;vm_flags itself.

Signed-off-by: David Rientjes &lt;rientjes@google.com&gt;
Reported-by: Suleiman Souhlal &lt;suleiman@google.com&gt;
Cc: "Kirill A. Shutemov" &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Andrea Arcangeli &lt;aarcange@redhat.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6d50e60cd2edb5a57154db5a6f64eef5aa59b751 upstream.

If an anonymous mapping is not allowed to fault thp memory and then
madvise(MADV_HUGEPAGE) is used after fault, khugepaged will never
collapse this memory into thp memory.

This occurs because the madvise(2) handler for thp, hugepage_madvise(),
clears VM_NOHUGEPAGE on the stack and it isn't stored in vma-&gt;vm_flags
until the final action of madvise_behavior().  This causes the
khugepaged_enter_vma_merge() to be a no-op in hugepage_madvise() when
the vma had previously had VM_NOHUGEPAGE set.

Fix this by passing the correct vma flags to the khugepaged mm slot
handler.  There's no chance khugepaged can run on this vma until after
madvise_behavior() returns since we hold mm-&gt;mmap_sem.

It would be possible to clear VM_NOHUGEPAGE directly from vma-&gt;vm_flags
in hugepage_advise(), but I didn't want to introduce special case
behavior into madvise_behavior().  I think it's best to just let it
always set vma-&gt;vm_flags itself.

Signed-off-by: David Rientjes &lt;rientjes@google.com&gt;
Reported-by: Suleiman Souhlal &lt;suleiman@google.com&gt;
Cc: "Kirill A. Shutemov" &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Andrea Arcangeli &lt;aarcange@redhat.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>clocksource: Remove "weak" from clocksource_default_clock() declaration</title>
<updated>2014-11-21T17:23:14+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2014-10-14T00:59:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fefd9bdc44e64c55da24e2a7d96faaeb0d5aea1e'/>
<id>fefd9bdc44e64c55da24e2a7d96faaeb0d5aea1e</id>
<content type='text'>
commit 96a2adbc6f501996418da9f7afe39bf0e4d006a9 upstream.

kernel/time/jiffies.c provides a default clocksource_default_clock()
definition explicitly marked "weak".  arch/s390 provides its own definition
intended to override the default, but the "weak" attribute on the
declaration applied to the s390 definition as well, so the linker chose one
based on link order (see 10629d711ed7 ("PCI: Remove __weak annotation from
pcibios_get_phb_of_node decl")).

Remove the "weak" attribute from the clocksource_default_clock()
declaration so we always prefer a non-weak definition over the weak one,
independent of link order.

Fixes: f1b82746c1e9 ("clocksource: Cleanup clocksource selection")
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: John Stultz &lt;john.stultz@linaro.org&gt;
Acked-by: Ingo Molnar &lt;mingo@kernel.org&gt;
CC: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
CC: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 96a2adbc6f501996418da9f7afe39bf0e4d006a9 upstream.

kernel/time/jiffies.c provides a default clocksource_default_clock()
definition explicitly marked "weak".  arch/s390 provides its own definition
intended to override the default, but the "weak" attribute on the
declaration applied to the s390 definition as well, so the linker chose one
based on link order (see 10629d711ed7 ("PCI: Remove __weak annotation from
pcibios_get_phb_of_node decl")).

Remove the "weak" attribute from the clocksource_default_clock()
declaration so we always prefer a non-weak definition over the weak one,
independent of link order.

Fixes: f1b82746c1e9 ("clocksource: Cleanup clocksource selection")
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: John Stultz &lt;john.stultz@linaro.org&gt;
Acked-by: Ingo Molnar &lt;mingo@kernel.org&gt;
CC: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
CC: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>kgdb: Remove "weak" from kgdb_arch_pc() declaration</title>
<updated>2014-11-21T17:23:14+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2014-10-14T01:00:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=401fc9d4842ecf2f5befd91ab0c92a126118e013'/>
<id>401fc9d4842ecf2f5befd91ab0c92a126118e013</id>
<content type='text'>
commit 107bcc6d566cb40184068d888637f9aefe6252dd upstream.

kernel/debug/debug_core.c provides a default kgdb_arch_pc() definition
explicitly marked "weak".  Several architectures provide their own
definitions intended to override the default, but the "weak" attribute on
the declaration applied to the arch definitions as well, so the linker
chose one based on link order (see 10629d711ed7 ("PCI: Remove __weak
annotation from pcibios_get_phb_of_node decl")).

Remove the "weak" attribute from the declaration so we always prefer a
non-weak definition over the weak one, independent of link order.

Fixes: 688b744d8bc8 ("kgdb: fix signedness mixmatches, add statics, add declaration to header")
Tested-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;	# for ARC build
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Harvey Harrison &lt;harvey.harrison@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 107bcc6d566cb40184068d888637f9aefe6252dd upstream.

kernel/debug/debug_core.c provides a default kgdb_arch_pc() definition
explicitly marked "weak".  Several architectures provide their own
definitions intended to override the default, but the "weak" attribute on
the declaration applied to the arch definitions as well, so the linker
chose one based on link order (see 10629d711ed7 ("PCI: Remove __weak
annotation from pcibios_get_phb_of_node decl")).

Remove the "weak" attribute from the declaration so we always prefer a
non-weak definition over the weak one, independent of link order.

Fixes: 688b744d8bc8 ("kgdb: fix signedness mixmatches, add statics, add declaration to header")
Tested-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;	# for ARC build
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Harvey Harrison &lt;harvey.harrison@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>vmcore: Remove "weak" from function declarations</title>
<updated>2014-11-21T17:23:14+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2014-10-14T00:59:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0e46aef546ad5f89664fe09622b723117299b51d'/>
<id>0e46aef546ad5f89664fe09622b723117299b51d</id>
<content type='text'>
commit 5ab03ac5aaa1f032e071f1b3dc433b7839359c03 upstream.

For the following functions:

  elfcorehdr_alloc()
  elfcorehdr_free()
  elfcorehdr_read()
  elfcorehdr_read_notes()
  remap_oldmem_pfn_range()

fs/proc/vmcore.c provides default definitions explicitly marked "weak".
arch/s390 provides its own definitions intended to override the default
ones, but the "weak" attribute on the declarations applied to the s390
definitions as well, so the linker chose one based on link order (see
10629d711ed7 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node
decl")).

Remove the "weak" attribute from the declarations so we always prefer a
non-weak definition over the weak one, independent of link order.

Fixes: be8a8d069e50 ("vmcore: introduce ELF header in new memory feature")
Fixes: 9cb218131de1 ("vmcore: introduce remap_oldmem_pfn_range()")
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Acked-by: Vivek Goyal &lt;vgoyal@redhat.com&gt;
CC: Michael Holzheu &lt;holzheu@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5ab03ac5aaa1f032e071f1b3dc433b7839359c03 upstream.

For the following functions:

  elfcorehdr_alloc()
  elfcorehdr_free()
  elfcorehdr_read()
  elfcorehdr_read_notes()
  remap_oldmem_pfn_range()

fs/proc/vmcore.c provides default definitions explicitly marked "weak".
arch/s390 provides its own definitions intended to override the default
ones, but the "weak" attribute on the declarations applied to the s390
definitions as well, so the linker chose one based on link order (see
10629d711ed7 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node
decl")).

Remove the "weak" attribute from the declarations so we always prefer a
non-weak definition over the weak one, independent of link order.

Fixes: be8a8d069e50 ("vmcore: introduce ELF header in new memory feature")
Fixes: 9cb218131de1 ("vmcore: introduce remap_oldmem_pfn_range()")
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Acked-by: Vivek Goyal &lt;vgoyal@redhat.com&gt;
CC: Michael Holzheu &lt;holzheu@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>memory-hotplug: Remove "weak" from memory_block_size_bytes() declaration</title>
<updated>2014-11-21T17:23:14+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2014-10-14T01:00:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6ba4331bc4ff1c4c0022d1efab4efb2ac582e561'/>
<id>6ba4331bc4ff1c4c0022d1efab4efb2ac582e561</id>
<content type='text'>
commit e0a8400c6923a163265d52798cdd4c33f3f8ab5a upstream.

drivers/base/memory.c provides a default memory_block_size_bytes()
definition explicitly marked "weak".  Several architectures provide their
own definitions intended to override the default, but the "weak" attribute
on the declaration applied to the arch definitions as well, so the linker
chose one based on link order (see 10629d711ed7 ("PCI: Remove __weak
annotation from pcibios_get_phb_of_node decl")).

Remove the "weak" attribute from the declaration so we always prefer a
non-weak definition over the weak one, independent of link order.

Fixes: 41f107266b19 ("drivers: base: Add prototype declaration to the header file")
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
CC: Rashika Kheria &lt;rashika.kheria@gmail.com&gt;
CC: Nathan Fontenot &lt;nfont@austin.ibm.com&gt;
CC: Anton Blanchard &lt;anton@au1.ibm.com&gt;
CC: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
CC: Yinghai Lu &lt;yinghai@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e0a8400c6923a163265d52798cdd4c33f3f8ab5a upstream.

drivers/base/memory.c provides a default memory_block_size_bytes()
definition explicitly marked "weak".  Several architectures provide their
own definitions intended to override the default, but the "weak" attribute
on the declaration applied to the arch definitions as well, so the linker
chose one based on link order (see 10629d711ed7 ("PCI: Remove __weak
annotation from pcibios_get_phb_of_node decl")).

Remove the "weak" attribute from the declaration so we always prefer a
non-weak definition over the weak one, independent of link order.

Fixes: 41f107266b19 ("drivers: base: Add prototype declaration to the header file")
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
CC: Rashika Kheria &lt;rashika.kheria@gmail.com&gt;
CC: Nathan Fontenot &lt;nfont@austin.ibm.com&gt;
CC: Anton Blanchard &lt;anton@au1.ibm.com&gt;
CC: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
CC: Yinghai Lu &lt;yinghai@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>power: charger-manager: Fix accessing invalidated power supply after charger unbind</title>
<updated>2014-11-21T17:23:13+00:00</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>k.kozlowski@samsung.com</email>
</author>
<published>2014-10-13T13:34:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e5cb3367b6fde0c21983cf4deb38c9972a390c42'/>
<id>e5cb3367b6fde0c21983cf4deb38c9972a390c42</id>
<content type='text'>
commit cdaf3e15385d3232b52287e50692506f8fd01a09 upstream.

The charger manager obtained in probe references to power supplies for
all chargers with power_supply_get_by_name() for later usage. However
if such charger driver was removed then this reference would point to
old power supply (from driver which was removed).

This lead to accessing invalid memory which could be observed with:
$ echo "max77693-charger" &gt; /sys/bus/platform/drivers/max77693-charger/unbind
$ grep . /sys/devices/virtual/power_supply/battery/charger.0/*
$ grep . /sys/devices/virtual/power_supply/battery/*
[   15.339817] Unable to handle kernel paging request at virtual address 0001c12c
[   15.346187] pgd = edd08000
[   15.348814] [0001c12c] *pgd=6dce2831, *pte=00000000, *ppte=00000000
[   15.355075] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
[   15.360967] Modules linked in:
[   15.364010] CPU: 2 PID: 1388 Comm: grep Not tainted 3.17.0-next-20141007-00027-ga95e761db1b0 #245
[   15.372859] task: ee03ad00 ti: edcf6000 task.ti: edcf6000
[   15.378241] PC is at 0x1c12c
[   15.381113] LR is at is_ext_pwr_online+0x30/0x6c
[   15.385706] pc : [&lt;0001c12c&gt;]    lr : [&lt;c0339fc4&gt;]    psr: a0000013
[   15.385706] sp : edcf7e88  ip : 00000000  fp : 00000000
[   15.397161] r10: eeb02c08  r9 : c04b1f84  r8 : eeb02c00
[   15.402369] r7 : edc69a10  r6 : eea6ac10  r5 : eea6ac10  r4 : 00000004
[   15.408878] r3 : 0001c12c  r2 : edcf7e8c  r1 : 00000004  r0 : ee914418
[   15.415390] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   15.422506] Control: 10c5387d  Table: 6dd0804a  DAC: 00000015
[   15.428236] Process grep (pid: 1388, stack limit = 0xedcf6240)
[   15.434050] Stack: (0xedcf7e88 to 0xedcf8000)
[   15.438395] 7e80:                   ee03ad00 00000000 edcf7f80 eea6aca8 edcf7ec4 c033b7b0
[   15.446554] 7ea0: 00000001 ee1cc3f0 00000004 c06e1e44 eebdc000 c06e1e44 eeb02c00 c0337144
[   15.454713] 7ec0: ee2dac68 c005cffc ee1cc3c0 c06e1e44 00000fff 00001000 eebdc000 c0278ca8
[   15.462872] 7ee0: c0278c8c ee1cc3c0 eeb7ce00 c014422c edcf7f20 00008000 ee1cc3c0 ee9a48c0
[   15.471030] 7f00: 00000001 00000001 edcf7f80 c0142d94 c0142d70 c01060f4 00021000 ee1cc3f0
[   15.479190] 7f20: 00000000 00000000 c06a2150 eebdc000 2e7ec000 ee9a48c0 00008000 00021000
[   15.487349] 7f40: edcf7f80 00008000 edcf6000 00021000 00021000 c00e39a4 00000000 ee9a48c0
[   15.495508] 7f60: 00004000 00000000 00000000 ee9a48c0 ee9a48c0 00008000 00021000 c00e3aa0
[   15.503668] 7f80: 00000000 00000000 0001f2e0 0001f2e0 00021000 00001000 00000003 c000f364
[   15.511826] 7fa0: 00000000 c000f1a0 0001f2e0 00021000 00000003 00021000 00008000 00000000
[   15.519986] 7fc0: 0001f2e0 00021000 00001000 00000003 00000001 000205e8 00000000 00021000
[   15.528145] 7fe0: 00008000 bebbe910 0000a7ad b6edc49c 60000010 00000003 aaaaaaaa aaaaaaaa
[   15.536320] [&lt;c0339fc4&gt;] (is_ext_pwr_online) from [&lt;c033b7b0&gt;] (charger_get_property+0x170/0x314)
[   15.545164] [&lt;c033b7b0&gt;] (charger_get_property) from [&lt;c0337144&gt;] (power_supply_show_property+0x48/0x20c)
[   15.554719] [&lt;c0337144&gt;] (power_supply_show_property) from [&lt;c0278ca8&gt;] (dev_attr_show+0x1c/0x48)
[   15.563577] [&lt;c0278ca8&gt;] (dev_attr_show) from [&lt;c014422c&gt;] (sysfs_kf_seq_show+0x84/0x104)
[   15.571725] [&lt;c014422c&gt;] (sysfs_kf_seq_show) from [&lt;c0142d94&gt;] (kernfs_seq_show+0x24/0x28)
[   15.579973] [&lt;c0142d94&gt;] (kernfs_seq_show) from [&lt;c01060f4&gt;] (seq_read+0x1b0/0x484)
[   15.587614] [&lt;c01060f4&gt;] (seq_read) from [&lt;c00e39a4&gt;] (vfs_read+0x88/0x144)
[   15.594552] [&lt;c00e39a4&gt;] (vfs_read) from [&lt;c00e3aa0&gt;] (SyS_read+0x40/0x8c)
[   15.601417] [&lt;c00e3aa0&gt;] (SyS_read) from [&lt;c000f1a0&gt;] (ret_fast_syscall+0x0/0x48)
[   15.608877] Code: bad PC value
[   15.611991] ---[ end trace a88fcc95208db283 ]---

The charger-manager should get reference to charger power supply on
each use of get_property callback.

Signed-off-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Fixes: 3bb3dbbd56ea ("power_supply: Add initial Charger-Manager driver")
Signed-off-by: Sebastian Reichel &lt;sre@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cdaf3e15385d3232b52287e50692506f8fd01a09 upstream.

The charger manager obtained in probe references to power supplies for
all chargers with power_supply_get_by_name() for later usage. However
if such charger driver was removed then this reference would point to
old power supply (from driver which was removed).

This lead to accessing invalid memory which could be observed with:
$ echo "max77693-charger" &gt; /sys/bus/platform/drivers/max77693-charger/unbind
$ grep . /sys/devices/virtual/power_supply/battery/charger.0/*
$ grep . /sys/devices/virtual/power_supply/battery/*
[   15.339817] Unable to handle kernel paging request at virtual address 0001c12c
[   15.346187] pgd = edd08000
[   15.348814] [0001c12c] *pgd=6dce2831, *pte=00000000, *ppte=00000000
[   15.355075] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
[   15.360967] Modules linked in:
[   15.364010] CPU: 2 PID: 1388 Comm: grep Not tainted 3.17.0-next-20141007-00027-ga95e761db1b0 #245
[   15.372859] task: ee03ad00 ti: edcf6000 task.ti: edcf6000
[   15.378241] PC is at 0x1c12c
[   15.381113] LR is at is_ext_pwr_online+0x30/0x6c
[   15.385706] pc : [&lt;0001c12c&gt;]    lr : [&lt;c0339fc4&gt;]    psr: a0000013
[   15.385706] sp : edcf7e88  ip : 00000000  fp : 00000000
[   15.397161] r10: eeb02c08  r9 : c04b1f84  r8 : eeb02c00
[   15.402369] r7 : edc69a10  r6 : eea6ac10  r5 : eea6ac10  r4 : 00000004
[   15.408878] r3 : 0001c12c  r2 : edcf7e8c  r1 : 00000004  r0 : ee914418
[   15.415390] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   15.422506] Control: 10c5387d  Table: 6dd0804a  DAC: 00000015
[   15.428236] Process grep (pid: 1388, stack limit = 0xedcf6240)
[   15.434050] Stack: (0xedcf7e88 to 0xedcf8000)
[   15.438395] 7e80:                   ee03ad00 00000000 edcf7f80 eea6aca8 edcf7ec4 c033b7b0
[   15.446554] 7ea0: 00000001 ee1cc3f0 00000004 c06e1e44 eebdc000 c06e1e44 eeb02c00 c0337144
[   15.454713] 7ec0: ee2dac68 c005cffc ee1cc3c0 c06e1e44 00000fff 00001000 eebdc000 c0278ca8
[   15.462872] 7ee0: c0278c8c ee1cc3c0 eeb7ce00 c014422c edcf7f20 00008000 ee1cc3c0 ee9a48c0
[   15.471030] 7f00: 00000001 00000001 edcf7f80 c0142d94 c0142d70 c01060f4 00021000 ee1cc3f0
[   15.479190] 7f20: 00000000 00000000 c06a2150 eebdc000 2e7ec000 ee9a48c0 00008000 00021000
[   15.487349] 7f40: edcf7f80 00008000 edcf6000 00021000 00021000 c00e39a4 00000000 ee9a48c0
[   15.495508] 7f60: 00004000 00000000 00000000 ee9a48c0 ee9a48c0 00008000 00021000 c00e3aa0
[   15.503668] 7f80: 00000000 00000000 0001f2e0 0001f2e0 00021000 00001000 00000003 c000f364
[   15.511826] 7fa0: 00000000 c000f1a0 0001f2e0 00021000 00000003 00021000 00008000 00000000
[   15.519986] 7fc0: 0001f2e0 00021000 00001000 00000003 00000001 000205e8 00000000 00021000
[   15.528145] 7fe0: 00008000 bebbe910 0000a7ad b6edc49c 60000010 00000003 aaaaaaaa aaaaaaaa
[   15.536320] [&lt;c0339fc4&gt;] (is_ext_pwr_online) from [&lt;c033b7b0&gt;] (charger_get_property+0x170/0x314)
[   15.545164] [&lt;c033b7b0&gt;] (charger_get_property) from [&lt;c0337144&gt;] (power_supply_show_property+0x48/0x20c)
[   15.554719] [&lt;c0337144&gt;] (power_supply_show_property) from [&lt;c0278ca8&gt;] (dev_attr_show+0x1c/0x48)
[   15.563577] [&lt;c0278ca8&gt;] (dev_attr_show) from [&lt;c014422c&gt;] (sysfs_kf_seq_show+0x84/0x104)
[   15.571725] [&lt;c014422c&gt;] (sysfs_kf_seq_show) from [&lt;c0142d94&gt;] (kernfs_seq_show+0x24/0x28)
[   15.579973] [&lt;c0142d94&gt;] (kernfs_seq_show) from [&lt;c01060f4&gt;] (seq_read+0x1b0/0x484)
[   15.587614] [&lt;c01060f4&gt;] (seq_read) from [&lt;c00e39a4&gt;] (vfs_read+0x88/0x144)
[   15.594552] [&lt;c00e39a4&gt;] (vfs_read) from [&lt;c00e3aa0&gt;] (SyS_read+0x40/0x8c)
[   15.601417] [&lt;c00e3aa0&gt;] (SyS_read) from [&lt;c000f1a0&gt;] (ret_fast_syscall+0x0/0x48)
[   15.608877] Code: bad PC value
[   15.611991] ---[ end trace a88fcc95208db283 ]---

The charger-manager should get reference to charger power supply on
each use of get_property callback.

Signed-off-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Fixes: 3bb3dbbd56ea ("power_supply: Add initial Charger-Manager driver")
Signed-off-by: Sebastian Reichel &lt;sre@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>power: charger-manager: Fix accessing invalidated power supply after fuel gauge unbind</title>
<updated>2014-11-21T17:23:13+00:00</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>k.kozlowski@samsung.com</email>
</author>
<published>2014-10-13T13:34:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=767a001799421965635c7f524cde66ff34231701'/>
<id>767a001799421965635c7f524cde66ff34231701</id>
<content type='text'>
commit bdbe81445407644492b9ac69a24d35e3202d773b upstream.

The charger manager obtained reference to fuel gauge power supply in probe
with power_supply_get_by_name() for later usage. However if fuel gauge
driver was removed and re-added then this reference would point to old
power supply (from driver which was removed).

This lead to accessing old (and probably invalid) memory which could be
observed with:
$ echo "12-0036" &gt; /sys/bus/i2c/drivers/max17042/unbind
$ echo "12-0036" &gt; /sys/bus/i2c/drivers/max17042/bind
$ cat /sys/devices/virtual/power_supply/battery/capacity
[  240.480084] INFO: task cat:1393 blocked for more than 120 seconds.
[  240.484799]       Not tainted 3.17.0-next-20141007-00028-ge60b6dd79570 #203
[  240.491782] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  240.499589] cat             D c0469530     0  1393      1 0x00000000
[  240.505947] [&lt;c0469530&gt;] (__schedule) from [&lt;c0469d3c&gt;] (schedule_preempt_disabled+0x14/0x20)
[  240.514449] [&lt;c0469d3c&gt;] (schedule_preempt_disabled) from [&lt;c046af08&gt;] (mutex_lock_nested+0x1bc/0x458)
[  240.523736] [&lt;c046af08&gt;] (mutex_lock_nested) from [&lt;c0287a98&gt;] (regmap_read+0x30/0x60)
[  240.531647] [&lt;c0287a98&gt;] (regmap_read) from [&lt;c032238c&gt;] (max17042_get_property+0x2e8/0x350)
[  240.540055] [&lt;c032238c&gt;] (max17042_get_property) from [&lt;c03247d8&gt;] (charger_get_property+0x264/0x348)
[  240.549252] [&lt;c03247d8&gt;] (charger_get_property) from [&lt;c0320764&gt;] (power_supply_show_property+0x48/0x1e0)
[  240.558808] [&lt;c0320764&gt;] (power_supply_show_property) from [&lt;c027308c&gt;] (dev_attr_show+0x1c/0x48)
[  240.567664] [&lt;c027308c&gt;] (dev_attr_show) from [&lt;c0141fb0&gt;] (sysfs_kf_seq_show+0x84/0x104)
[  240.575814] [&lt;c0141fb0&gt;] (sysfs_kf_seq_show) from [&lt;c0140b18&gt;] (kernfs_seq_show+0x24/0x28)
[  240.584061] [&lt;c0140b18&gt;] (kernfs_seq_show) from [&lt;c0104574&gt;] (seq_read+0x1b0/0x484)
[  240.591702] [&lt;c0104574&gt;] (seq_read) from [&lt;c00e1e24&gt;] (vfs_read+0x88/0x144)
[  240.598640] [&lt;c00e1e24&gt;] (vfs_read) from [&lt;c00e1f20&gt;] (SyS_read+0x40/0x8c)
[  240.605507] [&lt;c00e1f20&gt;] (SyS_read) from [&lt;c000e760&gt;] (ret_fast_syscall+0x0/0x48)
[  240.612952] 4 locks held by cat/1393:
[  240.616589]  #0:  (&amp;p-&gt;lock){+.+.+.}, at: [&lt;c01043f4&gt;] seq_read+0x30/0x484
[  240.623414]  #1:  (&amp;of-&gt;mutex){+.+.+.}, at: [&lt;c01417dc&gt;] kernfs_seq_start+0x1c/0x8c
[  240.631086]  #2:  (s_active#31){++++.+}, at: [&lt;c01417e4&gt;] kernfs_seq_start+0x24/0x8c
[  240.638777]  #3:  (&amp;map-&gt;mutex){+.+...}, at: [&lt;c0287a98&gt;] regmap_read+0x30/0x60

The charger-manager should get reference to fuel gauge power supply on
each use of get_property callback. The thermal zone 'tzd' field of
power supply should not be used because of the same reason.

Additionally this change solves also the issue with nested
thermal_zone_get_temp() calls and related false lockdep positive for
deadlock for thermal zone's mutex [1]. When fuel gauge is used as source of
temperature then the charger manager forwards its get_temp calls to fuel
gauge thermal zone. So actually different mutexes are used (one for
charger manager thermal zone and second for fuel gauge thermal zone) but
for lockdep this is one class of mutex.

The recursion is removed by retrieving temperature through power
supply's get_property().

In case external thermal zone is used ('cm-thermal-zone' property is
present in DTS) the recursion does not exist. Charger manager simply
exports POWER_SUPPLY_PROP_TEMP_AMBIENT property (instead of
POWER_SUPPLY_PROP_TEMP) thus no thermal zone is created for this power
supply.

[1] https://lkml.org/lkml/2014/10/6/309

Signed-off-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Fixes: 3bb3dbbd56ea ("power_supply: Add initial Charger-Manager driver")
Signed-off-by: Sebastian Reichel &lt;sre@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bdbe81445407644492b9ac69a24d35e3202d773b upstream.

The charger manager obtained reference to fuel gauge power supply in probe
with power_supply_get_by_name() for later usage. However if fuel gauge
driver was removed and re-added then this reference would point to old
power supply (from driver which was removed).

This lead to accessing old (and probably invalid) memory which could be
observed with:
$ echo "12-0036" &gt; /sys/bus/i2c/drivers/max17042/unbind
$ echo "12-0036" &gt; /sys/bus/i2c/drivers/max17042/bind
$ cat /sys/devices/virtual/power_supply/battery/capacity
[  240.480084] INFO: task cat:1393 blocked for more than 120 seconds.
[  240.484799]       Not tainted 3.17.0-next-20141007-00028-ge60b6dd79570 #203
[  240.491782] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  240.499589] cat             D c0469530     0  1393      1 0x00000000
[  240.505947] [&lt;c0469530&gt;] (__schedule) from [&lt;c0469d3c&gt;] (schedule_preempt_disabled+0x14/0x20)
[  240.514449] [&lt;c0469d3c&gt;] (schedule_preempt_disabled) from [&lt;c046af08&gt;] (mutex_lock_nested+0x1bc/0x458)
[  240.523736] [&lt;c046af08&gt;] (mutex_lock_nested) from [&lt;c0287a98&gt;] (regmap_read+0x30/0x60)
[  240.531647] [&lt;c0287a98&gt;] (regmap_read) from [&lt;c032238c&gt;] (max17042_get_property+0x2e8/0x350)
[  240.540055] [&lt;c032238c&gt;] (max17042_get_property) from [&lt;c03247d8&gt;] (charger_get_property+0x264/0x348)
[  240.549252] [&lt;c03247d8&gt;] (charger_get_property) from [&lt;c0320764&gt;] (power_supply_show_property+0x48/0x1e0)
[  240.558808] [&lt;c0320764&gt;] (power_supply_show_property) from [&lt;c027308c&gt;] (dev_attr_show+0x1c/0x48)
[  240.567664] [&lt;c027308c&gt;] (dev_attr_show) from [&lt;c0141fb0&gt;] (sysfs_kf_seq_show+0x84/0x104)
[  240.575814] [&lt;c0141fb0&gt;] (sysfs_kf_seq_show) from [&lt;c0140b18&gt;] (kernfs_seq_show+0x24/0x28)
[  240.584061] [&lt;c0140b18&gt;] (kernfs_seq_show) from [&lt;c0104574&gt;] (seq_read+0x1b0/0x484)
[  240.591702] [&lt;c0104574&gt;] (seq_read) from [&lt;c00e1e24&gt;] (vfs_read+0x88/0x144)
[  240.598640] [&lt;c00e1e24&gt;] (vfs_read) from [&lt;c00e1f20&gt;] (SyS_read+0x40/0x8c)
[  240.605507] [&lt;c00e1f20&gt;] (SyS_read) from [&lt;c000e760&gt;] (ret_fast_syscall+0x0/0x48)
[  240.612952] 4 locks held by cat/1393:
[  240.616589]  #0:  (&amp;p-&gt;lock){+.+.+.}, at: [&lt;c01043f4&gt;] seq_read+0x30/0x484
[  240.623414]  #1:  (&amp;of-&gt;mutex){+.+.+.}, at: [&lt;c01417dc&gt;] kernfs_seq_start+0x1c/0x8c
[  240.631086]  #2:  (s_active#31){++++.+}, at: [&lt;c01417e4&gt;] kernfs_seq_start+0x24/0x8c
[  240.638777]  #3:  (&amp;map-&gt;mutex){+.+...}, at: [&lt;c0287a98&gt;] regmap_read+0x30/0x60

The charger-manager should get reference to fuel gauge power supply on
each use of get_property callback. The thermal zone 'tzd' field of
power supply should not be used because of the same reason.

Additionally this change solves also the issue with nested
thermal_zone_get_temp() calls and related false lockdep positive for
deadlock for thermal zone's mutex [1]. When fuel gauge is used as source of
temperature then the charger manager forwards its get_temp calls to fuel
gauge thermal zone. So actually different mutexes are used (one for
charger manager thermal zone and second for fuel gauge thermal zone) but
for lockdep this is one class of mutex.

The recursion is removed by retrieving temperature through power
supply's get_property().

In case external thermal zone is used ('cm-thermal-zone' property is
present in DTS) the recursion does not exist. Charger manager simply
exports POWER_SUPPLY_PROP_TEMP_AMBIENT property (instead of
POWER_SUPPLY_PROP_TEMP) thus no thermal zone is created for this power
supply.

[1] https://lkml.org/lkml/2014/10/6/309

Signed-off-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Fixes: 3bb3dbbd56ea ("power_supply: Add initial Charger-Manager driver")
Signed-off-by: Sebastian Reichel &lt;sre@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>nfs: fix pnfs direct write memory leak</title>
<updated>2014-11-21T17:23:12+00:00</updated>
<author>
<name>Peng Tao</name>
<email>tao.peng@primarydata.com</email>
</author>
<published>2014-11-05T14:36:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=07909def7993d3fa661411526be045f02ee240f0'/>
<id>07909def7993d3fa661411526be045f02ee240f0</id>
<content type='text'>
commit 8c393f9a721c30a030049a680e1bf896669bb279 upstream.

For pNFS direct writes, layout driver may dynamically allocate ds_cinfo.buckets.
So we need to take care to free them when freeing dreq.

Ideally this needs to be done inside layout driver where ds_cinfo.buckets
are allocated. But buckets are attached to dreq and reused across LD IO iterations.
So I feel it's OK to free them in the generic layer.

Signed-off-by: Peng Tao &lt;tao.peng@primarydata.com&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8c393f9a721c30a030049a680e1bf896669bb279 upstream.

For pNFS direct writes, layout driver may dynamically allocate ds_cinfo.buckets.
So we need to take care to free them when freeing dreq.

Ideally this needs to be done inside layout driver where ds_cinfo.buckets
are allocated. But buckets are attached to dreq and reused across LD IO iterations.
So I feel it's OK to free them in the generic layer.

Signed-off-by: Peng Tao &lt;tao.peng@primarydata.com&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tracing: Do not busy wait in buffer splice</title>
<updated>2014-11-21T17:23:10+00:00</updated>
<author>
<name>Rabin Vincent</name>
<email>rabin@rab.in</email>
</author>
<published>2014-11-10T18:46:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fe1d808aabae9f4a1d1e73eea660839c1708b680'/>
<id>fe1d808aabae9f4a1d1e73eea660839c1708b680</id>
<content type='text'>
commit e30f53aad2202b5526c40c36d8eeac8bf290bde5 upstream.

On a !PREEMPT kernel, attempting to use trace-cmd results in a soft
lockup:

 # trace-cmd record -e raw_syscalls:* -F false
 NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [trace-cmd:61]
 ...
 Call Trace:
  [&lt;ffffffff8105b580&gt;] ? __wake_up_common+0x90/0x90
  [&lt;ffffffff81092e25&gt;] wait_on_pipe+0x35/0x40
  [&lt;ffffffff810936e3&gt;] tracing_buffers_splice_read+0x2e3/0x3c0
  [&lt;ffffffff81093300&gt;] ? tracing_stats_read+0x2a0/0x2a0
  [&lt;ffffffff812d10ab&gt;] ? _raw_spin_unlock+0x2b/0x40
  [&lt;ffffffff810dc87b&gt;] ? do_read_fault+0x21b/0x290
  [&lt;ffffffff810de56a&gt;] ? handle_mm_fault+0x2ba/0xbd0
  [&lt;ffffffff81095c80&gt;] ? trace_event_buffer_lock_reserve+0x40/0x80
  [&lt;ffffffff810951e2&gt;] ? trace_buffer_lock_reserve+0x22/0x60
  [&lt;ffffffff81095c80&gt;] ? trace_event_buffer_lock_reserve+0x40/0x80
  [&lt;ffffffff8112415d&gt;] do_splice_to+0x6d/0x90
  [&lt;ffffffff81126971&gt;] SyS_splice+0x7c1/0x800
  [&lt;ffffffff812d1edd&gt;] tracesys_phase2+0xd3/0xd8

The problem is this: tracing_buffers_splice_read() calls
ring_buffer_wait() to wait for data in the ring buffers.  The buffers
are not empty so ring_buffer_wait() returns immediately.  But
tracing_buffers_splice_read() calls ring_buffer_read_page() with full=1,
meaning it only wants to read a full page.  When the full page is not
available, tracing_buffers_splice_read() tries to wait again with
ring_buffer_wait(), which again returns immediately, and so on.

Fix this by adding a "full" argument to ring_buffer_wait() which will
make ring_buffer_wait() wait until the writer has left the reader's
page, i.e.  until full-page reads will succeed.

Link: http://lkml.kernel.org/r/1415645194-25379-1-git-send-email-rabin@rab.in

Fixes: b1169cc69ba9 ("tracing: Remove mock up poll wait function")
Signed-off-by: Rabin Vincent &lt;rabin@rab.in&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e30f53aad2202b5526c40c36d8eeac8bf290bde5 upstream.

On a !PREEMPT kernel, attempting to use trace-cmd results in a soft
lockup:

 # trace-cmd record -e raw_syscalls:* -F false
 NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [trace-cmd:61]
 ...
 Call Trace:
  [&lt;ffffffff8105b580&gt;] ? __wake_up_common+0x90/0x90
  [&lt;ffffffff81092e25&gt;] wait_on_pipe+0x35/0x40
  [&lt;ffffffff810936e3&gt;] tracing_buffers_splice_read+0x2e3/0x3c0
  [&lt;ffffffff81093300&gt;] ? tracing_stats_read+0x2a0/0x2a0
  [&lt;ffffffff812d10ab&gt;] ? _raw_spin_unlock+0x2b/0x40
  [&lt;ffffffff810dc87b&gt;] ? do_read_fault+0x21b/0x290
  [&lt;ffffffff810de56a&gt;] ? handle_mm_fault+0x2ba/0xbd0
  [&lt;ffffffff81095c80&gt;] ? trace_event_buffer_lock_reserve+0x40/0x80
  [&lt;ffffffff810951e2&gt;] ? trace_buffer_lock_reserve+0x22/0x60
  [&lt;ffffffff81095c80&gt;] ? trace_event_buffer_lock_reserve+0x40/0x80
  [&lt;ffffffff8112415d&gt;] do_splice_to+0x6d/0x90
  [&lt;ffffffff81126971&gt;] SyS_splice+0x7c1/0x800
  [&lt;ffffffff812d1edd&gt;] tracesys_phase2+0xd3/0xd8

The problem is this: tracing_buffers_splice_read() calls
ring_buffer_wait() to wait for data in the ring buffers.  The buffers
are not empty so ring_buffer_wait() returns immediately.  But
tracing_buffers_splice_read() calls ring_buffer_read_page() with full=1,
meaning it only wants to read a full page.  When the full page is not
available, tracing_buffers_splice_read() tries to wait again with
ring_buffer_wait(), which again returns immediately, and so on.

Fix this by adding a "full" argument to ring_buffer_wait() which will
make ring_buffer_wait() wait until the writer has left the reader's
page, i.e.  until full-page reads will succeed.

Link: http://lkml.kernel.org/r/1415645194-25379-1-git-send-email-rabin@rab.in

Fixes: b1169cc69ba9 ("tracing: Remove mock up poll wait function")
Signed-off-by: Rabin Vincent &lt;rabin@rab.in&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mem-hotplug: reset node managed pages when hot-adding a new pgdat</title>
<updated>2014-11-21T17:23:09+00:00</updated>
<author>
<name>Tang Chen</name>
<email>tangchen@cn.fujitsu.com</email>
</author>
<published>2014-11-13T23:19:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6bfed69cf01d1ef7aa98a178ed234037a460fcbc'/>
<id>6bfed69cf01d1ef7aa98a178ed234037a460fcbc</id>
<content type='text'>
commit f784a3f19613901ca4539a5b0eed3bdc700e6ee7 upstream.

In free_area_init_core(), zone-&gt;managed_pages is set to an approximate
value for lowmem, and will be adjusted when the bootmem allocator frees
pages into the buddy system.

But free_area_init_core() is also called by hotadd_new_pgdat() when
hot-adding memory.  As a result, zone-&gt;managed_pages of the newly added
node's pgdat is set to an approximate value in the very beginning.

Even if the memory on that node has node been onlined,
/sys/device/system/node/nodeXXX/meminfo has wrong value:

  hot-add node2 (memory not onlined)
  cat /sys/device/system/node/node2/meminfo
  Node 2 MemTotal:       33554432 kB
  Node 2 MemFree:               0 kB
  Node 2 MemUsed:        33554432 kB
  Node 2 Active:                0 kB

This patch fixes this problem by reset node managed pages to 0 after
hot-adding a new node.

1. Move reset_managed_pages_done from reset_node_managed_pages() to
   reset_all_zones_managed_pages()
2. Make reset_node_managed_pages() non-static
3. Call reset_node_managed_pages() in hotadd_new_pgdat() after pgdat
   is initialized

Signed-off-by: Tang Chen &lt;tangchen@cn.fujitsu.com&gt;
Signed-off-by: Yasuaki Ishimatsu &lt;isimatu.yasuaki@jp.fujitsu.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f784a3f19613901ca4539a5b0eed3bdc700e6ee7 upstream.

In free_area_init_core(), zone-&gt;managed_pages is set to an approximate
value for lowmem, and will be adjusted when the bootmem allocator frees
pages into the buddy system.

But free_area_init_core() is also called by hotadd_new_pgdat() when
hot-adding memory.  As a result, zone-&gt;managed_pages of the newly added
node's pgdat is set to an approximate value in the very beginning.

Even if the memory on that node has node been onlined,
/sys/device/system/node/nodeXXX/meminfo has wrong value:

  hot-add node2 (memory not onlined)
  cat /sys/device/system/node/node2/meminfo
  Node 2 MemTotal:       33554432 kB
  Node 2 MemFree:               0 kB
  Node 2 MemUsed:        33554432 kB
  Node 2 Active:                0 kB

This patch fixes this problem by reset node managed pages to 0 after
hot-adding a new node.

1. Move reset_managed_pages_done from reset_node_managed_pages() to
   reset_all_zones_managed_pages()
2. Make reset_node_managed_pages() non-static
3. Call reset_node_managed_pages() in hotadd_new_pgdat() after pgdat
   is initialized

Signed-off-by: Tang Chen &lt;tangchen@cn.fujitsu.com&gt;
Signed-off-by: Yasuaki Ishimatsu &lt;isimatu.yasuaki@jp.fujitsu.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
