14 Jan, 2011

2 commits

  • If the RCU callback-processing kthread has nothing to do, it parks in
    a wait_event(). If RCU remains idle for more than two minutes, the
    kernel complains about this. This commit changes from wait_event()
    to wait_event_interruptible() to prevent the kernel from complaining
    just because RCU is idle.

    Reported-by: Russell King
    Signed-off-by: Paul E. McKenney
    Signed-off-by: Paul E. McKenney
    Tested-by: Thomas Weber
    Tested-by: Russell King

    Paul E. McKenney
     
  • Because the adaptive synchronize_srcu_expedited() approach has
    worked very well in testing, remove the kernel parameter and
    replace it by a C-preprocessor macro. If someone finds problems
    with this approach, a more complex and aggressively adaptive
    approach might be required.

    Longer term, SRCU will be merged with the other RCU implementations,
    at which point synchronize_srcu_expedited() will be event driven,
    just as synchronize_sched_expedited() currently is. At that point,
    there will be no need for this adaptive approach.

    Reported-by: Linus Torvalds
    Signed-off-by: Paul E. McKenney

    Paul E. McKenney
     

23 Dec, 2010

1 commit


22 Dec, 2010

1 commit


21 Dec, 2010

13 commits


20 Dec, 2010

3 commits

  • Linus reported that the new warning introduced by commit f26f9aff6aaf
    "Sched: fix skip_clock_update optimization" triggers. The need_resched
    flag can be set by other CPUs asynchronously so this debug check is
    bogus - remove it.

    Reported-by: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Mike Galbraith
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • …nel.org/pub/scm/linux/kernel/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:
    x86-32: Make sure we can map all of lowmem if we need to
    x86, vt-d: Handle previous faults after enabling fault handling
    x86: Enable the intr-remap fault handling after local APIC setup
    x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode
    x86, vt-d: Quirk for masking vtd spec errors to platform error handling logic
    x86, xsave: Use alloc_bootmem_align() instead of alloc_bootmem()
    bootmem: Add alloc_bootmem_align()
    x86, gcc-4.6: Use gcc -m options when building vdso
    x86: HPET: Chose a paranoid safe value for the ETIME check
    x86: io_apic: Avoid unused variable warning when CONFIG_GENERIC_PENDING_IRQ=n

    * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    perf: Fix off by one in perf_swevent_init()
    perf: Fix duplicate events with multiple-pmu vs software events
    ftrace: Have recordmcount honor endianness in fn_ELF_R_INFO
    scripts/tags.sh: Add magic for trace-events
    tracing: Fix panic when lseek() called on "trace" opened for writing

    Linus Torvalds
     
  • …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: Fix the irqtime code for 32bit
    sched: Fix the irqtime code to deal with u64 wraps
    nohz: Fix get_next_timer_interrupt() vs cpu hotplug
    Sched: fix skip_clock_update optimization
    sched: Cure more NO_HZ load average woes

    Linus Torvalds
     

19 Dec, 2010

3 commits


18 Dec, 2010

