<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/kernel, branch v2.6.28</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v2.6.28</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v2.6.28'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2008-12-23T23:58:21Z</updated>
<entry>
<title>cgroups: avoid accessing uninitialized data in failure path</title>
<updated>2008-12-23T23:58:21Z</updated>
<author>
<name>Li Zefan</name>
<email>lizf@cn.fujitsu.com</email>
</author>
<published>2008-12-23T21:57:14Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=20ca9b3f4c6dfa0af8dd5b18a64df17eb994b54d'/>
<id>urn:sha1:20ca9b3f4c6dfa0af8dd5b18a64df17eb994b54d</id>
<content type='text'>
If cgroup_get_rootdir() failed, free_cg_links() will be called in the
failure path, but tmp_cg_links hasn't been initialized at that time.

I introduced this bug in the 2.6.27 merge window.

Signed-off-by: Li Zefan &lt;lizf@cn.fujitsu.com&gt;
Acked-by: Serge Hallyn &lt;serue@us.ibm.com&gt;
Cc: Paul Menage &lt;menage@google.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>cgroups: suppress bogus warning messages</title>
<updated>2008-12-23T23:58:21Z</updated>
<author>
<name>Sharyathi Nagesh</name>
<email>sharyath@in.ibm.com</email>
</author>
<published>2008-12-23T21:57:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e368d3a836797ddf193b1ec18c97407a791d2451'/>
<id>urn:sha1:e368d3a836797ddf193b1ec18c97407a791d2451</id>
<content type='text'>
Remove spurious warning messages that are thrown onto the console during
cgroup operations.

Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Sharyathi Nagesh &lt;sharyathi@in.ibm.com&gt;
Acked-by: Serge E. Hallyn &lt;serge@hallyn.com&gt;
Cc: Paul Menage &lt;menage@google.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Null pointer deref with hrtimer_try_to_cancel()</title>
<updated>2008-12-20T22:13:45Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2008-12-20T20:27:34Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3d44cc3e01ee1b40317f79ed54324e25c4f848df'/>
<id>urn:sha1:3d44cc3e01ee1b40317f79ed54324e25c4f848df</id>
<content type='text'>
Impact: Prevent kernel crash with posix timer clockid CLOCK_MONOTONIC_RAW

commit 2d42244ae71d6c7b0884b5664cf2eda30fb2ae68 (clocksource:
introduce CLOCK_MONOTONIC_RAW) introduced a new clockid, which is only
available to read out the raw not NTP adjusted system time.

The above commit did not prevent that a posix timer can be created
with that clockid. The timer_create() syscall succeeds and initializes
the timer to a non existing hrtimer base. When the timer is deleted
either by timer_delete() or by the exit() cleanup the kernel crashes.

Prevent the creation of timers for CLOCK_MONOTONIC_RAW by setting the
posix clock function to no_timer_create which returns an error code.

Reported-and-tested-by: Eric Sesterhenn &lt;snakebyte@gmx.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>cgroups: fix a race between rmdir and remount</title>
<updated>2008-12-16T00:27:07Z</updated>
<author>
<name>Paul Menage</name>
<email>menage@google.com</email>
</author>
<published>2008-12-15T21:54:22Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=307257cf475aac25db30b669987f13d90c934e3a'/>
<id>urn:sha1:307257cf475aac25db30b669987f13d90c934e3a</id>
<content type='text'>
When a cgroup is removed, it's unlinked from its parent's children list,
but not actually freed until the last dentry on it is released (at which
point cgrp-&gt;root-&gt;number_of_cgroups is decremented).

Currently rebind_subsystems checks for the top cgroup's child list being
empty in order to rebind subsystems into or out of a hierarchy - this can
result in the set of subsystems bound to a hierarchy being
removed-but-not-freed cgroup.

The simplest fix for this is to forbid remounts that change the set of
subsystems on a hierarchy that has removed-but-not-freed cgroups.  This
bug can be reproduced via:

mkdir /mnt/cg
mount -t cgroup -o ns,freezer cgroup /mnt/cg
mkdir /mnt/cg/foo
sleep 1h &lt; /mnt/cg/foo &amp;
rmdir /mnt/cg/foo
mount -t cgroup -o remount,ns,devices,freezer cgroup /mnt/cg
kill $!

