06 Oct, 2010

2 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:
    rcu: rcu_read_lock_bh_held(): disabling irqs also disables bh
    generic-ipi: Fix deadlock in __smp_call_function_single

    Linus Torvalds
     
  • With all the recent module loading cleanups, we've minimized the code
    that sits under module_mutex, fixing various deadlocks and making it
    possible to do most of the module loading in parallel.

    However, that whole conversion totally missed the rather obscure code
    that adds a new module to the list for BUG() handling. That code was
    doubly obscure because (a) the code itself lives in lib/bugs.c (for
    dubious reasons) and (b) it gets called from the architecture-specific
    "module_finalize()" rather than from generic code.

    Calling it from arch-specific code makes no sense what-so-ever to begin
    with, and is now actively wrong since that code isn't protected by the
    module loading lock any more.

    So this commit moves the "module_bug_{finalize,cleanup}()" calls away
    from the arch-specific code, and into the generic code - and in the
    process protects it with the module_mutex so that the list operations
    are now safe.

    Future fixups:
    - move the module list handling code into kernel/module.c where it
    belongs.
    - get rid of 'module_bug_list' and just use the regular list of modules
    (called 'modules' - imagine that) that we already create and maintain
    for other reasons.

    Reported-and-tested-by: Thomas Gleixner
    Cc: Rusty Russell
    Cc: Adrian Bunk
    Cc: Andrew Morton
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

02 Oct, 2010

1 commit

  • The kfifo_dma family of functions use sg_mark_end() on the last element in
    their scatterlist. This forces use of a fresh scatterlist for each DMA
    operation, which makes recycling a single scatterlist impossible.

    Change the behavior of the kfifo_dma functions to match the usage of the
    dma_map_sg function. This means that users must respect the returned
    nents value. The sample code is updated to reflect the change.

    This bug is trivial to cause: call kfifo_dma_in_prepare() such that it
    prepares a scatterlist with a single entry comprising the whole fifo.
    This is the case when you map the entirety of a newly created empty fifo.
    This causes the setup_sgl() function to mark the first scatterlist entry
    as the end of the chain, no matter what comes after it.

    Afterwards, add and remove some data from the fifo such that another call
    to kfifo_dma_in_prepare() will create two scatterlist entries. It returns
    nents=2. However, due to the previous sg_mark_end() call, sg_is_last()
    will now return true for the first scatterlist element. This causes the
    sample code to print a single scatterlist element when it should print
    two.

    By removing the call to sg_mark_end(), we make the API as similar as
    possible to the DMA mapping API. All users are required to respect the
    returned nents.

    Signed-off-by: Ira W. Snyder
    Cc: Stefani Seibold
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ira W. Snyder
     

23 Sep, 2010

1 commit

  • The below bug in fork led to the rmap walk finding the parent huge-pmd
    twice instead of just once, because the anon_vma_chain objects of the
    child vma still point to the vma->vm_mm of the parent.

    The patch fixes it by making the rmap walk accurate during fork. It's not
    a big deal normally but it worth being accurate considering the cost is
    the same.

    Signed-off-by: Andrea Arcangeli
    Acked-by: Johannes Weiner
    Acked-by: Rik van Riel
    Acked-by: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrea Arcangeli
     

22 Sep, 2010

2 commits


21 Sep, 2010

1 commit

  • There's a situation where the nohz balancer will try to wake itself:

    cpu-x is idle which is also ilb_cpu
    got a scheduler tick during idle
    and the nohz_kick_needed() in trigger_load_balance() checks for
    rq_x->nr_running which might not be zero (because of someone waking a
    task on this rq etc) and this leads to the situation of the cpu-x
    sending a kick to itself.

    And this can cause a lockup.

    Avoid this by not marking ourself eligible for kicking.

    Signed-off-by: Suresh Siddha
    Signed-off-by: Peter Zijlstra
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     

17 Sep, 2010

