27 Jan, 2009

3 commits

  • …/git/tip/linux-2.6-tip

    * 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    debugobjects: add and use INIT_WORK_ON_STACK
    rcu: remove duplicate CONFIG_RCU_CPU_STALL_DETECTOR
    relay: fix lock imbalance in relay_late_setup_files
    oprofile: fix uninitialized use of struct op_entry
    rcu: move Kconfig menu
    softlock: fix false panic which can occur if softlockup_thresh is reduced
    rcu: add __cpuinit to rcu_init_percpu_data()

    Linus Torvalds
     
  • …el/git/tip/linux-2.6-tip

    * 'timers-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    hrtimers: fix inconsistent lock state on resume in hres_timers_resume
    time-sched.c: tick_nohz_update_jiffies should be static
    locking, hpet: annotate false positive warning
    kernel/fork.c: unused variable 'ret'
    itimers: remove the per-cpu-ish-ness

    Linus Torvalds
     
  • …git/tip/linux-2.6-tip

    * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (29 commits)
    xen: unitialised return value in xenbus_write_transaction
    x86: fix section mismatch warning
    x86: unmask CPUID levels on Intel CPUs, fix
    x86: work around PAGE_KERNEL_WC not getting WC in iomap_atomic_prot_pfn.
    x86: use standard PIT frequency
    xen: handle highmem pages correctly when shrinking a domain
    x86, mm: fix pte_free()
    xen: actually release memory when shrinking domain
    x86: unmask CPUID levels on Intel CPUs
    x86: add MSR_IA32_MISC_ENABLE bits to <asm/msr-index.h>
    x86: fix PTE corruption issue while mapping RAM using /dev/mem
    x86: mtrr fix debug boot parameter
    x86: fix page attribute corruption with cpa()
    Revert "x86: signal: change type of paramter for sys_rt_sigreturn()"
    x86: use early clobbers in usercopy*.c
    x86: remove kernel_physical_mapping_init() from init section
    fix: crash: IP: __bitmap_intersects+0x48/0x73
    cpufreq: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_write
    work_on_cpu: Use our own workqueue.
    work_on_cpu: don't try to get_online_cpus() in work_on_cpu.
    ...

    Linus Torvalds
     

22 Jan, 2009

1 commit


20 Jan, 2009

2 commits

  • 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
    Signed-off-by: Mike Travis
    Signed-off-by: Ingo Molnar

    Rusty Russell
     
  • 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
    Signed-off-by: Mike Travis
    Signed-off-by: Ingo Molnar

    Rusty Russell
     

19 Jan, 2009

