02 Aug, 2011

4 commits

  • The first packet that gdb sends when the kernel is in kdb mode seems
    to change with every release of gdb. Instead of continuing to add
    many different gdb packets, change kdb to automatically look for any
    thing that looks like a gdb packet.

    Example 1 cold start test:
    echo g > /proc/sysrq-trigger
    $D#44+

    Example 2 cold start test:
    echo g > /proc/sysrq-trigger
    $3#33

    The second one should re-enter kdb's shell right away and is purely a
    test.

    Signed-off-by: Jason Wessel

    Jason Wessel
     
  • The DOING_KGDB2 was originally a state variable for one of the two
    ways to automatically transition from kdb to kgdb. Purge all these
    variables and just use one single state for the transition.

    Signed-off-by: Jason Wessel

    Jason Wessel
     
  • When switching from kdb mode to kgdb mode packets were getting lost
    depending on the size of the fifo queue of the serial chip. When gdb
    initially connects if it is in kdb mode it should entirely send any
    character buffer over to the gdbstub when switching connections.

    Previously kdb was zero'ing out the character buffer and this could
    lead to gdb failing to connect at all, or a lengthy pause could occur
    on the initial connect.

    Signed-off-by: Jason Wessel

    Jason Wessel
     
  • The BTARGS and BTSYMARG variables do not have any function in the
    mainline version of kdb.

    Reported-by: Tim Bird
    Signed-off-by: Jason Wessel

    Jason Wessel
     

22 Jul, 2011

10 commits


21 Jul, 2011

