<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/mm/percpu.c, branch linux-2.6.32.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.32.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.32.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2011-12-21T21:04:52Z</updated>
<entry>
<title>percpu: fix chunk range calculation</title>
<updated>2011-12-21T21:04:52Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2011-11-18T18:55:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f9da6299abdae16617736efb545079ddbfe2e380'/>
<id>urn:sha1:f9da6299abdae16617736efb545079ddbfe2e380</id>
<content type='text'>
commit a855b84c3d8c73220d4d3cd392a7bee7c83de70e upstream.

Percpu allocator recorded the cpus which map to the first and last
units in pcpu_first/last_unit_cpu respectively and used them to
determine the address range of a chunk - e.g. it assumed that the
first unit has the lowest address in a chunk while the last unit has
the highest address.

This simply isn't true.  Groups in a chunk can have arbitrary positive
or negative offsets from the previous one and there is no guarantee
that the first unit occupies the lowest offset while the last one the
highest.

Fix it by actually comparing unit offsets to determine cpus occupying
the lowest and highest offsets.  Also, rename pcu_first/last_unit_cpu
to pcpu_low/high_unit_cpu to avoid confusion.

The chunk address range is used to flush cache on vmalloc area
map/unmap and decide whether a given address is in the first chunk by
per_cpu_ptr_to_phys() and the bug was discovered by invalid
per_cpu_ptr_to_phys() translation for crash_note.

Kudos to Dave Young for tracking down the problem.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: WANG Cong &lt;xiyou.wangcong@gmail.com&gt;
Reported-by: Dave Young &lt;dyoung@redhat.com&gt;
Tested-by: Dave Young &lt;dyoung@redhat.com&gt;
LKML-Reference: &lt;4EC21F67.10905@redhat.com&gt;
Signed-off-by: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>percpu: fix pcpu_last_unit_cpu</title>
<updated>2010-09-27T00:21:27Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2010-09-21T05:57:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=61e0ce1b361c699387029fdda4ba08e6ae4af326'/>
<id>urn:sha1:61e0ce1b361c699387029fdda4ba08e6ae4af326</id>
<content type='text'>
commit 46b30ea9bc3698bc1d1e6fd726c9601d46fa0a91 upstream.

pcpu_first/last_unit_cpu are used to track which cpu has the first and
last units assigned.  This in turn is used to determine the span of a
chunk for man/unmap cache flushes and whether an address belongs to
the first chunk or not in per_cpu_ptr_to_phys().

When the number of possible CPUs isn't power of two, a chunk may
contain unassigned units towards the end of a chunk.  The logic to
determine pcpu_last_unit_cpu was incorrect when there was an unused
unit at the end of a chunk.  It failed to ignore the unused unit and
assigned the unused marker NR_CPUS to pcpu_last_unit_cpu.

This was discovered through kdump failure which was caused by
malfunctioning per_cpu_ptr_to_phys() on a kvm setup with 50 possible
CPUs by CAI Qian.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: CAI Qian &lt;caiqian@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>percpu: restructure pcpu_extend_area_map() to fix bugs and improve readability</title>
<updated>2009-11-12T15:55:35Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2009-11-11T06:35:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=833af8427be4b217b5bc522f61afdbd3f1d282c2'/>
<id>urn:sha1:833af8427be4b217b5bc522f61afdbd3f1d282c2</id>
<content type='text'>
pcpu_extend_area_map() had the following two bugs.

* It should return 1 if pcpu_lock was dropped and reacquired but it
  returned 0.  This could lead to oops if free_percpu() races with
  area map extension.

* pcpu_mem_free() was called under pcpu_lock.  pcpu_mem_free() might
  end up calling vfree() which isn't IRQ safe.  This could lead to
  deadlock through lock order inversion via IRQ.

In addition, Linus pointed out that the temporary lock dropping and
subtle three-way return value of pcpu_extend_area_map() was very ugly
and suggested to split the function into two - pcpu_need_to_extend()
and pcpu_extend_area_map().

This patch restructures pcpu_extend_area_map() as suggested and fixes
the two bugs.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Acked-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>percpu: allow pcpu_alloc() to be called with IRQs off</title>
<updated>2009-10-28T15:25:59Z</updated>
<author>
<name>Jiri Kosina</name>
</author>
<published>2009-10-28T15:25:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=403a91b1659cb149dbddc5885f892734ae4542d8'/>
<id>urn:sha1:403a91b1659cb149dbddc5885f892734ae4542d8</id>
<content type='text'>
pcpu_alloc() and pcpu_extend_area_map() perform a series of
spin_lock_irq()/spin_unlock_irq() calls, which make them unsafe
with respect to being called from contexts which have IRQs off.

This patch converts the code to perform save/restore of flags instead,
making pcpu_alloc() (or __alloc_percpu() respectively) to be called
from early kernel startup stage, where IRQs are off.

This is needed for proper initialization of per-cpu rq_weight data from
sched_init().

tj: added comment explaining why irqsave/restore is used in alloc path.

Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Acked-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
</content>
</entry>
<entry>
<title>percpu: fix compile warnings</title>
<updated>2009-10-12T08:04:42Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2009-10-04T00:31:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1a0c3298d6c6bfc357c38772e7f32d193c60c77d'/>
<id>urn:sha1:1a0c3298d6c6bfc357c38772e7f32d193c60c77d</id>
<content type='text'>
Fix the following two compile warnings which show up on i386.

mm/percpu.c:1873: warning: comparison of distinct pointer types lacks a cast
mm/percpu.c:1879: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'size_t'

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Randy Dunlap &lt;randy.dunlap@oracle.com&gt;
</content>
</entry>
<entry>
<title>percpu: make allocation failures more verbose</title>
<updated>2009-09-29T00:17:58Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2009-09-29T00:17:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f2badb0c950ed308be9b321203b9c8d341690cd4'/>
<id>urn:sha1:f2badb0c950ed308be9b321203b9c8d341690cd4</id>
<content type='text'>
Warn and dump stack when percpu allocation fails.  percpu allocator is
still young and unchecked NULL percpu pointer usage can result in
random memory corruption when combined with the pointer shifting in
access macros.  Allocation failures should be rare and the warning
message will be disabled after certain times.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
</content>
</entry>
<entry>
<title>percpu: make pcpu_setup_first_chunk() failures more verbose</title>
<updated>2009-09-29T00:17:57Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2009-09-24T00:43:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=635b75fc18858d3522e481c043de764766db923c'/>
<id>urn:sha1:635b75fc18858d3522e481c043de764766db923c</id>
<content type='text'>
The parameters to pcpu_setup_first_chunk() come from different sources
depending on architecture and can be quite complex.  The function runs
various sanity checks on the parameters and triggers BUG() if
something isn't right.  However, this is very early during the boot
and not reporting exactly what the problem is makes debugging even
harder.

Add PCPU_SETUP_BUG() macro which prints out enough information about
the parameters.  As the macro still puts separate BUG() for each
check, it won't lose any information even on the situations where only
the program counter can be retrieved.

While at it, also bump pcpu_dump_alloc_info() message to KERN_INFO so
that it's visible on the console if boot fails to complete.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
</content>
</entry>
<entry>
<title>percpu: make embedding first chunk allocator check vmalloc space size</title>
<updated>2009-09-29T00:17:57Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2009-09-24T09:46:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6ea529a2037ce662fc6bfa572b46d47407d08805'/>
<id>urn:sha1:6ea529a2037ce662fc6bfa572b46d47407d08805</id>
<content type='text'>
Embedding first chunk allocator maintains the distances between units
in the vmalloc area and thus needs vmalloc space to be larger than the
maximum distances between units; otherwise, it wouldn't be able to
create any dynamic chunks.  This patch makes the embedding first chunk
allocator check vmalloc space size and if the maximum distance between
units is larger than 75% of it, print warning and, if page mapping
allocator is available, fail initialization so that the system falls
back onto it.

This should work around percpu allocation failure problems on certain
sparc64 configurations where distances between NUMA nodes are larger
than the vmalloc area and makes percpu allocator more robust for
future configurations.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
</content>
</entry>
<entry>
<title>percpu: make pcpu_build_alloc_info() clear static buffers</title>
<updated>2009-09-29T00:17:57Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2009-09-24T09:50:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fb59e72e7e10fd9d31f4e522f1b28254c2cc8a6c'/>
<id>urn:sha1:fb59e72e7e10fd9d31f4e522f1b28254c2cc8a6c</id>
<content type='text'>
pcpu_build_alloc_info() may be called multiple times when percpu is
falling back to different first chunk allocator.  Make it clear static
buffers so that they don't contain values from previous runs.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
</content>
</entry>
<entry>
<title>percpu: fix unit_map[] verification in pcpu_setup_first_chunk()</title>
<updated>2009-09-29T00:17:56Z</updated>
<author>
<name>Tejun Heo</name>
</author>
<published>2009-09-29T00:17:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ffe0d5a575459ffe664b0762130b557f826fcace'/>
<id>urn:sha1:ffe0d5a575459ffe664b0762130b557f826fcace</id>
<content type='text'>
pcpu_setup_first_chunk() incorrectly used NR_CPUS as the impossible
unit number while unit number can equal and go over NR_CPUS with
sparse unit map.  This triggers BUG_ON() spuriously on machines which
have non-power-of-two number of cpus.  Use UINT_MAX instead.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-and-tested-by: Tony Vroon &lt;tony@linx.net&gt;
</content>
</entry>
</feed>
