17 Mar, 2008

4 commits

  • If subbuf_pages was larger than the max number of pages the pipe
    buffer will hold, subbuf_splice_actor() would happily go beyond
    the array size.

    Signed-off-by: Jens Axboe

    Jens Axboe
     
  • no longer working for some time.

    A driver that had been marked as BROKEN for such a long time seems to be
    unlikely to be revived in the forseeable future.

    But if anyone wants to ever revive this driver, the code is still present in
    the older kernel releases.

    Signed-off-by: Adrian Bunk
    Acked-by: Alan Cox
    Cc: Jens Axboe
    Signed-off-by: Andrew Morton
    Signed-off-by: Jens Axboe

    Adrian Bunk
     
  • Linus Torvalds
     
  • * 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6:
    [PARISC] make ptr_to_pide() static
    [PARISC] head.S: section mismatch fixes
    [PARISC] add back Crestone Peak cpu
    [PARISC] futex: special case cmpxchg NULL in kernel space
    [PARISC] clean up show_stack
    [PARISC] add pa8900 CPUs to hardware inventory
    [PARISC] clean up include/asm-parisc/elf.h
    [PARISC] move defconfig to arch/parisc/configs/
    [PARISC] add back AD1889 MAINTAINERS entry
    [PARISC] pdc_console: fix bizarre panic on boot
    [PARISC] dump_stack in show_regs
    [PARISC] pdc_stable: fix compile errors
    [PARISC] remove unused pdc_iodc_printf function
    [PARISC] bump __NR_syscalls
    [PARISC] unbreak pgalloc.h
    [PARISC] move VMALLOC_* definitions to fixmap.h
    [PARISC] wire up timerfd syscalls
    [PARISC] remove old timerfd syscall

    Linus Torvalds
     

16 Mar, 2008

21 commits


15 Mar, 2008

10 commits

  • Use the existing calc_delta_mine() calculation for sched_slice(). This
    saves a divide and simplifies the code because we share it with the
    other /cfs_rq->load users.

    It also improves code size:

    text data bss dec hex filename
    42659 2740 144 45543 b1e7 sched.o.before
    42093 2740 144 44977 afb1 sched.o.after

    Signed-off-by: Ingo Molnar
    Signed-off-by: Peter Zijlstra

    Ingo Molnar
     
  • Fair sleepers need to scale their latency target down by runqueue
    weight. Otherwise busy systems will gain ever larger sleep bonus.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Peter Zijlstra

    Ingo Molnar
     
  • Currently we schedule to the leftmost task in the runqueue. When the
    runtimes are very short because of some server/client ping-pong,
    especially in over-saturated workloads, this will cycle through all
    tasks trashing the cache.

    Reduce cache trashing by keeping dependent tasks together by running
    newly woken tasks first. However, by not running the leftmost task first
    we could starve tasks because the wakee can gain unlimited runtime.

    Therefore we only run the wakee if its within a small
    (wakeup_granularity) window of the leftmost task. This preserves
    fairness, but does alternate server/client task groups.

    Signed-off-by: Peter Zijlstra
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     
  • lw->weight can be 0 for a short time during bootup.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Peter Zijlstra

    Ingo Molnar
     
  • Clear the cached inverse value when updating load. This is needed for
    calc_delta_mine() to work correctly when using the rq load.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Peter Zijlstra

    Ingo Molnar
     
  • Current min_vruntime tracking is incorrect and will cause serious
    problems when we don't run the leftmost task for some reason.

    min_vruntime does two things; 1) it's used to determine a forward
    direction when the u64 vruntime wraps, 2) it's used to track the
    leftmost vruntime to position newly enqueued tasks from.

    The current logic advances min_vruntime whenever the current task's
    vruntime advance. Because the current task may pass the leftmost task
    still waiting we're failing the second goal. This causes new tasks to be
    placed too far ahead and thus penalizes their runtime.

    Fix this by making min_vruntime the min_vruntime of the waiting tasks by
    tracking it in enqueue/dequeue, and compare against current's vruntime
    to obtain the absolute minimum when placing new tasks.

    Signed-off-by: Peter Zijlstra
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     
  • Fix a hard to trigger crash seen in the -rt kernel that also affects
    the vanilla scheduler.

    There is a race condition between schedule() and some dequeue/enqueue
    functions; rt_mutex_setprio(), __setscheduler() and sched_move_task().

    When scheduling to idle, idle_balance() is called to pull tasks from
    other busy processor. It might drop the rq lock. It means that those 3
    functions encounter on_rq=0 and running=1. The current task should be
    put when running.

    Here is a possible scenario:

    CPU0 CPU1
    | schedule()
    | ->deactivate_task()
    | ->idle_balance()
    | -->load_balance_newidle()
    rt_mutex_setprio() |
    | --->double_lock_balance()
    *get lock *rel lock
    * on_rq=0, ruuning=1 |
    * sched_class is changed |
    *rel lock *get lock
    : |
    :
    ->put_prev_task_rt()
    ->pick_next_task_fair()
    => panic

    The current process of CPU1(P1) is scheduling. Deactivated P1, and the
    scheduler looks for another process on other CPU's runqueue because CPU1
    will be idle. idle_balance(), load_balance_newidle() and
    double_lock_balance() are called and double_lock_balance() could drop
    the rq lock. On the other hand, CPU0 is trying to boost the priority of
    P1. The result of boosting only P1's prio and sched_class are changed to
    RT. The sched entities of P1 and P1's group are never put. It makes
    cfs_rq invalid, because the cfs_rq has curr and no leaf, but
    pick_next_task_fair() is called, then the kernel panics.

    Signed-off-by: Hiroshi Shimamoto
    Signed-off-by: Peter Zijlstra
    Signed-off-by: Ingo Molnar

    Hiroshi Shimamoto
     
  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
    firewire: fw-ohci: shut up false compiler warning on PPC32
    firewire: fw-ohci: use dma_alloc_coherent for ar_buffer
    ieee1394: sbp2: fix for SYM13FW500 bridge (Datafab disk)
    firewire: fw-sbp2: fix for SYM13FW500 bridge (Datafab disk)
    firewire: update Kconfig help text
    firewire: warn on fatal condition in topology code
    firewire: fw-sbp2: set single-phase retry_limit
    firewire: fw-ohci: Apple UniNorth 1st generation support
    firewire: fw-ohci: PPC PMac platform code
    firewire: endianess annotations
    firewire: endianess fix

    Linus Torvalds
     
  • This bug was always here, but before my commit 6fa02839bf9412e18e77
    ("recheck for secure ports in fh_verify"), it could only be triggered by
    failure of a kmalloc(). After that commit it could be triggered by a
    client making a request from a non-reserved port for access to an export
    marked "secure". (Exports are "secure" by default.)

    The result is a struct svc_export with a reference count one too low,
    resulting in likely oopses next time the export is accessed.

    The reference counting here is not straightforward; a later patch will
    clean up fh_verify().

    Thanks to Lukas Hejtmanek for the bug report and followup.

    Signed-off-by: J. Bruce Fields
    Cc: Lukas Hejtmanek
    Signed-off-by: Linus Torvalds

    J. Bruce Fields
     
  • The comments in the definition of struct export_operations don't match the
    current members.

    Add a comment for the 2 new functions and remove 2 comments for unused ones.

    Signed-off-by: Marc Dionne
    Acked-by: David Howells
    Acked-by: Christoph Hellwig
    Signed-off-by: Linus Torvalds

    Marc Dionne
     

14 Mar, 2008

5 commits