linux-stable.git/kernel, branch v3.9.5

cgroup: fix a subtle bug in descendant pre-order walk

2013-06-07T19:53:07+00:00

commit 7805d000db30a3787a4c969bab6ae4d8a5fd8ce6 upstream.

When cgroup_next_descendant_pre() initiates a walk, it checks whether
the subtree root doesn't have any children and if not returns NULL.
Later code assumes that the subtree isn't empty.  This is broken
because the subtree may become empty inbetween, which can lead to the
traversal escaping the subtree by walking to the sibling of the
subtree root.

There's no reason to have the early exit path.  Remove it along with
the later assumption that the subtree isn't empty.  This simplifies
the code a bit and fixes the subtle bug.

While at it, fix the comment of cgroup_for_each_descendant_pre() which
was incorrectly referring to ->css_offline() instead of
->css_online().

Signed-off-by: Tejun Heo 
Reviewed-by: Michal Hocko 
Signed-off-by: Greg Kroah-Hartman

cgroup: initialize xattr before calling d_instantiate()

2013-06-07T19:53:05+00:00

commit d6cbf35dac8a3dadb9103379820c96d7c85df3d9 upstream.

cgroup_create_file() calls d_instantiate(), which may decide to look
at the xattrs on the file. Smack always does this and SELinux can be
configured to do so.

But cgroup_add_file() didn't initialize xattrs before calling
cgroup_create_file(), which finally leads to dereferencing NULL
dentry->d_fsdata.

This bug has been there since cgroup xattr was introduced.

Reported-by: Ivan Bulatovic 
Reported-by: Casey Schaufler 
Signed-off-by: Li Zefan 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

module: don't unlink the module until we've removed all exposure.

2013-06-07T19:52:48+00:00

commit 944a1fa01266aa9ace607f29551b73c41e9440e9 upstream.

Otherwise we get a race between unload and reload of the same module:
the new module doesn't see the old one in the list, but then fails because
it can't register over the still-extant entries in sysfs:

 [  103.981925] ------------[ cut here ]------------
 [  103.986902] WARNING: at fs/sysfs/dir.c:536 sysfs_add_one+0xab/0xd0()
 [  103.993606] Hardware name: CrownBay Platform
 [  103.998075] sysfs: cannot create duplicate filename '/module/pch_gbe'
 [  104.004784] Modules linked in: pch_gbe(+) [last unloaded: pch_gbe]
 [  104.011362] Pid: 3021, comm: modprobe Tainted: G        W    3.9.0-rc5+ #5
 [  104.018662] Call Trace:
 [  104.021286]  [] warn_slowpath_common+0x6d/0xa0
 [  104.026933]  [] ? sysfs_add_one+0xab/0xd0
 [  104.031986]  [] ? sysfs_add_one+0xab/0xd0
 [  104.037000]  [] warn_slowpath_fmt+0x2e/0x30
 [  104.042188]  [] sysfs_add_one+0xab/0xd0
 [  104.046982]  [] create_dir+0x5e/0xa0
 [  104.051633]  [] sysfs_create_dir+0x78/0xd0
 [  104.056774]  [] kobject_add_internal+0x83/0x1f0
 [  104.062351]  [] ? kvasprintf+0x46/0x60
 [  104.067231]  [] kobject_add_varg+0x2d/0x50
 [  104.072450]  [] kobject_init_and_add+0x27/0x30
 [  104.078075]  [] mod_sysfs_setup+0x80/0x540
 [  104.083207]  [] ? module_bug_finalize+0x51/0xc0
 [  104.088720]  [] load_module+0x1429/0x18b0

We can teardown sysfs first, then to be sure, put the state in
MODULE_STATE_UNFORMED so it's ignored while we deconstruct it.

Reported-by: Veaceslav Falico 
Tested-by: Veaceslav Falico 
Signed-off-by: Rusty Russell 
Cc: Ben Greear 
Signed-off-by: Greg Kroah-Hartman

x86, range: fix missing merge during add range

2013-06-07T19:52:46+00:00

commit fbe06b7bae7c9cf6ab05168fce5ee93b2f4bae7c upstream.

Christian found v3.9 does not work with E350 with EFI is enabled.

[    1.658832] Trying to unpack rootfs image as initramfs...
[    1.679935] BUG: unable to handle kernel paging request at ffff88006e3fd000
[    1.686940] IP: [] memset+0x1f/0xb0
[    1.692010] PGD 1f77067 PUD 1f7a067 PMD 61420067 PTE 0

but early memtest report all memory could be accessed without problem.

