| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Commit 58c6d3dfe436eb8cfb451981d8fdc9044eaf42da ("dma-coherent: catch
oversized requests to dma_alloc_from_coherent()") attempted to add a
sanity check to bail out on allocations larger than the coherent area.
Unfortunately when this was implemented, the fact the coherent area
is tracked in pages rather than bytes was overlooked, which subsequently
broke every single dma_alloc_from_coherent() user, forcing the allocation
silently through generic memory instead.
Signed-off-by: Adrian McMenamin <[email protected] >
Signed-off-by: Paul Mundt <[email protected]>
|
|
Conflicts:
arch/x86/mm/fault.c
|
|
Conflicts:
arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
arch/x86/kernel/tlb_32.c
Merge it here because both the cpumask changes and the ongoing percpu
work is touching the TLB code. The percpu changes take precedence, as
they eliminate tlb_32.c altogether.
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Impact: fix to allow some archs to use the ring buffer
Commits in the ring buffer are checked by pointer arithmetic.
If the calculation is incorrect, then the commits will never take
place and the buffer will simply fill up and report an error.
Each page in the ring buffer has a small header:
struct buffer_data_page {
u64 time_stamp;
local_t commit;
unsigned char data[];
};
Unfortuntely, some of the calculations used sizeof(struct buffer_data_page)
to know the size of the header. But this is incorrect on some archs,
where sizeof(struct buffer_data_page) does not equal
offsetof(struct buffer_data_page, data), and on those archs, the commits
are never processed.
This patch replaces the sizeof with offsetof.
Signed-off-by: Steven Rostedt <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Impact: remove potential clashes with generic kevent workqueue
Annoyingly, some places we want to use work_on_cpu are already in
workqueues. As per Ingo's suggestion, we create a different workqueue
for work_on_cpu.
Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Mike Travis <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Impact: remove potential circular lock dependency with cpu hotplug lock
This has caused more problems than it solved, with a pile of cpu
hotplug locking issues.
Followup patches will get_online_cpus() in callers that need it, but
if they don't do it they're no worse than before when they were using
set_cpus_allowed without locking.
Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Mike Travis <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Lockdep reported some possible circular locking info when we tested cpuset on
NUMA/fake NUMA box.
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-rc1-00224-ga652504 #111
-------------------------------------------------------
bash/2968 is trying to acquire lock:
(events){--..}, at: [<ffffffff8024c8cd>] flush_work+0x24/0xd8
but task is already holding lock:
(cgroup_mutex){--..}, at: [<ffffffff8026ad1e>] cgroup_lock_live_group+0x12/0x29
which lock already depends on the new lock.
......
-------------------------------------------------------
Steps to reproduce:
# mkdir /dev/cpuset
# mount -t cpuset xxx /dev/cpuset
# mkdir /dev/cpuset/0
# echo 0 > /dev/cpuset/0/cpus
# echo 0 > /dev/cpuset/0/mems
# echo 1 > /dev/cpuset/0/memory_migrate
# cat /dev/zero > /dev/null &
# echo $! > /dev/cpuset/0/tasks
This is because async_rebuild_sched_domains has the following lock sequence:
run_workqueue(async_rebuild_sched_domains)
-> do_rebuild_sched_domains -> cgroup_lock
But, attaching tasks when memory_migrate is set has following:
cgroup_lock_live_group(cgroup_tasks_write)
-> do_migrate_pages -> flush_work
This patch fixes it by using a separate workqueue thread.
Signed-off-by: Miao Xie <[email protected]>
Signed-off-by: Lai Jiangshan <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Andrey Borzenkov reported this lockdep assert:
> [17854.688347] =================================
> [17854.688347] [ INFO: inconsistent lock state ]
> [17854.688347] 2.6.29-rc2-1avb #1
> [17854.688347] ---------------------------------
> [17854.688347] inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
> [17854.688347] pm-suspend/18240 [HC0[0]:SC0[0]:HE1:SE1] takes:
> [17854.688347] (&cpu_base->lock){++..}, at: [<c0136fcc>] retrigger_next_event+0x5c/0xa0
> [17854.688347] {in-hardirq-W} state was registered at:
> [17854.688347] [<c01443cd>] __lock_acquire+0x79d/0x1930
> [17854.688347] [<c01455bc>] lock_acquire+0x5c/0x80
> [17854.688347] [<c03092e5>] _spin_lock+0x35/0x70
> [17854.688347] [<c0136e61>] hrtimer_run_queues+0x31/0x140
> [17854.688347] [<c0128d98>] run_local_timers+0x8/0x20
> [17854.688347] [<c0128dd3>] update_process_times+0x23/0x60
> [17854.688347] [<c013e274>] tick_periodic+0x24/0x80
> [17854.688347] [<c013e2e2>] tick_handle_periodic+0x12/0x70
> [17854.688347] [<c0104e24>] timer_interrupt+0x14/0x20
> [17854.688347] [<c01607b9>] handle_IRQ_event+0x29/0x60
> [17854.688347] [<c0161c59>] handle_level_irq+0x69/0xe0
> [17854.688347] [<ffffffff>] 0xffffffff
> [17854.688347] irq event stamp: 55771
> [17854.688347] hardirqs last enabled at (55771): [<c0309125>] _spin_unlock_irqrestore+0x35/0x60
> [17854.688347] hardirqs last disabled at (55770): [<c0309419>] _spin_lock_irqsave+0x19/0x80
> [17854.688347] softirqs last enabled at (54836): [<c0124f54>] __do_softirq+0xc4/0x110
> [17854.688347] softirqs last disabled at (54831): [<c01049ae>] do_softirq+0x8e/0xe0
> [17854.688347]
> [17854.688347] other info that might help us debug this:
> [17854.688347] 3 locks held by pm-suspend/18240:
> [17854.688347] #0: (&buffer->mutex){--..}, at: [<c01dd4c5>] sysfs_write_file+0x25/0x100
> [17854.688347] #1: (pm_mutex){--..}, at: [<c015056f>] enter_state+0x4f/0x140
> [17854.688347] #2: (dpm_list_mtx){--..}, at: [<c027880f>] device_pm_lock+0xf/0x20
> [17854.688347]
> [17854.688347] stack backtrace:
> [17854.688347] Pid: 18240, comm: pm-suspend Not tainted 2.6.29-rc2-1avb #1
> [17854.688347] Call Trace:
> [17854.688347] [<c0306248>] ? printk+0x18/0x20
> [17854.688347] [<c0141fac>] print_usage_bug+0x16c/0x1d0
> [17854.688347] [<c0142bcf>] mark_lock+0x8bf/0xc90
> [17854.688347] [<c0106b8f>] ? pit_next_event+0x2f/0x40
> [17854.688347] [<c01441b0>] __lock_acquire+0x580/0x1930
> [17854.688347] [<c030916d>] ? _spin_unlock+0x1d/0x20
> [17854.688347] [<c0106b8f>] ? pit_next_event+0x2f/0x40
> [17854.688347] [<c013dd38>] ? clockevents_program_event+0x98/0x160
> [17854.688347] [<c0142fe8>] ? mark_held_locks+0x48/0x90
> [17854.688347] [<c0309125>] ? _spin_unlock_irqrestore+0x35/0x60
> [17854.688347] [<c0143229>] ? trace_hardirqs_on_caller+0x139/0x190
> [17854.688347] [<c014328b>] ? trace_hardirqs_on+0xb/0x10
> [17854.688347] [<c01455bc>] lock_acquire+0x5c/0x80
> [17854.688347] [<c0136fcc>] ? retrigger_next_event+0x5c/0xa0
> [17854.688347] [<c03092e5>] _spin_lock+0x35/0x70
> [17854.688347] [<c0136fcc>] ? retrigger_next_event+0x5c/0xa0
> [17854.688347] [<c0136fcc>] retrigger_next_event+0x5c/0xa0
> [17854.688347] [<c013711a>] hres_timers_resume+0xa/0x10
> [17854.688347] [<c013aa8e>] timekeeping_resume+0xee/0x150
> [17854.688347] [<c0273384>] __sysdev_resume+0x14/0x50
> [17854.688347] [<c0273407>] sysdev_resume+0x47/0x80
> [17854.688347] [<c02791ab>] device_power_up+0xb/0x20
> [17854.688347] [<c015043f>] suspend_devices_and_enter+0xcf/0x150
> [17854.688347] [<c0150c2f>] ? freeze_processes+0x3f/0x90
> [17854.688347] [<c0150614>] enter_state+0xf4/0x140
> [17854.688347] [<c01506dd>] state_store+0x7d/0xc0
> [17854.688347] [<c0150660>] ? state_store+0x0/0xc0
> [17854.688347] [<c0202da4>] kobj_attr_store+0x24/0x30
> [17854.688347] [<c01dd53c>] sysfs_write_file+0x9c/0x100
> [17854.688347] [<c019916c>] vfs_write+0x9c/0x160
> [17854.688347] [<c0103494>] ? restore_nocheck_notrace+0x0/0xe
> [17854.688347] [<c01dd4a0>] ? sysfs_write_file+0x0/0x100
> [17854.688347] [<c01992ed>] sys_write+0x3d/0x70
> [17854.688347] [<c0103371>] sysenter_do_call+0x12/0x31
Andrey's analysis:
> timekeeping_resume() is called via class ->resume
> method; and according to comments in sysdev_resume() and
> device_power_up(), they are called with interrupts disabled.
>
> Looking at suspend_enter, irqs *are* disabled at this point.
>
> So it actually looks like something (may be some driver)
> unconditionally enabled irqs in resume path.
Add a debug check to test this theory. If it triggers then it
triggers because the resume code calls it with irqs enabled,
which is a no-no not just for timekeeping_resume(), but also
bad for a number of other resume handlers.
Reported-by: Andrey Borzenkov <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
One fail path in relay_late_setup_files() omits
mutex_unlock(&relay_channels_mutex);
Add it.
Signed-off-by: Jiri Slaby <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Conflicts:
arch/x86/include/asm/pda.h
arch/x86/include/asm/system.h
Also, moved include/asm-x86/stackprotector.h to arch/x86/include/asm.
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Impact: remove potential clashes with generic kevent workqueue
Annoyingly, some places we want to use work_on_cpu are already in
workqueues. As per Ingo's suggestion, we create a different workqueue
for work_on_cpu.
Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Mike Travis <[email protected]>
|
|
Impact: remove potential circular lock dependency with cpu hotplug lock
This has caused more problems than it solved, with a pile of cpu
hotplug locking issues.
Followup patches will get_online_cpus() in callers that need it, but
if they don't do it they're no worse than before when they were using
set_cpus_allowed without locking.
Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Mike Travis <[email protected]>
|
|
Reorder the code in kernel/power/main.c to fix compilation warning
triggered by unsetting CONFIG_SUSPEND.
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Len Brown <[email protected]>
|
|
|
|
Check CONFIG_FREEZER instead of CONFIG_PM because kprobe booster
depends on freeze_processes() and thaw_processes() when CONFIG_PREEMPT=y.
This fixes a linkage error which occurs when CONFIG_PREEMPT=y, CONFIG_PM=y
and CONFIG_FREEZER=n.
Reported-by: Cheng Renquan <[email protected]>
Signed-off-by: Masami Hiramatsu <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Signed-off-by: Len Brown <[email protected]>
|
|
Freezer fails to compile if with the following configuration
settings:
CONFIG_CGROUPS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_MODULES=y
CONFIG_FREEZER=y
CONFIG_PM=y
CONFIG_PM_SLEEP=n
Fix this by making process.o compilation depend on CONFIG_FREEZER.
Reported-by: Cheng Renquan <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Len Brown <[email protected]>
|
|
Provide a shared interrupt debug facility under CONFIG_DEBUG_SHIRQ:
it uses the existing irqpoll facilities to iterate through all
registered interrupt handlers and call those which can handle shared
IRQ lines.
This can be handy for suspend/resume debugging: if we call this function
early during resume we can trigger crashes in those drivers which have
incorrect assumptions about when exactly their ISRs will be called
during suspend/resume.
Signed-off-by: Ingo Molnar <[email protected]>
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
sched: sched_slice() fixlet
sched: fix update_min_vruntime
sched: SCHED_OTHER vs SCHED_IDLE isolation
sched: SCHED_IDLE weight change
sched: fix bandwidth validation for UID grouping
Revert "sched: improve preempt debugging"
|
|
Fix __request_region() parameter kernel-doc notation and parameter name:
Warning(linux-2.6.28-git10//kernel/resource.c:627): No description found for parameter 'flags'
Signed-off-by: Randy Dunlap <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Move Documentation/cpusets.txt and Documentation/controllers/* to
Documentation/cgroups/
Signed-off-by: Li Zefan <[email protected]>
Acked-by: KAMEZAWA Hiroyuki <[email protected]>
Acked-by: Balbir Singh <[email protected]>
Acked-by: Paul Menage <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Mike's change: 0a582440f "sched: fix sched_slice())" broke group
scheduling by forgetting to reload cfs_rq on each loop.
This patch fixes aim7 regression and specjbb2005 regression becomes
less than 1.5% on 8-core stokley.
Signed-off-by: Lin Ming <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Tested-by: Jayson King <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Often the cause of kernel unaligned access warnings is not
obvious from just the ip displayed in the warning. This adds
the option via proc to dump the stack in addition to the warning.
The default is off (just display the 1 line warning). To enable
the stack to be shown: echo 1 > /proc/sys/kernel/unaligned-dump-stack
Signed-off-by: Doug Chapman <[email protected]>
Signed-off-by: Tony Luck <[email protected]>
|
|
|
|
Impact: fix SCHED_IDLE latency problems
OK, so we have 1 running task A (which is obviously curr and the tree is
equally obviously empty).
'A' nicely chugs along, doing its thing, carrying min_vruntime along as it
goes.
Then some whacko speed freak SCHED_IDLE task gets inserted due to SMP
balancing, which is very likely far right, in that case
update_curr
update_min_vruntime
cfs_rq->rb_leftmost := true (the crazy task sitting in a tree)
vruntime = se->vruntime
and voila, min_vruntime is waaay right of where it ought to be.
OK, so why did I write it like that to begin with...
Aah, yes.
Say we've just dequeued current
schedule
deactivate_task(prev)
dequeue_entity
update_min_vruntime
Then we'll set
vruntime = cfs_rq->min_vruntime;
we find !cfs_rq->curr, but do find someone in the tree. Then we _must_
do vruntime = se->vruntime, because
vruntime = min_vruntime(vruntime := cfs_rq->min_vruntime, se->vruntime)
will not advance vruntime, and cause lags the other way around (which we
fixed with that initial patch: 1af5f730fc1bf7c62ec9fb2d307206e18bf40a69
(sched: more accurate min_vruntime accounting).
Signed-off-by: Peter Zijlstra <[email protected]>
Tested-by: Mike Galbraith <[email protected]>
Acked-by: Mike Galbraith <[email protected]>
Cc: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Stronger SCHED_IDLE isolation:
- no SCHED_IDLE buddies
- never let SCHED_IDLE preempt on wakeup
- always preempt SCHED_IDLE on wakeup
- limit SLEEPER fairness for SCHED_IDLE.
Signed-off-by: Mike Galbraith <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Increase the SCHED_IDLE weight from 2 to 3, this gives much more stable
vruntime numbers.
time advanced in 100ms:
weight=2
64765.988352
67012.881408
88501.412352
weight=3
35496.181411
34130.971298
35497.411573
Signed-off-by: Mike Galbraith <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Impact: make rt-limit tunables work again
Mark Glines reported:
> I've got an issue on x86-64 where I can't configure the system to allow
> RT tasks for a non-root user.
>
> In 2.6.26.5, I was able to do the following to set things up nicely:
> echo 450000 >/sys/kernel/uids/0/cpu_rt_runtime
> echo 450000 >/sys/kernel/uids/1000/cpu_rt_runtime
>
> Seems like every value I try to echo into the /sys files returns EINVAL.
For UID grouping we initialize the root group with infinite bandwidth
which by default is actually more than the global limit, therefore the
bandwidth check always fails.
Because the root group is a phantom group (for UID grouping) we cannot
runtime adjust it, therefore we let it reflect the global bandwidth
settings.
Reported-by: Mark Glines <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
|
|
Impact: cleanup, reduce kernel size a bit, avoid sparse warning
Fixes sparse warning:
kernel/time/tick-sched.c:137:6: warning: symbol 'tick_nohz_update_jiffies' was not declared. Should it be static?
Signed-off-by: Jaswinder Singh Rajput <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
* 'syscalls' of git://git390.osdl.marist.edu/pub/scm/linux-2.6: (44 commits)
[CVE-2009-0029] s390 specific system call wrappers
[CVE-2009-0029] System call wrappers part 33
[CVE-2009-0029] System call wrappers part 32
[CVE-2009-0029] System call wrappers part 31
[CVE-2009-0029] System call wrappers part 30
[CVE-2009-0029] System call wrappers part 29
[CVE-2009-0029] System call wrappers part 28
[CVE-2009-0029] System call wrappers part 27
[CVE-2009-0029] System call wrappers part 26
[CVE-2009-0029] System call wrappers part 25
[CVE-2009-0029] System call wrappers part 24
[CVE-2009-0029] System call wrappers part 23
[CVE-2009-0029] System call wrappers part 22
[CVE-2009-0029] System call wrappers part 21
[CVE-2009-0029] System call wrappers part 20
[CVE-2009-0029] System call wrappers part 19
[CVE-2009-0029] System call wrappers part 18
[CVE-2009-0029] System call wrappers part 17
[CVE-2009-0029] System call wrappers part 16
[CVE-2009-0029] System call wrappers part 15
...
|
|
This reverts commit ad7a953c522ceb496611d127e51e278bfe0ff483.
And commit: ("allow stripping of generated symbols under CONFIG_KALLSYMS_ALL")
9bb482476c6c9d1ae033306440c51ceac93ea80c
These stripping patches has caused a set of issues:
1) People have reported compatibility issues with binutils due to
lack of support for `--strip-unneeded-symbols' with objcopy 2.15.92.0.2
Reported by: Wenji
2) ccache and distcc no longer works as expeced
Reported by: Ted, Roland, + others
3) The installed modules increased a lot in size
Reported by: Ted, Davej + others
Reported-by: Wenji Huang <[email protected]>
Reported-by: "Theodore Ts'o" <[email protected]>
Reported-by: Dave Jones <[email protected]>
Reported-by: Roland McGrath <[email protected]>
Signed-off-by: Sam Ravnborg <[email protected]>
|
|
Fix the sparc build - we were including `up.o' on SMP builds, when
CONFIG_USE_GENERIC_SMP_HELPERS=n.
Tested-by: Robert Reif <[email protected]>
Fixed-by: Robert Reif <[email protected]>
Cc: David Miller <[email protected]>
Cc: Ingo Molnar <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|
|
Signed-off-by: Heiko Carstens <[email protected]>
|