1. 19 1月, 2006 1 次提交
  2. 18 1月, 2006 1 次提交
    • R
      [SPARC64]: Eliminate race condition reading Hummingbird STICK register · 9eb3394b
      Richard Mortimer 提交于
      Ensure a consistent value is read from the STICK register by ensuring
      that both high and low are read without high changing due to a roll
      over of the low register.
      
      Various Debian/SPARC users (myself include) have noticed problems with
      Hummingbird based systems. The symptoms are that the system time is
      seen to jump forward 3 days, 6 hours, 11 minutes give or take a few
      seconds. In many cases the system then hangs some time afterwards.
      
      I've spotted a race condition in the code to read the STICK register.
      I could not work out why 3d, 6h, 11m is important but guess that it is
      due to the 2^32 jump of STICK (forwards on one read and then the next
      read will seem to be backwards) during a timer interrupt. I'm guessing
      that a change of -2^32 will get converted to a large unsigned
      increment after the arithmetic manipulation between STICK,
      nanoseconds, jiffies etc.
      
      I did a test where I modified __hbird_read_stick to artificially
      inject rollover faults forcefully every few seconds. With this I saw
      the clock jump over 6 times in 12 hours compared to once every month
      or so.
      Signed-off-by: NRichard Mortimer <richm@oldelvet.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9eb3394b
  3. 13 1月, 2006 3 次提交
  4. 12 1月, 2006 3 次提交
  5. 11 1月, 2006 5 次提交
  6. 10 1月, 2006 5 次提交
  7. 09 1月, 2006 2 次提交
  8. 29 12月, 2005 1 次提交
  9. 23 12月, 2005 2 次提交
  10. 21 12月, 2005 1 次提交
  11. 13 12月, 2005 1 次提交
  12. 30 11月, 2005 1 次提交
  13. 29 11月, 2005 1 次提交
  14. 23 11月, 2005 2 次提交
    • H
      [PATCH] unpaged: fix sound Bad page states · f3d48f03
      Hugh Dickins 提交于
      Earlier I unifdefed PageCompound, so that snd_pcm_mmap_control_nopage and
      others can give out a 0-order component of a higher-order page, which won't
      be mistakenly freed when zap_pte_range unmaps it.  But many Bad page states
      reported a PG_reserved was freed after all: I had missed that we need to
      say __GFP_COMP to get compound page behaviour.
      
      Some of these higher-order pages are allocated by snd_malloc_pages, some by
      snd_malloc_dev_pages; or if SBUS, by sbus_alloc_consistent - but that has
      no gfp arg, so add __GFP_COMP into its sparc32/64 implementations.
      
      I'm still rather puzzled that DRM seems not to need a similar change.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f3d48f03
    • H
      [PATCH] unpaged: VM_UNPAGED · 0b14c179
      Hugh Dickins 提交于
      Although we tend to associate VM_RESERVED with remap_pfn_range, quite a few
      drivers set VM_RESERVED on areas which are then populated by nopage.  The
      PageReserved removal in 2.6.15-rc1 changed VM_RESERVED not to free pages in
      zap_pte_range, without changing those drivers not to set it: so their pages
      just leak away.
      
      Let's not change miscellaneous drivers now: introduce VM_UNPAGED at the core,
      to flag the special areas where the ptes may have no struct page, or if they
      have then it's not to be touched.  Replace most instances of VM_RESERVED in
      core mm by VM_UNPAGED.  Force it on in remap_pfn_range, and the sparc and
      sparc64 io_remap_pfn_range.
      
      Revert addition of VM_RESERVED to powerpc vdso, it's not needed there.  Is it
      needed anywhere?  It still governs the mm->reserved_vm statistic, and special
      vmas not to be merged, and areas not to be core dumped; but could probably be
      eliminated later (the drivers are probably specifying it because in 2.4 it
      kept swapout off the vma, but in 2.6 we work from the LRU, which these pages
      don't get on).
      
      Use the VM_SHM slot for VM_UNPAGED, and define VM_SHM to 0: it serves no
      purpose whatsoever, and should be removed from drivers when we clean up.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Acked-by: NWilliam Irwin <wli@holomorphy.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0b14c179
  15. 13 11月, 2005 1 次提交
  16. 12 11月, 2005 1 次提交
  17. 10 11月, 2005 2 次提交
  18. 09 11月, 2005 4 次提交
    • N
      [PATCH] sched: resched and cpu_idle rework · 64c7c8f8
      Nick Piggin 提交于
      Make some changes to the NEED_RESCHED and POLLING_NRFLAG to reduce
      confusion, and make their semantics rigid.  Improves efficiency of
      resched_task and some cpu_idle routines.
      
      * In resched_task:
      - TIF_NEED_RESCHED is only cleared with the task's runqueue lock held,
        and as we hold it during resched_task, then there is no need for an
        atomic test and set there. The only other time this should be set is
        when the task's quantum expires, in the timer interrupt - this is
        protected against because the rq lock is irq-safe.
      
      - If TIF_NEED_RESCHED is set, then we don't need to do anything. It
        won't get unset until the task get's schedule()d off.
      
      - If we are running on the same CPU as the task we resched, then set
        TIF_NEED_RESCHED and no further action is required.
      
      - If we are running on another CPU, and TIF_POLLING_NRFLAG is *not* set
        after TIF_NEED_RESCHED has been set, then we need to send an IPI.
      
      Using these rules, we are able to remove the test and set operation in
      resched_task, and make clear the previously vague semantics of
      POLLING_NRFLAG.
      
      * In idle routines:
      - Enter cpu_idle with preempt disabled. When the need_resched() condition
        becomes true, explicitly call schedule(). This makes things a bit clearer
        (IMO), but haven't updated all architectures yet.
      
      - Many do a test and clear of TIF_NEED_RESCHED for some reason. According
        to the resched_task rules, this isn't needed (and actually breaks the
        assumption that TIF_NEED_RESCHED is only cleared with the runqueue lock
        held). So remove that. Generally one less locked memory op when switching
        to the idle thread.
      
      - Many idle routines clear TIF_POLLING_NRFLAG, and only set it in the inner
        most polling idle loops. The above resched_task semantics allow it to be
        set until before the last time need_resched() is checked before going into
        a halt requiring interrupt wakeup.
      
        Many idle routines simply never enter such a halt, and so POLLING_NRFLAG
        can be always left set, completely eliminating resched IPIs when rescheduling
        the idle task.
      
        POLLING_NRFLAG width can be increased, to reduce the chance of resched IPIs.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Con Kolivas <kernel@kolivas.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      64c7c8f8
    • N
      [PATCH] sched: disable preempt in idle tasks · 5bfb5d69
      Nick Piggin 提交于
      Run idle threads with preempt disabled.
      
      Also corrected a bugs in arm26's cpu_idle (make it actually call schedule()).
      How did it ever work before?
      
      Might fix the CPU hotplugging hang which Nigel Cunningham noted.
      
      We think the bug hits if the idle thread is preempted after checking
      need_resched() and before going to sleep, then the CPU offlined.
      
      After calling stop_machine_run, the CPU eventually returns from preemption and
      into the idle thread and goes to sleep.  The CPU will continue executing
      previous idle and have no chance to call play_dead.
      
      By disabling preemption until we are ready to explicitly schedule, this bug is
      fixed and the idle threads generally become more robust.
      
      From: alexs <ashepard@u.washington.edu>
      
        PPC build fix
      
      From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
      
        MIPS build fix
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NYoichi Yuasa <yuasa@hh.iij4u.or.jp>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5bfb5d69
    • C
      [PATCH] remove ioctl32_handler_t · 7e4c54a2
      Christoph Hellwig 提交于
      Some architectures define and use this type in their compat_ioctl code, but
      all of them can easily use the identical ioctl_trans_handler_t type that is
      defined in common code.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7e4c54a2
    • H
      [SPARC64] mm: update get_user_insn comment · da160546
      Hugh Dickins 提交于
      Update comment on get_user_insn to the more general "pte lock", which may
      or may not be the page_table_lock.  Note vmtruncate handled like kswapd.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      da160546
  19. 08 11月, 2005 3 次提交