early page table is set in following sequence:
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000] init_memory_mapping: [mem 0x6e600000-0x6e7fffff]
[    0.000000] init_memory_mapping: [mem 0x6c000000-0x6e5fffff]
[    0.000000] init_memory_mapping: [mem 0x00100000-0x6bffffff]
[    0.000000] init_memory_mapping: [mem 0x6e800000-0x6ea07fff]
but later efi_enter_virtual_mode try set mapping again wrongly.
[    0.010644] pid_max: default: 32768 minimum: 301
[    0.015302] init_memory_mapping: [mem 0x640c5000-0x6e3fcfff]
that means it fails with pfn_range_is_mapped.

It turns out that we have a bug in add_range_with_merge and it does not
merge range properly when new add one fill the hole between two exsiting
ranges. In the case when [mem 0x00100000-0x6bffffff] is the hole between
[mem 0x00000000-0x000fffff] and [mem 0x6c000000-0x6e7fffff].

Fix the add_range_with_merge by calling itself recursively.

Reported-by: "Christian König" 
Signed-off-by: Yinghai Lu 
Link: http://lkml.kernel.org/r/CAE9FiQVofGoSk7q5-0irjkBxemqK729cND4hov-1QCBJDhxpgQ@mail.gmail.com
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

audit: Make testing for a valid loginuid explicit.

2013-05-19T18:38:47+00:00

commit 780a7654cee8d61819512385e778e4827db4bfbc upstream.

audit rule additions containing "-F auid!=4294967295" were failing
with EINVAL because of a regression caused by e1760bd.

Apparently some userland audit rule sets want to know if loginuid uid
has been set and are using a test for auid != 4294967295 to determine
that.

In practice that is a horrible way to ask if a value has been set,
because it relies on subtle implementation details and will break
every time the uid implementation in the kernel changes.

So add a clean way to test if the audit loginuid has been set, and
silently convert the old idiom to the cleaner and more comprehensible
new idiom.

RGB notes: In upstream, audit_rule_to_entry has been refactored out.
This is patch is already upstream in functionally the same form in
commit 780a7654cee8d61819512385e778e4827db4bfbc .  The decimal constant
was cast to unsigned to quiet GCC 4.6 32-bit architecture warnings.

Reported-By: Steve Grubb 
Signed-off-by: "Eric W. Biederman" 
Tested-by: Richard Guy Briggs 
Signed-off-by: Eric Paris 
Backported-by: Richard Guy Briggs 
Signed-off-by: Greg Kroah-Hartman

usermodehelper: check subprocess_info->path != NULL

2013-05-19T18:38:45+00:00

commit 264b83c07a84223f0efd0d1db9ccc66d6f88288f upstream.

argv_split(empty_or_all_spaces) happily succeeds, it simply returns
argc == 0 and argv[0] == NULL. Change call_usermodehelper_exec() to
check sub_info->path != NULL to avoid the crash.

This is the minimal fix, todo:

 - perhaps we should change argv_split() to return NULL or change the
   callers.

 - kill or justify ->path[0] check

 - narrow the scope of helper_lock()

Signed-off-by: Oleg Nesterov 
Acked-By: Lucas De Marchi 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

tracing: Fix leaks of filter preds

2013-05-19T18:38:25+00:00

commit 60705c89460fdc7227f2d153b68b3f34814738a4 upstream.

Special preds are created when folding a series of preds that
can be done in serial. These are allocated in an ops field of
the pred structure. But they were never freed, causing memory
leaks.

This was discovered using the kmemleak checker:

unreferenced object 0xffff8800797fd5e0 (size 32):
  comm "swapper/0", pid 1, jiffies 4294690605 (age 104.608s)
  hex dump (first 32 bytes):
    00 00 01 00 03 00 05 00 07 00 09 00 0b 00 0d 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] kmemleak_alloc+0x73/0x98
    [] kmemleak_alloc_recursive.constprop.42+0x16/0x18
    [] __kmalloc+0xd7/0x125
    [] kcalloc.constprop.24+0x2d/0x2f
    [] fold_pred_tree_cb+0xa9/0xf4
    [] walk_pred_tree+0x47/0xcc
    [] replace_preds.isra.20+0x6f8/0x72f
    [] create_filter+0x4e/0x8b
    [] ftrace_test_event_filter+0x5a/0x155
    [] do_one_initcall+0xa0/0x137
    [] kernel_init_freeable+0x14d/0x1dc
    [] kernel_init+0xe/0xdb
    [] ret_from_fork+0x7c/0xb0
    [] 0xffffffffffffffff

Signed-off-by: Steven Rostedt 
Cc: Tom Zanussi 
Signed-off-by: Greg Kroah-Hartman

tick: Cleanup NOHZ per cpu data on cpu down

2013-05-19T18:38:25+00:00

commit 4b0c0f294f60abcdd20994a8341a95c8ac5eeb96 upstream.

Prarit reported a crash on CPU offline/online. The reason is that on
CPU down the NOHZ related per cpu data of the dead cpu is not cleaned
up. If at cpu online an interrupt happens before the per cpu tick
device is registered the irq_enter() check potentially sees stale data
and dereferences a NULL pointer.

