1. 28 4月, 2008 1 次提交
  2. 27 4月, 2008 2 次提交
  3. 26 4月, 2008 1 次提交
  4. 25 4月, 2008 8 次提交
    • A
      [PATCH] sanitize unshare_files/reset_files_struct · 3b125388
      Al Viro 提交于
      * let unshare_files() give caller the displaced files_struct
      * don't bother with grabbing reference only to drop it in the
        caller if it hadn't been shared in the first place
      * in that form unshare_files() is trivially implemented via
        unshare_fd(), so we eliminate the duplicate logics in fork.c
      * reset_files_struct() is not just only called for current;
        it will break the system if somebody ever calls it for anything
        else (we can't modify ->files of somebody else).  Lose the
        task_struct * argument.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      3b125388
    • A
      [PATCH] sanitize handling of shared descriptor tables in failing execve() · fd8328be
      Al Viro 提交于
      * unshare_files() can fail; doing it after irreversible actions is wrong
        and de_thread() is certainly irreversible.
      * since we do it unconditionally anyway, we might as well do it in do_execve()
        and save ourselves the PITA in binfmt handlers, etc.
      * while we are at it, binfmt_som actually leaked files_struct on failure.
      
      As a side benefit, unshare_files(), put_files_struct() and reset_files_struct()
      become unexported.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      fd8328be
    • A
      [PATCH] close race in unshare_files() · 6b335d9c
      Al Viro 提交于
      updating current->files requires task_lock
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6b335d9c
    • D
      sched: use alloc_bootmem() instead of alloc_bootmem_low() · 5a9d3225
      David Miller 提交于
      There is no guarantee that there is physical ram below 4GB, and in
      fact many boxes don't have exactly that.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5a9d3225
    • P
      sched: fix share (re)distribution · 3f5087a2
      Peter Zijlstra 提交于
      fix __aggregate_redistribute_shares() related lockup reported by
      David S. Miller.
      
      The problem this code tries to solve is 'accurately' calculating the 'fair'
      share of the group weight for each cpu. The current code falls back to a global
      group rebalance in case the sched_domain's span it looks at has no shares, but
      does have tasks.
      
      The reason it gets stuck here, is because its inherently racy - if someone
      steals the last task after we compute the agg->rq_weight, but before we
      rebalance, we'll never get out of the loop.
      
      We could of course go fix that, but while looking at this issue I found that
      this 'fallback' wasn't nearly as rare as I'd hoped it to be. In fact its quite
      common - and given it walks the whole machine, thats very bad.
      
      The new approach is simple (why didn't I think of it before?), we set the
      aggregate shares to the full task group weight, and each larger sched domain
      that encounters an aggregate shares larger than the weight, clips it (it
      already re-distributes anyway).
      
      This nicely converges to the desired global picture where the sum of all
      shares equals the task group weight.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3f5087a2
    • I
      softlockup: fix NOHZ wakeup · 126e01bf
      Ingo Molnar 提交于
      David Miller reported:
      
      |--------------->
      the following commit:
      
      | commit 27ec4407
      | Author: Ingo Molnar <mingo@elte.hu>
      | Date:   Thu Feb 28 21:00:21 2008 +0100
      |
      |     sched: make cpu_clock() globally synchronous
      |
      |     Alexey Zaytsev reported (and bisected) that the introduction of
      |     cpu_clock() in printk made the timestamps jump back and forth.
      |
      |     Make cpu_clock() more reliable while still keeping it fast when it's
      |     called frequently.
      |
      |     Signed-off-by: Ingo Molnar <mingo@elte.hu>
      
      causes watchdog triggers when a cpu exits NOHZ state when it has been
      there for >= the soft lockup threshold, for example here are some
      messages from a 128 cpu Niagara2 box:
      
      [  168.106406] BUG: soft lockup - CPU#11 stuck for 128s! [dd:3239]
      [  168.989592] BUG: soft lockup - CPU#21 stuck for 86s! [swapper:0]
      [  168.999587] BUG: soft lockup - CPU#29 stuck for 91s! [make:4511]
      [  168.999615] BUG: soft lockup - CPU#2 stuck for 85s! [swapper:0]
      [  169.020514] BUG: soft lockup - CPU#37 stuck for 91s! [swapper:0]
      [  169.020514] BUG: soft lockup - CPU#45 stuck for 91s! [sh:4515]
      [  169.020515] BUG: soft lockup - CPU#69 stuck for 92s! [swapper:0]
      [  169.020515] BUG: soft lockup - CPU#77 stuck for 92s! [swapper:0]
      [  169.020515] BUG: soft lockup - CPU#61 stuck for 92s! [swapper:0]
      [  169.112554] BUG: soft lockup - CPU#85 stuck for 92s! [swapper:0]
      [  169.112554] BUG: soft lockup - CPU#101 stuck for 92s! [swapper:0]
      [  169.112554] BUG: soft lockup - CPU#109 stuck for 92s! [swapper:0]
      [  169.112554] BUG: soft lockup - CPU#117 stuck for 92s! [swapper:0]
      [  169.171483] BUG: soft lockup - CPU#40 stuck for 80s! [dd:3239]
      [  169.331483] BUG: soft lockup - CPU#13 stuck for 86s! [swapper:0]
      [  169.351500] BUG: soft lockup - CPU#43 stuck for 101s! [dd:3239]
      [  169.531482] BUG: soft lockup - CPU#9 stuck for 129s! [mkdir:4565]
      [  169.595754] BUG: soft lockup - CPU#20 stuck for 93s! [swapper:0]
      [  169.626787] BUG: soft lockup - CPU#52 stuck for 93s! [swapper:0]
      [  169.626787] BUG: soft lockup - CPU#84 stuck for 92s! [swapper:0]
      [  169.636812] BUG: soft lockup - CPU#116 stuck for 94s! [swapper:0]
      
      It's simple enough to trigger this by doing a 10 minute sleep after a
      fresh bootup then starting a parallel kernel build.
      
      I suspect this might be reintroducing a problem we've had and fixed
      before, see the thread:
      
      http://marc.info/?l=linux-kernel&m=119546414004065&w=2
      <---------------|
      
      touch the softlockup watchdog when exiting NOHZ state - we are
      obviously not locked up.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      126e01bf
    • M
      [PATCH] Build fix for CONFIG_NUMA=y && CONFIG_SMP=n · 03970f06
      Mike Travis 提交于
      Regression caused by 434d53b0Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      03970f06
    • R
      [IA64] fix bootmem regression on Altix · 472613b9
      Russ Anderson 提交于
      A recent change prevents SGI Altix from booting.
      This patch fixes the problem.
      
      The regresson was introduced in commit 434d53b0Signed-off-by: NRuss Anderson <rja@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      472613b9
  5. 23 4月, 2008 2 次提交
  6. 22 4月, 2008 3 次提交
  7. 21 4月, 2008 4 次提交
    • T
      hrtimer: optimize the softirq time optimization · 259aae86
      Thomas Gleixner 提交于
      The previous optimization did not take the case into account where a
      clock provides its own softirq_get_time() function.
      
      Check for the availablitiy of the clock get time function first and
      then check if we need to retrieve the time for both clocks via
      hrtimer_softirq_gettime() to avoid a double evaluation of time in that
      case as well.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      259aae86
    • D
      hrtimer: reduce calls to hrtimer_get_softirq_time() · 833883d9
      Dimitri Sivanich 提交于
      It seems that hrtimer_run_queues() is calling hrtimer_get_softirq_time() more
      often than it needs to.  This can cause frequent contention on systems with
      large numbers of processors/cores.
      
      With this patch, hrtimer_run_queues only calls hrtimer_get_softirq_time() if
      there is a pending timer in one of the hrtimer bases, and only once.
      
      This also combines hrtimer_run_queues() and the inline run_hrtimer_queue()
      into one function.
      
      [ tglx@linutronix.de: coding style ]
      Signed-off-by: NDimitri Sivanich <sivanich@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      833883d9
    • G
      clockevents: fix typo in tick-broadcast.c · 833df317
      Glauber Costa 提交于
      braodcast -> broadcast
      Signed-off-by: NGlauber Costa <gcosta@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      833df317
    • I
      PCI: clean up resource alignment management · 88452565
      Ivan Kokshaysky 提交于
      Done per Linus' request and suggestions. Linus has explained that
      better than I'll be able to explain:
      
      On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
      > Actually, before we go any further, there might be a less intrusive
      > alternative: add just a couple of flags to the resource flags field (we
      > still have something like 8 unused bits on 32-bit), and use those to
      > implement a generic "resource_alignment()" routine.
      >
      > Two flags would do it:
      >
      >  - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
      >    resources)
      >
      >  - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
      >    during probing)
      >
      > and then the case of both flags zero (or both bits set) would actually be
      > "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
      > actually allocate the resource (so that we don't use the "start" field as
      > alignment incorrectly when it no longer indicates alignment).
      >
      > That wouldn't be totally generic, but it would have the nice property of
      > automatically at least add sanity checking for that whole "res->start has
      > the odd meaning of 'alignment' during probing" and remove the need for a
      > new field, and it would allow us to have a generic "resource_alignment()"
      > routine that just gets a resource pointer.
      
      Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.
      Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Gary Hade <garyhade@us.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      88452565
  8. 20 4月, 2008 19 次提交