17 commits

  • The current tile rt_sigreturn() syscall pattern uses the common idiom
    of loading up pt_regs with all the saved registers from the time of
    the signal, then anticipating the fact that we will clobber the ABI
    "return value" register (r0) as we return from the syscall by setting
    the rt_sigreturn return value to whatever random value was in the pt_regs
    for r0.

    However, this breaks in our 64-bit kernel when running "compat" tasks,
    since we always sign-extend the "return value" register to properly
    handle returned pointers that are in the upper 2GB of the 32-bit compat
    address space. Doing this to the sigreturn path then causes occasional
    random corruption of the 64-bit r0 register.

    Instead, we stop doing the crazy "load the return-value register"
    hack in sigreturn. We already have some sigreturn-specific assembly
    code that we use to pass the pt_regs pointer to C code. We extend that
    code to also set the link register to point to a spot a few instructions
    after the usual syscall return address so we don't clobber the saved r0.
    Now it no longer matters what the rt_sigreturn syscall returns, and the
    pt_regs structure can be cleanly and completely reloaded.

    Signed-off-by: Chris Metcalf

    Chris Metcalf
     
  • Previously we were just setting up the "tp" register in the
    new task as started by clone() in libc. However, this is not
    quite right, since in principle a signal might be delivered to
    the new task before it had its TLS set up. (Of course, this race
    window still exists for resetting the libc getpid() cached value
    in the new task, in principle. But in any case, we are now doing
    this exactly the way all other architectures do it.)

    This change is important for 2.6.37 since the tile glibc we will
    be submitting upstream will not set TLS in user space any more,
    so it will only work on a kernel that has this fix. It should
    also be taken for 2.6.36.x in the stable tree if possible.

    Signed-off-by: Chris Metcalf
    Cc: stable

    Chris Metcalf
     
  • The initial values of the registers 0x01 and 0x17 are taken from the sensor
    table at capture start and updated according to the flag PDN_INV.

    Their values are updated at each step of the capture initialization and
    memorized for reuse in capture stop.

    This patch also fixed automatically some bad hardcoded values of these
    registers.

    Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same
    value as other webcams with the same sensor. For now, only two webcams have
    been so detected: the Microsoft's VX1000 and VX3000.

    Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • Signed-off-by: Jean-François Moine
    Signed-off-by: Mauro Carvalho Chehab

    Jean-Francois Moine
     
  • After Mauro's "bttv: Fix locking issues due to BKL removal code" there
    are a number of comments that are no longer needed about lock ordering.
    Remove them.

    Signed-off-by: Brandon Philips
    Signed-off-by: Mauro Carvalho Chehab

    Brandon Philips
     
  • Fix a regression where bttv driver causes oopses when loading, since it
    were using some non-initialized mutexes. While it would be possible to
    fix the issue, there are some other lock troubles, like to the presence of
    lock code at free_btres_lock().

    It is possible to fix, but the better is to just use the core-assisted
    locking schema. This way, V4L2 core will serialize access to all
    ioctl's/open/close/mmap/read/poll operations, avoiding to have two
    processes accessing the hardware at the same time. Also, as there's just
    one lock, instead of 3, there's no risk of dead locks.

    The net result is a cleaner code, with just one lock.

    Reported-by: Dan Carpenter
    Reported-by: Brandon Philips
    Reported-by: Chris Clayton
    Reported-by: Torsten Kaiser
    Tested-by: Chris Clayton
    Tested-by: Torsten Kaiser
    Signed-off-by: Mauro Carvalho Chehab

    Mauro Carvalho Chehab
     
  • Signed-off-by: Paul E. McKenney

    Paul E. McKenney
     
  • This restores parentheses blance.

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

    Mariusz Kozlowski
     
  • When the current __call_rcu() function was written, the expedited
    APIs did not exist. The __call_rcu() implementation therefore went
    to great lengths to detect the end of old grace periods and to start
    new ones, all in the name of reducing grace-period latency. Now the
    expedited APIs do exist, and the usage of __call_rcu() has increased
    considerably. This commit therefore causes __call_rcu() to avoid
    worrying about grace periods unless there are a large number of
    RCU callbacks stacked up on the current CPU.

    Signed-off-by: Paul E. McKenney

    Paul E. McKenney
     
  • Some recent benchmarks have indicated possible lock contention on the
    leaf-level rcu_node locks. This commit therefore limits the number of
    CPUs per leaf-level rcu_node structure to 16, in other words, there
    can be at most 16 rcu_data structures fanning into a given rcu_node
    structure. Prior to this, the limit was 32 on 32-bit systems and 64 on
    64-bit systems.

    Note that the fanout of non-leaf rcu_node structures is unchanged. The
    organization of accesses to the rcu_node tree is such that references
    to non-leaf rcu_node structures are much less frequent than to the
    leaf structures.

    Signed-off-by: Paul E. McKenney

    Paul E. McKenney
     
  • Use the CPU's bit in rnp->qsmask to determine whether or not the CPU
    should try to report a quiescent state. Handle overflow in the check
    for rdp->gpnum having fallen behind.

    Signed-off-by: Paul E. McKenney

    Paul E. McKenney
     
  • When a CPU that was in an extended quiescent state wakes
    up and catches up with grace periods that remote CPUs
    completed on its behalf, we update the completed field
    but not the gpnum that keeps a stale value of a backward
    grace period ID.

    Later, note_new_gpnum() will interpret the shift between
    the local CPU and the node grace period ID as some new grace
    period to handle and will then start to hunt quiescent state.

    But if every grace periods have already been completed, this
    interpretation becomes broken. And we'll be stuck in clusters
    of spurious softirqs because rcu_report_qs_rdp() will make
    this broken state run into infinite loop.

    The solution, as suggested by Lai Jiangshan, is to ensure that
    the gpnum and completed fields are well synchronized when we catch
    up with completed grace periods on their behalf by other cpus.
    This way we won't start noting spurious new grace periods.

    Suggested-by: Lai Jiangshan
    Signed-off-by: Frederic Weisbecker
    Cc: Paul E. McKenney
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Peter Zijlstra
    Cc: Steven Rostedt

    Frederic Weisbecker
     
  • When a CPU is idle and others CPUs handled its extended
    quiescent state to complete grace periods on its behalf,
    it will catch up with completed grace periods numbers
    when it wakes up.

    But at this point there might be no more grace period to
    complete, but still the woken CPU always keeps its stale
    qs_pending value and will then continue to chase quiescent
    states even if its not needed anymore.

    This results in clusters of spurious softirqs until a new
    real grace period is started. Because if we continue to
    chase quiescent states but we have completed every grace
    periods, rcu_report_qs_rdp() is puzzled and makes that
    state run into infinite loops.

    As suggested by Lai Jiangshan, just reset qs_pending if
    someone completed every grace periods on our behalf.

    Suggested-by: Lai Jiangshan
    Signed-off-by: Frederic Weisbecker
    Cc: Paul E. McKenney
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Peter Zijlstra
    Cc: Steven Rostedt
    Signed-off-by: Paul E. McKenney

    Frederic Weisbecker