Though the above will cause oops in -mm only but not mainline, but the bug
can cause memory leak in mainline (and even oops)

Signed-off-by: Paul Menage &lt;menage@google.com&gt;
Reviewed-by: Li Zefan &lt;lizf@cn.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;
</content>
</entry>
<entry>
<title>Revert "sched_clock: prevent scd-&gt;clock from moving backwards"</title>
<updated>2008-12-15T00:23:17Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2008-12-14T23:46:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=ca7e716c7833aeaeb8fedd6d004c5f5d5e14d325'/>
<id>urn:sha1:ca7e716c7833aeaeb8fedd6d004c5f5d5e14d325</id>
<content type='text'>
This reverts commit 5b7dba4ff834259a5623e03a565748704a8fe449, which
caused a regression in hibernate, reported by and bisected by Fabio
Comolli.

This revert fixes

 http://bugzilla.kernel.org/show_bug.cgi?id=12155
 http://bugzilla.kernel.org/show_bug.cgi?id=12149

Bisected-by: Fabio Comolli &lt;fabio.comolli@gmail.com&gt;
Requested-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Acked-by: Dave Kleikamp &lt;shaggy@linux.vnet.ibm.com&gt;
Cc: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip</title>
<updated>2008-12-10T22:41:06Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2008-12-10T22:41:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f9fc05e7620b3ffc93eeeda6d02fc70436676152'/>
<id>urn:sha1:f9fc05e7620b3ffc93eeeda6d02fc70436676152</id>
<content type='text'>
* 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  sched: CPU remove deadlock fix
</content>
</entry>
<entry>
<title>fix mapping_writably_mapped()</title>
<updated>2008-12-10T22:40:45Z</updated>
<author>
<name>Hugh Dickins</name>
<email>hugh@veritas.com</email>
</author>
<published>2008-12-10T20:48:52Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b88ed20594db2c685555b68c52b693b75738b2f5'/>
<id>urn:sha1:b88ed20594db2c685555b68c52b693b75738b2f5</id>
<content type='text'>
Lee Schermerhorn noticed yesterday that I broke the mapping_writably_mapped
test in 2.6.7!  Bad bad bug, good good find.

The i_mmap_writable count must be incremented for VM_SHARED (just as
i_writecount is for VM_DENYWRITE, but while holding the i_mmap_lock)
when dup_mmap() copies the vma for fork: it has its own more optimal
version of __vma_link_file(), and I missed this out.  So the count
was later going down to 0 (dangerous) when one end unmapped, then
wrapping negative (inefficient) when the other end unmapped.

The only impact on x86 would have been that setting a mandatory lock on
a file which has at some time been opened O_RDWR and mapped MAP_SHARED
(but not necessarily PROT_WRITE) across a fork, might fail with -EAGAIN
when it should succeed, or succeed when it should fail.

But those architectures which rely on flush_dcache_page() to flush
userspace modifications back into the page before the kernel reads it,
may in some cases have skipped the flush after such a fork - though any
repetitive test will soon wrap the count negative, in which case it will
flush_dcache_page() unnecessarily.

Fix would be a two-liner, but mapping variable added, and comment moved.

Reported-by: Lee Schermerhorn &lt;Lee.Schermerhorn@hp.com&gt;
Signed-off-by: Hugh Dickins &lt;hugh@veritas.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>KSYM_SYMBOL_LEN fixes</title>
<updated>2008-12-10T16:01:54Z</updated>
<author>
<name>Hugh Dickins</name>
<email>hugh@veritas.com</email>
</author>
<published>2008-12-09T21:14:27Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9c24624727f6d6c460e45762a408ca5f5b9b8ef2'/>
<id>urn:sha1:9c24624727f6d6c460e45762a408ca5f5b9b8ef2</id>
<content type='text'>
Miles Lane tailing /sys files hit a BUG which Pekka Enberg has tracked
to my 966c8c12dc9e77f931e2281ba25d2f0244b06949 sprint_symbol(): use
less stack exposing a bug in slub's list_locations() -
kallsyms_lookup() writes a 0 to namebuf[KSYM_NAME_LEN-1], but that was
beyond the end of page provided.

The 100 slop which list_locations() allows at end of page looks roughly
enough for all the other stuff it might print after the symbol before
it checks again: break out KSYM_SYMBOL_LEN earlier than before.

