1. 06 11月, 2013 5 次提交
  2. 29 10月, 2013 5 次提交
  3. 28 10月, 2013 1 次提交
  4. 26 10月, 2013 1 次提交
  5. 25 10月, 2013 1 次提交
  6. 23 10月, 2013 1 次提交
    • T
      clockevents: Sanitize ticks to nsec conversion · 97b94106
      Thomas Gleixner 提交于
      Marc Kleine-Budde pointed out, that commit 77cc982f "clocksource: use
      clockevents_config_and_register() where possible" caused a regression
      for some of the converted subarchs.
      
      The reason is, that the clockevents core code converts the minimal
      hardware tick delta to a nanosecond value for core internal
      usage. This conversion is affected by integer math rounding loss, so
      the backwards conversion to hardware ticks will likely result in a
      value which is less than the configured hardware limitation. The
      affected subarchs used their own workaround (SIGH!) which got lost in
      the conversion.
      
      The solution for the issue at hand is simple: adding evt->mult - 1 to
      the shifted value before the integer divison in the core conversion
      function takes care of it. But this only works for the case where for
      the scaled math mult/shift pair "mult <= 1 << shift" is true. For the
      case where "mult > 1 << shift" we can apply the rounding add only for
      the minimum delta value to make sure that the backward conversion is
      not less than the given hardware limit. For the upper bound we need to
      omit the rounding add, because the backwards conversion is always
      larger than the original latch value. That would violate the upper
      bound of the hardware device.
      
      Though looking closer at the details of that function reveals another
      bogosity: The upper bounds check is broken as well. Checking for a
      resulting "clc" value greater than KTIME_MAX after the conversion is
      pointless. The conversion does:
      
            u64 clc = (latch << evt->shift) / evt->mult;
      
      So there is no sanity check for (latch << evt->shift) exceeding the
      64bit boundary. The latch argument is "unsigned long", so on a 64bit
      arch the handed in argument could easily lead to an unnoticed shift
      overflow. With the above rounding fix applied the calculation before
      the divison is:
      
             u64 clc = (latch << evt->shift) + evt->mult - 1;
      
      So we need to make sure, that neither the shift nor the rounding add
      is overflowing the u64 boundary.
      
      [ukl: move assignment to rnd after eventually changing mult, fix build
       issue and correct comment with the right math]
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      Cc: Marc Kleine-Budde <mkl@pengutronix.de>
      Cc: nicolas.ferre@atmel.com
      Cc: Marc Pignat <marc.pignat@hevs.ch>
      Cc: john.stultz@linaro.org
      Cc: kernel@pengutronix.de
      Cc: Ronald Wahl <ronald.wahl@raritan.com>
      Cc: LAK <linux-arm-kernel@lists.infradead.org>
      Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/1380052223-24139-1-git-send-email-u.kleine-koenig@pengutronix.deSigned-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      97b94106
  7. 19 10月, 2013 1 次提交
  8. 18 10月, 2013 1 次提交
    • S
      perf: Disable PERF_RECORD_MMAP2 support · 3090ffb5
      Stephane Eranian 提交于
      For now, we disable the extended MMAP record support (MMAP2).
      
      We have identified cases where it would not report the correct mapping
      information, clone(VM_CLONE) but with separate pids.  We will revisit
      the support once we find a solution for this case.
      
      The patch changes the kernel to return EINVAL if attr->mmap2 is set. The
      patch also modifies the perf tool to use regular PERF_RECORD_MMAP for
      synthetic events and it also prevents the tool from requesting
      attr->mmap2 mode because the kernel would reject it.
      
      The support will be revisited once the kenrel interface is updated.
      
      In V2, we reduce the patch to the strict minimum.
      
      In V3, we avoid calling perf_event_open() with mmap2 set because we know
      it will fail and require fallback retry.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20131017173215.GA8820@quadSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3090ffb5
  9. 16 10月, 2013 4 次提交
    • O
      sched/wait: Introduce prepare_to_wait_event() · c2d81644
      Oleg Nesterov 提交于
      Add the new helper, prepare_to_wait_event() which should only be used
      by ___wait_event().
      
      prepare_to_wait_event() returns -ERESTARTSYS if signal_pending_state()
      is true, otherwise it does prepare_to_wait/exclusive.  This allows to
      uninline the signal-pending checks in wait_event*() macros.
      
      Also, it can initialize wait->private/func. We do not care if they were
      already initialized, the values are the same. This also shaves a couple
      of insns from the inlined code.
      
      This obviously makes prepare_*() path a little bit slower, but we are
      likely going to sleep anyway, so I think it makes sense to shrink .text:
      
                     text    data      bss      dec     hex  filename
                  ===================================================
         before:  5126092 2959248 10117120 18202460 115bf5c   vmlinux
          after:  5124618 2955152 10117120 18196890 115a99a   vmlinux
      
      on my build.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20131007161824.GA29757@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c2d81644
    • P
      sched: Remove get_online_cpus() usage · 6acce3ef
      Peter Zijlstra 提交于
      Remove get_online_cpus() usage from the scheduler; there's 4 sites that
      use it:
      
       - sched_init_smp(); where its completely superfluous since we're in
         'early' boot and there simply cannot be any hotplugging.
      
       - sched_getaffinity(); we already take a raw spinlock to protect the
         task cpus_allowed mask, this disables preemption and therefore
         also stabilizes cpu_online_mask as that's modified using
         stop_machine. However switch to active mask for symmetry with
         sched_setaffinity()/set_cpus_allowed_ptr(). We guarantee active
         mask stability by inserting sync_rcu/sched() into _cpu_down.
      
       - sched_setaffinity(); we don't appear to need get_online_cpus()
         either, there's two sites where hotplug appears relevant:
          * cpuset_cpus_allowed(); for the !cpuset case we use possible_mask,
            for the cpuset case we hold task_lock, which is a spinlock and
            thus for mainline disables preemption (might cause pain on RT).
          * set_cpus_allowed_ptr(); Holds all scheduler locks and thus has
            preemption properly disabled; also it already deals with hotplug
            races explicitly where it releases them.
      
       - migrate_swap(); we can make stop_two_cpus() do the heavy lifting for
         us with a little trickery. By adding a sync_sched/rcu() after the
         CPU_DOWN_PREPARE notifier we can provide preempt/rcu guarantees for
         cpu_active_mask. Use these to validate that both our cpus are active
         when queueing the stop work before we queue the stop_machine works
         for take_cpu_down().
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
      Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Link: http://lkml.kernel.org/r/20131011123820.GV3081@twins.programming.kicks-ass.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6acce3ef
    • P
      sched: Fix race in migrate_swap_stop() · 74602315
      Peter Zijlstra 提交于
      There is a subtle race in migrate_swap, when task P, on CPU A, decides to swap
      places with task T, on CPU B.
      
      Task P:
        - call migrate_swap
      Task T:
        - go to sleep, removing itself from the runqueue
      Task P:
        - double lock the runqueues on CPU A & B
      Task T:
        - get woken up, place itself on the runqueue of CPU C
      Task P:
        - see that task T is on a runqueue, and pretend to remove it
          from the runqueue on CPU B
      
      Now CPUs B & C both have corrupted scheduler data structures.
      
      This patch fixes it, by holding the pi_lock for both of the tasks
      involved in the migrate swap. This prevents task T from waking up,
      and placing itself onto another runqueue, until after migrate_swap
      has released all locks.
      
      This means that, when migrate_swap checks, task T will be either
      on the runqueue where it was originally seen, or not on any
      runqueue at all. Migrate_swap deals correctly with of those cases.
      Tested-by: NJoe Mario <jmario@redhat.com>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Reviewed-by: NRik van Riel <riel@redhat.com>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: hannes@cmpxchg.org
      Cc: aarcange@redhat.com
      Cc: srikar@linux.vnet.ibm.com
      Cc: tglx@linutronix.de
      Cc: hpa@zytor.com
      Link: http://lkml.kernel.org/r/20131010181722.GO13848@laptop.programming.kicks-ass.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      74602315
    • P
      sched/rt: Add missing rmb() · 7c3f2ab7
      Peter Zijlstra 提交于
      While discussing the proposed SCHED_DEADLINE patches which in parts
      mimic the existing FIFO code it was noticed that the wmb in
      rt_set_overloaded() didn't have a matching barrier.
      
      The only site using rt_overloaded() to test the rto_count is
      pull_rt_task() and we should issue a matching rmb before then assuming
      there's an rto_mask bit set.
      
      Without that smp_rmb() in there we could actually miss seeing the
      rto_mask bit.
      
      Also, change to using smp_[wr]mb(), even though this is SMP only code;
      memory barriers without smp_ always make me think they're against
      hardware of some sort.
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: vincent.guittot@linaro.org
      Cc: luca.abeni@unitn.it
      Cc: bruce.ashfield@windriver.com
      Cc: dhaval.giani@gmail.com
      Cc: rostedt@goodmis.org
      Cc: hgu1972@gmail.com
      Cc: oleg@redhat.com
      Cc: fweisbec@gmail.com
      Cc: darren@dvhart.com
      Cc: johan.eker@ericsson.com
      Cc: p.faure@akatech.ch
      Cc: paulmck@linux.vnet.ibm.com
      Cc: raistlin@linux.it
      Cc: claudio@evidence.eu.com
      Cc: insop.song@gmail.com
      Cc: michael@amarulasolutions.com
      Cc: liming.wang@windriver.com
      Cc: fchecconi@gmail.com
      Cc: jkacur@redhat.com
      Cc: tommaso.cucinotta@sssup.it
      Cc: Juri Lelli <juri.lelli@gmail.com>
      Cc: harald.gustafsson@ericsson.com
      Cc: nicola.manica@disi.unitn.it
      Cc: tglx@linutronix.de
      Link: http://lkml.kernel.org/r/20131015103507.GF10651@twins.programming.kicks-ass.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      7c3f2ab7
  10. 14 10月, 2013 2 次提交
  11. 13 10月, 2013 1 次提交
  12. 09 10月, 2013 17 次提交