12 commits

  • Signed-off-by: Pavel Shilovsky
    Reviewed-by: Jeff Layton
    Signed-off-by: Steve French

    Pavel Shilovsky
     
  • …l/git/tip/linux-2.6-tip

    * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    signal: align __lock_task_sighand() irq disabling and RCU
    softirq,rcu: Inform RCU of irq_exit() activity
    sched: Add irq_{enter,exit}() to scheduler_ipi()
    rcu: protect __rcu_read_unlock() against scheduler-using irq handlers
    rcu: Streamline code produced by __rcu_read_unlock()
    rcu: Fix RCU_BOOST race handling current->rcu_read_unlock_special
    rcu: decrease rcu_report_exp_rnp coupling with scheduler

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

    * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    sched: Avoid creating superfluous NUMA domains on non-NUMA systems
    sched: Allow for overlapping sched_domain spans
    sched: Break out cpu_power from the sched_group structure

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

    * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    x86. reboot: Make Dell Latitude E6320 use reboot=pci
    x86, doc only: Correct real-mode kernel header offset for init_size
    x86: Disable AMD_NUMA for 32bit for now

    Linus Torvalds
     
  • …ck/linux-2.6-rcu into core/urgent

    Ingo Molnar
     
  • The __lock_task_sighand() function calls rcu_read_lock() with interrupts
    and preemption enabled, but later calls rcu_read_unlock() with interrupts
    disabled. It is therefore possible that this RCU read-side critical
    section will be preempted and later RCU priority boosted, which means that
    rcu_read_unlock() will call rt_mutex_unlock() in order to deboost itself, but
    with interrupts disabled. This results in lockdep splats, so this commit
    nests the RCU read-side critical section within the interrupt-disabled
    region of code. This prevents the RCU read-side critical section from
    being preempted, and thus prevents the attempt to deboost with interrupts
    disabled.

    It is quite possible that a better long-term fix is to make rt_mutex_unlock()
    disable irqs when acquiring the rt_mutex structure's ->wait_lock.

    Signed-off-by: Paul E. McKenney
    Signed-off-by: Paul E. McKenney

    Paul E. McKenney
     
  • The rcu_read_unlock_special() function relies on in_irq() to exclude
    scheduler activity from interrupt level. This fails because exit_irq()
    can invoke the scheduler after clearing the preempt_count() bits that
    in_irq() uses to determine that it is at interrupt level. This situation
    can result in failures as follows:

    $task IRQ SoftIRQ

    rcu_read_lock()

    /* do stuff */

    |= UNLOCK_BLOCKED

    rcu_read_unlock()
    --t->rcu_read_lock_nesting

    irq_enter();
    /* do stuff, don't use RCU */
    irq_exit();
    sub_preempt_count(IRQ_EXIT_OFFSET);
    invoke_softirq()

    ttwu();
    spin_lock_irq(&pi->lock)
    rcu_read_lock();
    /* do stuff */
    rcu_read_unlock();
    rcu_read_unlock_special()
    rcu_report_exp_rnp()
    ttwu()
    spin_lock_irq(&pi->lock) /* deadlock */

    rcu_read_unlock_special(t);

    Ed can simply trigger this 'easy' because invoke_softirq() immediately
    does a ttwu() of ksoftirqd/# instead of doing the in-place softirq stuff
    first, but even without that the above happens.

    Cure this by also excluding softirqs from the
    rcu_read_unlock_special() handler and ensuring the force_irqthreads
    ksoftirqd/# wakeup is done from full softirq context.

    [ Alternatively, delaying the ->rcu_read_lock_nesting decrement
    until after the special handling would make the thing more robust
    in the face of interrupts as well. And there is a separate patch
    for that. ]

    Cc: Thomas Gleixner
    Reported-and-tested-by: Ed Tomlinson
    Signed-off-by: Peter Zijlstra
    Signed-off-by: Paul E. McKenney

    Peter Zijlstra
     
  • Ensure scheduler_ipi() calls irq_{enter,exit} when it does some actual
    work. Traditionally we never did any actual work from the resched IPI
    and all magic happened in the return from interrupt path.

    Now that we do do some work, we need to ensure irq_{enter,exit} are
    called so that we don't confuse things.

    This affects things like timekeeping, NO_HZ and RCU, basically
    everything with a hook in irq_enter/exit.

    Explicit examples of things going wrong are:

    sched_clock_cpu() -- has a callback when leaving NO_HZ state to take
    a new reading from GTOD and TSC. Without this
    callback, time is stuck in the past.

    RCU -- needs in_irq() to work in order to avoid some nasty deadlocks

    Signed-off-by: Peter Zijlstra
    Signed-off-by: Paul E. McKenney

    Peter Zijlstra
     
  • The addition of RCU read-side critical sections within runqueue and
    priority-inheritance lock critical sections introduced some deadlock
    cycles, for example, involving interrupts from __rcu_read_unlock()
    where the interrupt handlers call wake_up(). This situation can cause
    the instance of __rcu_read_unlock() invoked from interrupt to do some
    of the processing that would otherwise have been carried out by the
    task-level instance of __rcu_read_unlock(). When the interrupt-level
    instance of __rcu_read_unlock() is called with a scheduler lock held
    from interrupt-entry/exit situations where in_irq() returns false,
    deadlock can result.

    This commit resolves these deadlocks by using negative values of
    the per-task ->rcu_read_lock_nesting counter to indicate that an
    instance of __rcu_read_unlock() is in flight, which in turn prevents
    instances from interrupt handlers from doing any special processing.
    This patch is inspired by Steven Rostedt's earlier patch that similarly
    made __rcu_read_unlock() guard against interrupt-mediated recursion
    (see https://lkml.org/lkml/2011/7/15/326), but this commit refines
    Steven's approach to avoid the need for preemption disabling on the
    __rcu_read_unlock() fastpath and to also avoid the need for manipulating
    a separate per-CPU variable.

    This patch avoids need for preempt_disable() by instead using negative
    values of the per-task ->rcu_read_lock_nesting counter. Note that nested
    rcu_read_lock()/rcu_read_unlock() pairs are still permitted, but they will
    never see ->rcu_read_lock_nesting go to zero, and will therefore never
    invoke rcu_read_unlock_special(), thus preventing them from seeing the
    RCU_READ_UNLOCK_BLOCKED bit should it be set in ->rcu_read_unlock_special.
    This patch also adds a check for ->rcu_read_unlock_special being negative
    in rcu_check_callbacks(), thus preventing the RCU_READ_UNLOCK_NEED_QS
    bit from being set should a scheduling-clock interrupt occur while
    __rcu_read_unlock() is exiting from an outermost RCU read-side critical
    section.

    Of course, __rcu_read_unlock() can be preempted during the time that
    ->rcu_read_lock_nesting is negative. This could result in the setting
    of the RCU_READ_UNLOCK_BLOCKED bit after __rcu_read_unlock() checks it,
    and would also result it this task being queued on the corresponding
    rcu_node structure's blkd_tasks list. Therefore, some later RCU read-side
    critical section would enter rcu_read_unlock_special() to clean up --
    which could result in deadlock if that critical section happened to be in
    the scheduler where the runqueue or priority-inheritance locks were held.

    This situation is dealt with by making rcu_preempt_note_context_switch()
    check for negative ->rcu_read_lock_nesting, thus refraining from
    queuing the task (and from setting RCU_READ_UNLOCK_BLOCKED) if we are
    already exiting from the outermost RCU read-side critical section (in
    other words, we really are no longer actually in that RCU read-side
    critical section). In addition, rcu_preempt_note_context_switch()
    invokes rcu_read_unlock_special() to carry out the cleanup in this case,
    which clears out the ->rcu_read_unlock_special bits and dequeues the task
    (if necessary), in turn avoiding needless delay of the current RCU grace
    period and needless RCU priority boosting.

    It is still illegal to call rcu_read_unlock() while holding a scheduler
    lock if the prior RCU read-side critical section has ever had either
    preemption or irqs enabled. However, the common use case is legal,
    namely where then entire RCU read-side critical section executes with
    irqs disabled, for example, when the scheduler lock is held across the
    entire lifetime of the RCU read-side critical section.

    Signed-off-by: Paul E. McKenney
    Signed-off-by: Paul E. McKenney

    Paul E. McKenney
     
  • When creating sched_domains, stop when we've covered the entire
    target span instead of continuing to create domains, only to
    later find they're redundant and throw them away again.

    This avoids single node systems from touching funny NUMA
    sched_domain creation code and reduces the risks of the new
    SD_OVERLAP code.

    Requested-by: Linus Torvalds
    Signed-off-by: Peter Zijlstra
    Cc: Anton Blanchard
    Cc: mahesh@linux.vnet.ibm.com
    Cc: benh@kernel.crashing.org
    Cc: linuxppc-dev@lists.ozlabs.org
    Link: http://lkml.kernel.org/r/1311180177.29152.57.camel@twins
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     
  • Allow for sched_domain spans that overlap by giving such domains their
    own sched_group list instead of sharing the sched_groups amongst
    each-other.

    This is needed for machines with more than 16 nodes, because
    sched_domain_node_span() will generate a node mask from the
    16 nearest nodes without regard if these masks have any overlap.

    Currently sched_domains have a sched_group that maps to their child
    sched_domain span, and since there is no overlap we share the
    sched_group between the sched_domains of the various CPUs. If however
    there is overlap, we would need to link the sched_group list in
    different ways for each cpu, and hence sharing isn't possible.

    In order to solve this, allocate private sched_groups for each CPU's
    sched_domain but have the sched_groups share a sched_group_power
    structure such that we can uniquely track the power.

    Reported-and-tested-by: Anton Blanchard
    Signed-off-by: Peter Zijlstra
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Link: http://lkml.kernel.org/n/tip-08bxqw9wis3qti9u5inifh3y@git.kernel.org
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     
  • In order to prepare for non-unique sched_groups per domain, we need to
    carry the cpu_power elsewhere, so put a level of indirection in.

    Reported-and-tested-by: Anton Blanchard
    Signed-off-by: Peter Zijlstra
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Link: http://lkml.kernel.org/n/tip-qkho2byuhe4482fuknss40ad@git.kernel.org
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

20 Jul, 2011

10 commits

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
    ceph: fix file mode calculation

    Linus Torvalds
     
  • * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc:
    davinci: DM365 EVM: fix video input mux bits
    ARM: davinci: Check for NULL return from irq_alloc_generic_chip
    arm: davinci: Fix low level gpio irq handlers' argument

    Linus Torvalds
     
  • I'm running a workload which triggers a lot of swap in a machine with 4
    nodes. After I kill the workload, I found a kswapd livelock. Sometimes
    kswapd3 or kswapd2 are keeping running and I can't access filesystem,
    but most memory is free.

    This looks like a regression since commit 08951e545918c159 ("mm: vmscan:
    correct check for kswapd sleeping in sleeping_prematurely").

    Node 2 and 3 have only ZONE_NORMAL, but balance_pgdat() will return 0
    for classzone_idx. The reason is end_zone in balance_pgdat() is 0 by
    default, if all zones have watermark ok, end_zone will keep 0.

    Later sleeping_prematurely() always returns true. Because this is an
    order 3 wakeup, and if classzone_idx is 0, both balanced_pages and
    present_pages in pgdat_balanced() are 0. We add a special case here.
    If a zone has no page, we think it's balanced. This fixes the livelock.

    Signed-off-by: Shaohua Li
    Acked-by: Mel Gorman
    Cc: Minchan Kim
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Shaohua Li
     
  • Assume that /sys/kernel/debug/dummy64 is debugfs file created by
    debugfs_create_x64().

    # cd /sys/kernel/debug
    # echo 0x1234567812345678 > dummy64
    # cat dummy64
    0x0000000012345678

    # echo 0x80000000 > dummy64
    # cat dummy64
    0xffffffff80000000

    A value larger than INT_MAX cannot be written to the debugfs file created
    by debugfs_create_u64 or debugfs_create_x64 on 32bit machine. Because
    simple_attr_write() uses simple_strtol() for the conversion.

    To fix this, use simple_strtoll() instead.

    Signed-off-by: Akinobu Mita
    Cc: Greg Kroah-Hartman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     
  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
    vfs: fix race in rcu lookup of pruned dentry
    Fix cifs_get_root()

    [ Edited the last commit to get rid of a 'unused variable "seq"'
    warning due to Al editing the patch. - Linus ]

    Linus Torvalds
     
  • Don't update *inode in __follow_mount_rcu() until we'd verified that
    there is mountpoint there. Kudos to Hugh Dickins for catching that
    one in the first place and eventually figuring out the solution (and
    catching a braino in the earlier version of patch).

    Signed-off-by: Linus Torvalds
    Signed-off-by: Al Viro

    Linus Torvalds
     
  • Given some common flag combinations, particularly -Os, gcc will inline
    rcu_read_unlock_special() despite its being in an unlikely() clause.
    Use noinline to prohibit this misoptimization.

    In addition, move the second barrier() in __rcu_read_unlock() so that
    it is not on the common-case code path. This will allow the compiler to
    generate better code for the common-case path through __rcu_read_unlock().

    Suggested-by: Linus Torvalds
    Signed-off-by: Paul E. McKenney
    Acked-by: Mathieu Desnoyers

    Paul E. McKenney
     
  • The RCU_BOOST commits for TREE_PREEMPT_RCU introduced an other-task
    write to a new RCU_READ_UNLOCK_BOOSTED bit in the task_struct structure's
    ->rcu_read_unlock_special field, but, as noted by Steven Rostedt, without
    correctly synchronizing all accesses to ->rcu_read_unlock_special.
    This could result in bits in ->rcu_read_unlock_special being spuriously
    set and cleared due to conflicting accesses, which in turn could result
    in deadlocks between the rcu_node structure's ->lock and the scheduler's
    rq and pi locks. These deadlocks would result from RCU incorrectly
    believing that the just-ended RCU read-side critical section had been
    preempted and/or boosted. If that RCU read-side critical section was
    executed with either rq or pi locks held, RCU's ensuing (incorrect)
    calls to the scheduler would cause the scheduler to attempt to once
    again acquire the rq and pi locks, resulting in deadlock. More complex
    deadlock cycles are also possible, involving multiple rq and pi locks
    as well as locks from multiple rcu_node structures.

    This commit fixes synchronization by creating ->rcu_boosted field in
    task_struct that is accessed and modified only when holding the ->lock
    in the rcu_node structure on which the task is queued (on that rcu_node
    structure's ->blkd_tasks list). This results in tasks accessing only
    their own current->rcu_read_unlock_special fields, making unsynchronized
    access once again legal, and keeping the rcu_read_unlock() fastpath free
    of atomic instructions and memory barriers.

    The reason that the rcu_read_unlock() fastpath does not need to access
    the new current->rcu_boosted field is that this new field cannot
    be non-zero unless the RCU_READ_UNLOCK_BLOCKED bit is set in the
    current->rcu_read_unlock_special field. Therefore, rcu_read_unlock()
    need only test current->rcu_read_unlock_special: if that is zero, then
    current->rcu_boosted must also be zero.

    This bug does not affect TINY_PREEMPT_RCU because this implementation
    of RCU accesses current->rcu_read_unlock_special with irqs disabled,
    thus preventing races on the !SMP systems that TINY_PREEMPT_RCU runs on.

    Maybe-reported-by: Dave Jones
    Maybe-reported-by: Sergey Senozhatsky
    Reported-by: Steven Rostedt
    Signed-off-by: Paul E. McKenney
    Signed-off-by: Paul E. McKenney
    Reviewed-by: Steven Rostedt

    Paul E. McKenney
     
  • PREEMPT_RCU read-side critical sections blocking an expedited grace
    period invoke rcu_report_exp_rnp(). When the last such critical section
    has completed, rcu_report_exp_rnp() invokes the scheduler to wake up the
    task that invoked synchronize_rcu_expedited() -- needlessly holding the
    root rcu_node structure's lock while doing so, thus needlessly providing
    a way for RCU and the scheduler to deadlock.

    This commit therefore releases the root rcu_node structure's lock before
    calling wake_up().

    Reported-by: Ed Tomlinson
    Signed-off-by: Paul E. McKenney

    Paul E. McKenney
     
  • open(2) must always include one of O_RDONLY, O_WRONLY, or O_RDWR. No need
    for any O_APPEND special case.

    Passing O_WRONLY|O_RDWR is undefined according to the man page, but the
    Linux VFS interprets this as O_RDWR, so we'll do the same.

    This fixes open(2) with flags O_RDWR|O_APPEND, which was incorrectly being
    translated to readonly.

    Reported-by: Fyodor Ustinov
    Signed-off-by: Sage Weil

    Sage Weil
     

19 Jul, 2011

4 commits

  • Video input mux settings for tvp7002 and imager inputs were swapped.
    Comment was correct.

    Tested on EVM with tvp7002 input.

    Signed-off-by: Jon Povey
    Acked-by: Manjunath Hadli
    Cc: stable@kernel.org
    Signed-off-by: Sekhar Nori

    Jon Povey
     
  • Avoid NULL dereference of irq_alloc_generic_chip return in low
    memory conditions.

    Signed-off-by: Todd Poynor
    Signed-off-by: Sekhar Nori

    Todd Poynor
     
  • Align unfenced buffers on older hardware to the power-of-two object
    size. The docs suggest that it should be possible to align only to a
    power-of-two tile height, but using the already computed fence size is
    easier and always correct. We also have to make sure that we unbind
    misaligned buffers upon tiling changes.

    In order to prevent a repetition of this bug, we change the interface
    to the alignment computation routines to force the caller to provide
    the requested alignment and size of the GTT binding rather than assume
    the current values on the object.

    Reported-and-tested-by: Sitosfe Wheeler
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36326
    Signed-off-by: Chris Wilson
    Cc: stable@kernel.org
    Reviewed-by: Daniel Vetter
    Signed-off-by: Keith Packard

    Chris Wilson
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
    pppoe: Must flush connections when MAC address changes too.
    include/linux/sdla.h: remove the prototype of sdla()
    tulip: dmfe: Remove old log spamming pr_debugs

    Linus Torvalds