Latencytop and ftrace and are using KSYM_NAME_LEN buffers where they
need KSYM_SYMBOL_LEN buffers, and vmallocinfo a 2*KSYM_NAME_LEN buffer
where it wants a KSYM_SYMBOL_LEN buffer: fix those before anyone copies
them.

[akpm@linux-foundation.org: ftrace.h needs module.h]
Signed-off-by: Hugh Dickins &lt;hugh@veritas.com&gt;
Cc: Christoph Lameter &lt;cl@linux-foundation.org&gt;
Cc Miles Lane &lt;miles.lane@gmail.com&gt;
Acked-by: Pekka Enberg &lt;penberg@cs.helsinki.fi&gt;
Acked-by: Steven Rostedt &lt;srostedt@redhat.com&gt;
Acked-by: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>relayfs: fix infinite loop with splice()</title>
<updated>2008-12-10T16:01:52Z</updated>
<author>
<name>Tom Zanussi</name>
<email>zanussi@comcast.net</email>
</author>
<published>2008-12-09T21:14:10Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=fbb5b7ae4b442f1923513dc6165a66c7a7f29073'/>
<id>urn:sha1:fbb5b7ae4b442f1923513dc6165a66c7a7f29073</id>
<content type='text'>
Running kmemtraced, which uses splice() on relayfs, causes a hard lock on
x86-64 SMP.  As described by Tom Zanussi:

  It looks like you hit the same problem as described here:

  commit 8191ecd1d14c6914c660dfa007154860a7908857

      splice: fix infinite loop in generic_file_splice_read()

  relay uses the same loop but it never got noticed or fixed.

Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@polymtl.ca&gt;
Tested-by: Pekka Enberg &lt;penberg@cs.helsinki.fi&gt;
Signed-off-by: Tom Zanussi &lt;tzanussi@gmail.com&gt;
Signed-off-by: Pekka Enberg &lt;penberg@cs.helsinki.fi&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>sched: CPU remove deadlock fix</title>
<updated>2008-12-09T18:27:03Z</updated>
<author>
<name>Brian King</name>
<email>brking@linux.vnet.ibm.com</email>
</author>
<published>2008-12-09T14:47:00Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9a2bd244e18ffbb96c8b783210fda4eded7c7e6f'/>
<id>urn:sha1:9a2bd244e18ffbb96c8b783210fda4eded7c7e6f</id>
<content type='text'>
Impact: fix possible deadlock in CPU hot-remove path

This patch fixes a possible deadlock scenario in the CPU remove path.
migration_call grabs rq-&gt;lock, then wakes up everything on rq-&gt;migration_queue
with the lock held. Then one of the tasks on the migration queue ends up
calling tg_shares_up which then also tries to acquire the same rq-&gt;lock.

[c000000058eab2e0] c000000000502078 ._spin_lock_irqsave+0x98/0xf0
[c000000058eab370] c00000000008011c .tg_shares_up+0x10c/0x20c
[c000000058eab430] c00000000007867c .walk_tg_tree+0xc4/0xfc
[c000000058eab4d0] c0000000000840c8 .try_to_wake_up+0xb0/0x3c4
[c000000058eab590] c0000000000799a0 .__wake_up_common+0x6c/0xe0
[c000000058eab640] c00000000007ada4 .complete+0x54/0x80
[c000000058eab6e0] c000000000509fa8 .migration_call+0x5fc/0x6f8
[c000000058eab7c0] c000000000504074 .notifier_call_chain+0x68/0xe0
[c000000058eab860] c000000000506568 ._cpu_down+0x2b0/0x3f4
[c000000058eaba60] c000000000506750 .cpu_down+0xa4/0x108
[c000000058eabb10] c000000000507e54 .store_online+0x44/0xa8
[c000000058eabba0] c000000000396260 .sysdev_store+0x3c/0x50
[c000000058eabc10] c0000000001a39b8 .sysfs_write_file+0x124/0x18c
[c000000058eabcd0] c00000000013061c .vfs_write+0xd0/0x1bc
[c000000058eabd70] c0000000001308a4 .sys_write+0x68/0x114
[c000000058eabe30] c0000000000086b4 syscall_exit+0x0/0x40

Signed-off-by: Brian King &lt;brking@linux.vnet.ibm.com&gt;
Acked-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
</feed>