2 commits

  • 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: [] retrigger_next_event+0x5c/0xa0
    > [17854.688347] {in-hardirq-W} state was registered at:
    > [17854.688347] [] __lock_acquire+0x79d/0x1930
    > [17854.688347] [] lock_acquire+0x5c/0x80
    > [17854.688347] [] _spin_lock+0x35/0x70
    > [17854.688347] [] hrtimer_run_queues+0x31/0x140
    > [17854.688347] [] run_local_timers+0x8/0x20
    > [17854.688347] [] update_process_times+0x23/0x60
    > [17854.688347] [] tick_periodic+0x24/0x80
    > [17854.688347] [] tick_handle_periodic+0x12/0x70
    > [17854.688347] [] timer_interrupt+0x14/0x20
    > [17854.688347] [] handle_IRQ_event+0x29/0x60
    > [17854.688347] [] handle_level_irq+0x69/0xe0
    > [17854.688347] [] 0xffffffff
    > [17854.688347] irq event stamp: 55771
    > [17854.688347] hardirqs last enabled at (55771): [] _spin_unlock_irqrestore+0x35/0x60
    > [17854.688347] hardirqs last disabled at (55770): [] _spin_lock_irqsave+0x19/0x80
    > [17854.688347] softirqs last enabled at (54836): [] __do_softirq+0xc4/0x110
    > [17854.688347] softirqs last disabled at (54831): [] 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: [] sysfs_write_file+0x25/0x100
    > [17854.688347] #1: (pm_mutex){--..}, at: [] enter_state+0x4f/0x140
    > [17854.688347] #2: (dpm_list_mtx){--..}, at: [] 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] [] ? printk+0x18/0x20
    > [17854.688347] [] print_usage_bug+0x16c/0x1d0
    > [17854.688347] [] mark_lock+0x8bf/0xc90
    > [17854.688347] [] ? pit_next_event+0x2f/0x40
    > [17854.688347] [] __lock_acquire+0x580/0x1930
    > [17854.688347] [] ? _spin_unlock+0x1d/0x20
    > [17854.688347] [] ? pit_next_event+0x2f/0x40
    > [17854.688347] [] ? clockevents_program_event+0x98/0x160
    > [17854.688347] [] ? mark_held_locks+0x48/0x90
    > [17854.688347] [] ? _spin_unlock_irqrestore+0x35/0x60
    > [17854.688347] [] ? trace_hardirqs_on_caller+0x139/0x190
    > [17854.688347] [] ? trace_hardirqs_on+0xb/0x10
    > [17854.688347] [] lock_acquire+0x5c/0x80
    > [17854.688347] [] ? retrigger_next_event+0x5c/0xa0
    > [17854.688347] [] _spin_lock+0x35/0x70
    > [17854.688347] [] ? retrigger_next_event+0x5c/0xa0
    > [17854.688347] [] retrigger_next_event+0x5c/0xa0
    > [17854.688347] [] hres_timers_resume+0xa/0x10
    > [17854.688347] [] timekeeping_resume+0xee/0x150
    > [17854.688347] [] __sysdev_resume+0x14/0x50
    > [17854.688347] [] sysdev_resume+0x47/0x80
    > [17854.688347] [] device_power_up+0xb/0x20
    > [17854.688347] [] suspend_devices_and_enter+0xcf/0x150
    > [17854.688347] [] ? freeze_processes+0x3f/0x90
    > [17854.688347] [] enter_state+0xf4/0x140
    > [17854.688347] [] state_store+0x7d/0xc0
    > [17854.688347] [] ? state_store+0x0/0xc0
    > [17854.688347] [] kobj_attr_store+0x24/0x30
    > [17854.688347] [] sysfs_write_file+0x9c/0x100
    > [17854.688347] [] vfs_write+0x9c/0x160
    > [17854.688347] [] ? restore_nocheck_notrace+0x0/0xe
    > [17854.688347] [] ? sysfs_write_file+0x0/0x100
    > [17854.688347] [] sys_write+0x3d/0x70
    > [17854.688347] [] 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
    Signed-off-by: Peter Zijlstra
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     
  • One fail path in relay_late_setup_files() omits
    mutex_unlock(&relay_channels_mutex);
    Add it.

    Signed-off-by: Jiri Slaby
    Signed-off-by: Ingo Molnar

    Jiri Slaby
     

17 Jan, 2009

3 commits


16 Jan, 2009

5 commits

  • …l/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"

    Linus Torvalds
     
  • 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
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     
  • Move Documentation/cpusets.txt and Documentation/controllers/* to
    Documentation/cgroups/

    Signed-off-by: Li Zefan
    Acked-by: KAMEZAWA Hiroyuki
    Acked-by: Balbir Singh
    Acked-by: Paul Menage
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Li Zefan
     
  • 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
    Signed-off-by: Peter Zijlstra
    Tested-by: Jayson King
    Signed-off-by: Ingo Molnar

    Lin Ming
     
  • 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
    Signed-off-by: Tony Luck

    Doug Chapman
     

15 Jan, 2009

7 commits

  • 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
    Tested-by: Mike Galbraith
    Acked-by: Mike Galbraith
    Cc:
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     
  • 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
    Signed-off-by: Peter Zijlstra
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     
  • 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
    Signed-off-by: Peter Zijlstra
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     
  • 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
    Signed-off-by: Peter Zijlstra
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     
  • 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
    Signed-off-by: Ingo Molnar

    Jaswinder Singh Rajput
     
  • * '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
    ...

    Linus Torvalds
     
  • Fix the sparc build - we were including `up.o' on SMP builds, when
    CONFIG_USE_GENERIC_SMP_HELPERS=n.

    Tested-by: Robert Reif
    Fixed-by: Robert Reif
    Cc: David Miller
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

14 Jan, 2009

17 commits