2 commits

  • Hardware breakpoints can't be registered within pid namespaces
    because tsk->pid is passed rather than the pid in the current
    namespace.

    (See https://bugzilla.kernel.org/show_bug.cgi?id=17281 )

    This is a quick fix demonstrating the problem but is not the
    best method of solving the problem since passing pids internally
    is not the best way to avoid pid namespace bugs. Subsequent patches
    will show a better solution.

    Much thanks to Frederic Weisbecker for doing
    the bulk of the work finding this bug.

    Reported-by: Robin Green
    Signed-off-by: Matt Helsley
    Signed-off-by: Peter Zijlstra
    Cc: Prasad
    Cc: Arnaldo Carvalho de Melo
    Cc: Steven Rostedt
    Cc: Will Deacon
    Cc: Mahesh Salgaonkar
    Cc: 2.6.33-2.6.35
    LKML-Reference:
    Signed-off-by: Ingo Molnar
    Signed-off-by: Frederic Weisbecker

    Matt Helsley
     
  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
    workqueue: add documentation

    Linus Torvalds
     

15 Sep, 2010

2 commits

  • We have 32-bit variable overflow possibility when multiply in
    task_times() and thread_group_times() functions. When the
    overflow happens then the scaled utime value becomes erroneously
    small and the scaled stime becomes i erroneously big.

    Reported here:

    https://bugzilla.redhat.com/show_bug.cgi?id=633037
    https://bugzilla.kernel.org/show_bug.cgi?id=16559

    Reported-by: Michael Chapman
    Reported-by: Ciriaco Garcia de Celis
    Signed-off-by: Stanislaw Gruszka
    Signed-off-by: Peter Zijlstra
    Cc: Hidetoshi Seto
    Cc: # 2.6.32.19+ (partially) and 2.6.33+
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Stanislaw Gruszka
     
  • compat_alloc_user_space() expects the caller to independently call
    access_ok() to verify the returned area. A missing call could
    introduce problems on some architectures.

    This patch incorporates the access_ok() check into
    compat_alloc_user_space() and also adds a sanity check on the length.
    The existing compat_alloc_user_space() implementations are renamed
    arch_compat_alloc_user_space() and are used as part of the
    implementation of the new global function.

    This patch assumes NULL will cause __get_user()/__put_user() to either
    fail or access userspace on all architectures. This should be
    followed by checking the return value of compat_access_user_space()
    for NULL in the callers, at which time the access_ok() in the callers
    can also be removed.

    Reported-by: Ben Hawkes
    Signed-off-by: H. Peter Anvin
    Acked-by: Benjamin Herrenschmidt
    Acked-by: Chris Metcalf
    Acked-by: David S. Miller
    Acked-by: Ingo Molnar
    Acked-by: Thomas Gleixner
    Acked-by: Tony Luck
    Cc: Andrew Morton
    Cc: Arnd Bergmann
    Cc: Fenghua Yu
    Cc: H. Peter Anvin
    Cc: Heiko Carstens
    Cc: Helge Deller
    Cc: James Bottomley
    Cc: Kyle McMartin
    Cc: Martin Schwidefsky
    Cc: Paul Mackerras
    Cc: Ralf Baechle
    Cc:

    H. Peter Anvin
     

14 Sep, 2010

1 commit

  • Mathieu reported bad latencies with make -j10 kind of kbuild
    workloads - which is mostly caused by us scheduling with a
    too coarse granularity.

    Reduce the minimum granularity some more, to make sure we
    can meet the latency target.

    I got the following results (make -j10 kbuild load, average of 3
    runs):

    vanilla:

    maximum latency: 38278.9 µs
    average latency: 7730.1 µs

    patched:

    maximum latency: 22702.1 µs
    average latency: 6684.8 µs

    Mathieu also measured it:

    |
    | * wakeup-latency.c (SIGEV_THREAD) with make -j10
    |
    | - Mainline 2.6.35.2 kernel
    |
    | maximum latency: 45762.1 µs
    | average latency: 7348.6 µs
    |
    | - With only Peter's smaller min_gran (shown below):
    |
    | maximum latency: 29100.6 µs
    | average latency: 6684.1 µs
    |

    Reported-by: Mathieu Desnoyers
    Reported-by: Linus Torvalds
    Acked-by: Mathieu Desnoyers
    Suggested-by: Peter Zijlstra
    Acked-by: Peter Zijlstra
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

13 Sep, 2010

1 commit

  • Update copyright notice and add Documentation/workqueue.txt.

    Randy Dunlap, Dave Chinner: misc fixes.

    Signed-off-by: Tejun Heo
    Reviewed-By: Florian Mickler
    Cc: Ingo Molnar
    Cc: Christoph Lameter
    Cc: Randy Dunlap
    Cc: Dave Chinner

    Tejun Heo
     

12 Sep, 2010

2 commits

  • * 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6:
    PM / Hibernate: Avoid hitting OOM during preallocation of memory
    PM QoS: Correct pr_debug() misuse and improve parameter checks
    PM: Prevent waiting forever on asynchronous resume after failing suspend

    Linus Torvalds
     
  • There is a problem in hibernate_preallocate_memory() that it calls
    preallocate_image_memory() with an argument that may be greater than
    the total number of available non-highmem memory pages. If that's
    the case, the OOM condition is guaranteed to trigger, which in turn
    can cause significant slowdown to occur during hibernation.

    To avoid that, make preallocate_image_memory() adjust its argument
    before calling preallocate_image_pages(), so that the total number of
    saveable non-highem pages left is not less than the minimum size of
    a hibernation image. Change hibernate_preallocate_memory() to try to
    allocate from highmem if the number of pages allocated by
    preallocate_image_memory() is too low.

    Modify free_unnecessary_pages() to take all possible memory
    allocation patterns into account.

    Reported-by: KOSAKI Motohiro
    Signed-off-by: Rafael J. Wysocki
    Tested-by: M. Vefa Bicakci

    Rafael J. Wysocki
     

11 Sep, 2010

2 commits


10 Sep, 2010

10 commits

  • Just got my 6 way machine to a state where cpu 0 is in an
    endless loop within __smp_call_function_single.
    All other cpus are idle.

    The call trace on cpu 0 looks like this:

    __smp_call_function_single
    scheduler_tick
    update_process_times
    tick_sched_timer
    __run_hrtimer
    hrtimer_interrupt
    clock_comparator_work
    do_extint
    ext_int_handler
    ----> timer irq
    cpu_idle

    __smp_call_function_single() got called from nohz_balancer_kick()
    (inlined) with the remote cpu being 1, wait being 0 and the per
    cpu variable remote_sched_softirq_cb (call_single_data) of the
    current cpu (0).

    Then it loops forever when it tries to grab the lock of the
    call_single_data, since it is already locked and enqueued on cpu 0.

    My theory how this could have happened: for some reason the
    scheduler decided to call __smp_call_function_single() on it's own
    cpu, and sends an IPI to itself. The interrupt stays pending
    since IRQs are disabled. If then the hypervisor schedules the
    cpu away it might happen that upon rescheduling both the IPI and
    the timer IRQ are pending. If then interrupts are enabled again
    it depends which one gets scheduled first.
    If the timer interrupt gets delivered first we end up with the
    local deadlock as seen in the calltrace above.

    Let's make __smp_call_function_single() check if the target cpu is
    the current cpu and execute the function immediately just like
    smp_call_function_single does. That should prevent at least the
    scenario described here.

    It might also be that the scheduler is not supposed to call
    __smp_call_function_single with the remote cpu being the current
    cpu, but that is a different issue.

    Signed-off-by: Heiko Carstens
    Acked-by: Peter Zijlstra
    Acked-by: Jens Axboe
    Cc: Venkatesh Pallipadi
    Cc: Suresh Siddha
    LKML-Reference:
    Signed-off-by: Ingo Molnar

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

    * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    tracing: t_start: reset FTRACE_ITER_HASH in case of seek/pread
    perf symbols: Fix multiple initialization of symbol system
    perf: Fix CPU hotplug
    perf, trace: Fix module leak
    tracing/kprobe: Fix handling of C-unlike argument names
    tracing/kprobes: Fix handling of argument names
    perf probe: Fix handling of arguments names
    perf probe: Fix return probe support
    tracing/kprobe: Fix a memory leak in error case
    tracing: Do not allow llseek to set_ftrace_filter

    Linus Torvalds
     
  • Be sure to avoid entering t_show() with FTRACE_ITER_HASH set without
    having properly started the iterator to iterate the hash. This case is
    degenerate and, as discovered by Robert Swiecki, can cause t_hash_show()
    to misuse a pointer. This causes a NULL ptr deref with possible security
    implications. Tracked as CVE-2010-3079.

    Cc: Robert Swiecki
    Cc: Eugene Teo
    Cc:
    Signed-off-by: Chris Wright
    Signed-off-by: Steven Rostedt

    Chris Wright
     
  • Please revert 2.6.36-rc commit d2997b1042ec150616c1963b5e5e919ffd0b0ebf
    "hibernation: freeze swap at hibernation". It complicated matters by
    adding a second swap allocation path, just for hibernation; without in any
    way fixing the issue that it was intended to address - page reclaim after
    fixing the hibernation image might free swap from a page already imaged as
    swapcache, letting its swap be reallocated to store a different page of
    the image: resulting in data corruption if the imaged page were freed as
    clean then swapped back in. Pages freed to si->swap_map were still in
    danger of being reallocated by the alternative allocation path.

    I guess it inadvertently fixed slow SSD swap allocation for hibernation,
    as reported by Nigel Cunningham: by missing out the discards that occur on
    the usual swap allocation path; but that was unintentional, and needs a
    separate fix.

    Signed-off-by: Hugh Dickins
    Cc: KAMEZAWA Hiroyuki
    Cc: KOSAKI Motohiro
    Cc: "Rafael J. Wysocki"
    Cc: Ondrej Zary
    Cc: Andrea Gelmini
    Cc: Balbir Singh
    Cc: Andrea Arcangeli
    Cc: Nigel Cunningham
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     
  • gid_t is a unsigned int. If group_info contains a gid greater than
    MAX_INT, groups_search() function may look on the wrong side of the search
    tree.

    This solves some unfair "permission denied" problems.

    Signed-off-by: Jerome Marchand
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jerome Marchand
     
  • Add cgroup_attach_task_all()

    The existing cgroup_attach_task_current_cg() API is called by a thread to
    attach another thread to all of its cgroups; this is unsuitable for cases
    where a privileged task wants to attach itself to the cgroups of a less
    privileged one, since the call must be made from the context of the target
    task.

    This patch adds a more generic cgroup_attach_task_all() API that allows
    both the source task and to-be-moved task to be specified.
    cgroup_attach_task_current_cg() becomes a specialization of the more
    generic new function.

    [menage@google.com: rewrote changelog]
    [akpm@linux-foundation.org: address reviewer comments]
    Signed-off-by: Michael S. Tsirkin
    Tested-by: Alex Williamson
    Acked-by: Paul Menage
    Cc: Li Zefan
    Cc: Ben Blum
    Cc: Sridhar Samudrala
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael S. Tsirkin
     
  • The gcov-kernel infrastructure expects that each object file is loaded
    only once. This may not be true, e.g. when loading multiple kernel
    modules which are linked to the same object file. As a result, loading
    such kernel modules will result in incorrect gcov results while unloading
    will cause a null-pointer dereference.

    This patch fixes these problems by changing the gcov-kernel infrastructure
    so that multiple profiling data sets can be associated with one debugfs
    entry. It applies to 2.6.36-rc1.

    Signed-off-by: Peter Oberparleiter
    Reported-by: Werner Spies
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Oberparleiter
     
  • Currently sched_avg_update() (which updates rt_avg stats in the rq)
    is getting called from scale_rt_power() (in the load balance context)
    which doesn't take rq->lock.

    Fix it by moving the sched_avg_update() to more appropriate
    update_cpu_load() where the CFS load gets updated as well.

    Signed-off-by: Suresh Siddha
    Signed-off-by: Peter Zijlstra
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     
  • Since we have UP_PREPARE, we should also have UP_CANCELED.

    Signed-off-by: Peter Zijlstra
    Cc: paulus
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     
  • Commit 1c024eca (perf, trace: Optimize tracepoints by using
    per-tracepoint-per-cpu hlist to track events) caused a module
    refcount leak.

    Reported-And-Tested-by: Avi Kivity
    Signed-off-by: Peter Zijlstra
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Li Zefan
     

09 Sep, 2010

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:
    gcc-4.6: kernel/*: Fix unused but set warnings
    mutex: Fix annotations to include it in kernel-locking docbook
    pid: make setpgid() system call use RCU read-side critical section
    MAINTAINERS: Add RCU's public git tree

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

    * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    perf, x86: Try to handle unknown nmis with an enabled PMU
    perf, x86: Fix handle_irq return values
    perf, x86: Fix accidentally ack'ing a second event on intel perf counter
    oprofile, x86: fix init_sysfs() function stub
    lockup_detector: Sync touch_*_watchdog back to old semantics
    tracing: Fix a race in function profile
    oprofile, x86: fix init_sysfs error handling
    perf_events: Fix time tracking for events with pid != -1 and cpu != -1
    perf: Initialize callchains roots's childen hits
    oprofile: fix crash when accessing freed task structs

    Linus Torvalds
     
  • Reading the file set_ftrace_filter does three things.

    1) shows whether or not filters are set for the function tracer
    2) shows what functions are set for the function tracer
    3) shows what triggers are set on any functions

    3 is independent from 1 and 2.

    The way this file currently works is that it is a state machine,
    and as you read it, it may change state. But this assumption breaks
    when you use lseek() on the file. The state machine gets out of sync
    and the t_show() may use the wrong pointer and cause a kernel oops.

    Luckily, this will only kill the app that does the lseek, but the app
    dies while holding a mutex. This prevents anyone else from using the
    set_ftrace_filter file (or any other function tracing file for that matter).

    A real fix for this is to rewrite the code, but that is too much for
    a -rc release or stable. This patch simply disables llseek on the
    set_ftrace_filter() file for now, and we can do the proper fix for the
    next major release.

    Reported-by: Robert Swiecki
    Cc: Chris Wright
    Cc: Tavis Ormandy
    Cc: Eugene Teo
    Cc: vendor-sec@lst.de
    Cc:
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

08 Sep, 2010

4 commits

  • Check the argument name whether it is invalid (not C-like symbol name). This
    makes event format simple.

    Reported-by: Srikar Dronamraju
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker
    Cc: Ingo Molnar
    Cc: Mathieu Desnoyers
    LKML-Reference:
    Signed-off-by: Masami Hiramatsu
    Signed-off-by: Arnaldo Carvalho de Melo

    Masami Hiramatsu
     
  • Set "argN" name for each argument automatically if it has no specified name.
    Since dynamic trace event(kprobe_events) accepts special characters for its
    argument, its format can show those special characters (e.g. '$', '%', '+').
    However, perf can't parse those format because of the character (especially
    '%') mess up the format. This sets "argX" name for those arguments if user
    omitted the argument names.

    E.g.
    # echo 'p do_fork %ax IP=%ip $stack' > tracing/kprobe_events
    # cat tracing/kprobe_events
    p:kprobes/p_do_fork_0 do_fork arg1=%ax IP=%ip arg3=$stack

    Reported-by: Srikar Dronamraju
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker
    Cc: Ingo Molnar
    Cc: Mathieu Desnoyers
    LKML-Reference:
    Signed-off-by: Masami Hiramatsu
    Signed-off-by: Arnaldo Carvalho de Melo

    Masami Hiramatsu
     
  • Fix a memory leak which happens when a field name conflicts with others. In
    error case, free_trace_probe() will free all arguments until nr_args, so this
    increments nr_args the begining of the loop instead of the end.

    Cc: Steven Rostedt
    Cc: Frederic Weisbecker
    Cc: Ingo Molnar
    Cc: Mathieu Desnoyers
    LKML-Reference:
    Signed-off-by: Masami Hiramatsu
    Signed-off-by: Arnaldo Carvalho de Melo

    Masami Hiramatsu
     
  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
    workqueue: use zalloc_cpumask_var() for gcwq->mayday_mask
    workqueue: fix GCWQ_DISASSOCIATED initialization
    workqueue: Add a workqueue chapter to the tracepoint docbook
    workqueue: fix cwq->nr_active underflow
    workqueue: improve destroy_workqueue() debuggability
    workqueue: mark lock acquisition on worker_maybe_bind_and_lock()
    workqueue: annotate lock context change
    workqueue: free rescuer on destroy_workqueue

    Linus Torvalds
     

05 Sep, 2010

1 commit


03 Sep, 2010

1 commit


01 Sep, 2010

3 commits

  • During my rewrite, the semantics of touch_nmi_watchdog and
    touch_softlockup_watchdog changed enough to break some drivers
    (mostly over preemptable regions).

    These are cases where long delays on one CPU (due to
    print_delay for example) can cause long delays on other
    CPUs - so we must 'touch' the nmi_watchdog flag of those
    other CPUs as well.

    This change brings those touch_*_watchdog() functions back in line
    with to how they used to work.

    Signed-off-by: Don Zickus
    Acked-by: Cyrill Gorcunov
    Cc: peterz@infradead.org
    Cc: fweisbec@gmail.com
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Don Zickus
     
  • [ 23.584719]
    [ 23.584720] ===================================================
    [ 23.585059] [ INFO: suspicious rcu_dereference_check() usage. ]
    [ 23.585176] ---------------------------------------------------
    [ 23.585176] kernel/pid.c:419 invoked rcu_dereference_check() without protection!
    [ 23.585176]
    [ 23.585176] other info that might help us debug this:
    [ 23.585176]
    [ 23.585176]
    [ 23.585176] rcu_scheduler_active = 1, debug_locks = 1
    [ 23.585176] 1 lock held by rc.sysinit/728:
    [ 23.585176] #0: (tasklist_lock){.+.+..}, at: [] sys_setpgid+0x5f/0x193
    [ 23.585176]
    [ 23.585176] stack backtrace:
    [ 23.585176] Pid: 728, comm: rc.sysinit Not tainted 2.6.36-rc2 #2
    [ 23.585176] Call Trace:
    [ 23.585176] [] lockdep_rcu_dereference+0x99/0xa2
    [ 23.585176] [] find_task_by_pid_ns+0x50/0x6a
    [ 23.585176] [] find_task_by_vpid+0x1d/0x1f
    [ 23.585176] [] sys_setpgid+0x67/0x193
    [ 23.585176] [] system_call_fastpath+0x16/0x1b
    [ 24.959669] type=1400 audit(1282938522.956:4): avc: denied { module_request } for pid=766 comm="hwclock" kmod="char-major-10-135" scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclas

    It turns out that the setpgid() system call fails to enter an RCU
    read-side critical section before doing a PID-to-task_struct translation.
    This commit therefore does rcu_read_lock() before the translation, and
    also does rcu_read_unlock() after the last use of the returned pointer.

    Reported-by: Andrew Morton
    Signed-off-by: Paul E. McKenney
    Acked-by: David Howells

    Paul E. McKenney
     
  • While we are reading trace_stat/functionX and someone just
    disabled function_profile at that time, we can trigger this:

    divide error: 0000 [#1] PREEMPT SMP
    ...
    EIP is at function_stat_show+0x90/0x230
    ...

    This fix just takes the ftrace_profile_lock and checks if
    rec->counter is 0. If it's 0, we know the profile buffer
    has been reset.

    Signed-off-by: Li Zefan
    Cc: stable@kernel.org
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Li Zefan
     

31 Aug, 2010

1 commit

  • alloc_mayday_mask() was using alloc_cpumask_var() making
    gcwq->mayday_mask contain garbage after initialization on
    CONFIG_CPUMASK_OFFSTACK=y configurations. This combined with the
    previously fixed GCWQ_DISASSOCIATED initialization bug could make
    rescuers fall into infinite loop trying to bind to an offline cpu.

    Signed-off-by: Tejun Heo
    Reported-by: CAI Qian

    Tejun Heo