Cleanup the data after the cpu is dead.

Reported-by: Prarit Bhargava 
Cc: Mike Galbraith 
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305031451561.2886@ionos
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

timer: Don't reinitialize the cpu base lock during CPU_UP_PREPARE

2013-05-19T18:38:24+00:00

commit 42a5cf46cd56f46267d2a9fcf2655f4078cd3042 upstream.

An inactive timer's base can refer to a offline cpu's base.

In the current code, cpu_base's lock is blindly reinitialized each
time a CPU is brought up. If a CPU is brought online during the period
that another thread is trying to modify an inactive timer on that CPU
with holding its timer base lock, then the lock will be reinitialized
under its feet. This leads to following SPIN_BUG().

<0> BUG: spinlock already unlocked on CPU#3, kworker/u:3/1466
<0> lock: 0xe3ebe000, .magic: dead4ead, .owner: kworker/u:3/1466, .owner_cpu: 1
<4> [] (unwind_backtrace+0x0/0x11c) from [] (do_raw_spin_unlock+0x40/0xcc)
<4> [] (do_raw_spin_unlock+0x40/0xcc) from [] (_raw_spin_unlock+0x8/0x30)
<4> [] (_raw_spin_unlock+0x8/0x30) from [] (mod_timer+0x294/0x310)
<4> [] (mod_timer+0x294/0x310) from [] (queue_delayed_work_on+0x104/0x120)
<4> [] (queue_delayed_work_on+0x104/0x120) from [] (sdhci_msm_bus_voting+0x88/0x9c)
<4> [] (sdhci_msm_bus_voting+0x88/0x9c) from [] (sdhci_disable+0x40/0x48)
<4> [] (sdhci_disable+0x40/0x48) from [] (mmc_release_host+0x4c/0xb0)
<4> [] (mmc_release_host+0x4c/0xb0) from [] (mmc_sd_detect+0x90/0xfc)
<4> [] (mmc_sd_detect+0x90/0xfc) from [] (mmc_rescan+0x7c/0x2c4)
<4> [] (mmc_rescan+0x7c/0x2c4) from [] (process_one_work+0x27c/0x484)
<4> [] (process_one_work+0x27c/0x484) from [] (worker_thread+0x210/0x3b0)
<4> [] (worker_thread+0x210/0x3b0) from [] (kthread+0x80/0x8c)
<4> [] (kthread+0x80/0x8c) from [] (kernel_thread_exit+0x0/0x8)

As an example, this particular crash occurred when CPU #3 is executing
mod_timer() on an inactive timer whose base is refered to offlined CPU
#2.  The code locked the timer_base corresponding to CPU #2. Before it
could proceed, CPU #2 came online and reinitialized the spinlock
corresponding to its base. Thus now CPU #3 held a lock which was
reinitialized. When CPU #3 finally ended up unlocking the old cpu_base
corresponding to CPU #2, we hit the above SPIN_BUG().

CPU #0		CPU #3				       CPU #2
------		-------				       -------
.....		 ......				      
		mod_timer()
		 lock_timer_base
		   spin_lock_irqsave(&base->lock)

cpu_up(2)	 .....				        ......
							init_timers_cpu()
....		 .....				    	spin_lock_init(&base->lock)
.....		   spin_unlock_irqrestore(&base->lock)  ......
		   

Allocation of per_cpu timer vector bases is done only once under
"tvec_base_done[]" check. In the current code, spinlock_initialization
of base->lock isn't under this check. When a CPU is up each time the
base lock is reinitialized. Move base spinlock initialization under
the check.

Signed-off-by: Tirupathi Reddy 
Link: http://lkml.kernel.org/r/1368520142-4136-1-git-send-email-tirupath@codeaurora.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons

2013-05-19T18:38:24+00:00

commit b4f711ee03d28f776fd2324fd0bd999cc428e4d2 upstream.

Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config,
which enables some minor compile time optimization to avoid
uncessary code in mostly the suspend/resume path could cause
problems for userland.

In particular, the dependency for RTC_HCTOSYS on
!ALWAYS_USE_PERSISTENT_CLOCK, which avoids setting the time
twice and simplifies suspend/resume, has the side effect
of causing the /sys/class/rtc/rtcN/hctosys flag to always be
zero, and this flag is commonly used by udev to setup the
/dev/rtc symlink to /dev/rtcN, which can cause pain for
older applications.

While the udev rules could use some work to be less fragile,
breaking userland should strongly be avoided. Additionally
the compile time optimizations are fairly minor, and the code
being optimized is likely to be reworked in the future, so
lets revert this change.

Reported-by: Kay Sievers 
Signed-off-by: John Stultz 
Cc: Feng Tang 
Cc: Jason Gunthorpe 
Link: http://lkml.kernel.org/r/1366828376-18124-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman