1. 20 10月, 2005 12 次提交
    • Y
      [PATCH] swiotlb: make sure initial DMA allocations really are in DMA memory · 281dd25c
      Yasunori Goto 提交于
      This introduces a limit parameter to the core bootmem allocator; The new
      parameter indicates that physical memory allocated by the bootmem
      allocator should be within the requested limit.
      
      We also introduce alloc_bootmem_low_pages_limit, alloc_bootmem_node_limit,
      alloc_bootmem_low_pages_node_limit apis, but alloc_bootmem_low_pages_limit
      is the only api used for swiotlb.
      
      The existing alloc_bootmem_low_pages() api could instead have been
      changed and made to pass right limit to the core allocator.  But that
      would make the patch more intrusive for 2.6.14, as other arches use
      alloc_bootmem_low_pages().  We may be done that post 2.6.14 as a
      cleanup.
      
      With this, swiotlb gets memory within 4G for both x86_64 and ia64
      arches.
      Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
      Cc: Ravikiran G Thirumalai <kiran@scalex86.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      281dd25c
    • P
      [PATCH] `unaligned access' in acpi get_root_bridge_busnr() · 51b190b3
      Peter Chubb 提交于
      In drivers/acpi/glue.c the address of an integer is cast to the address of
      an unsigned long.  This breaks on systems where a long is larger than an
      int --- for a start the int can be misaligned; for a second the assignment
      through the pointer will overwrite part of the next variable.
      Signed-off-by: NPeter Chubb <peterc@gelato.unsw.edu.au>
      Acked-by: N"Brown, Len" <len.brown@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      51b190b3
    • D
      [PATCH] fix MGA DRM regression before 2.6.14 · 11909d64
      Dave Airlie 提交于
      I've gotten a report on lkml, of a possible regression in the MGA DRM in
      2.6.14-rc4 (since -rc1), I haven't been able to reproduce it here, but I've
      figured out some possible issues in the mga code that were definitely
      wrong, some of these are from DRM CVS, the main fix is the agp enable bit
      on the old code path still used by everyone.....
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      11909d64
    • A
      [PATCH] Threads shouldn't inherit PF_NOFREEZE · d1209d04
      Alan Stern 提交于
      The PF_NOFREEZE process flag should not be inherited when a thread is
      forked.  This patch (as585) removes the flag from the child.
      
      This problem is starting to show up more and more as drivers turn to the
      kthread API instead of using kernel_thread().  As a result, their kernel
      threads are now children of the kthread worker instead of modprobe, and
      they inherit the PF_NOFREEZE flag.  This can cause problems during system
      suspend; the kernel threads are not getting frozen as they ought to be.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d1209d04
    • T
      [PATCH] Export RCS_TAR_IGNORE for rpm targets · f9b25fab
      Tom Rini 提交于
      The variable RCS_TAR_IGNORE is used in scripts/packaging/Makefile, but not
      exported from the main Makefile, so it's never used.
      
      This results in the rpm targets being very unhappy in quilted trees.
      Signed-off-by: NTom Rini <trini@kernel.crashing.org>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f9b25fab
    • B
      [PATCH] ppc64: Fix error in vDSO 32 bits date · 83bcbf8d
      Benjamin Herrenschmidt 提交于
      The implementation of __kernel_gettimeofday() in the 32 bits vDSO has a
      small bug (a typo actually) that will cause it to lose 1 bit of precision.
      Not terribly bad but worth fixing.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      83bcbf8d
    • N
      [PATCH] Three one-liners in md.c · 6985c43f
      NeilBrown 提交于
      The main problem fixes is that in certain situations stopping md arrays may
      take longer than you expect, or may require multiple attempts.  This would
      only happen when resync/recovery is happening.
      
      This patch fixes three vaguely related bugs.
      
      1/ The recent change to use kthreads got the setting of the
         process name wrong.  This fixes it.
      2/ The recent change to use kthreads lost the ability for
         md threads to be signalled with SIG_KILL.  This restores that.
      3/ There is a long standing bug in that if:
          - An array needs recovery (onto a hot-spare) and
          - The recovery is being blocked because some other array being
             recovered shares a physical device and
          - The recovery thread is killed with SIG_KILL
         Then the recovery will appear to have completed with no IO being
         done, which can cause data corruption.
         This patch makes sure that incomplete recovery will be treated as
         incomplete.
      
      Note that any kernel affected by bug 2 will not suffer the problem of bug
      3, as the signal can never be delivered.  Thus the current 2.6.14-rc
      kernels are not susceptible to data corruption.  Note also that if arrays
      are shutdown (with "mdadm -S" or "raidstop") then the problem doesn't
      occur.  It only happens if a SIGKILL is independently delivered as done by
      'init' when shutting down.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6985c43f
    • A
      [PATCH] raw1394: fix locking in the presence of SMP and interrupts · 4a9949d7
      Andy Wingo 提交于
      Changes all spinlocks that can be held during an irq handler to disable
      interrupts while the lock is held.  Changes spin_[un]lock_irq to use the
      irqsave/irqrestore variants for robustness and readability.
      
      In raw1394.c:handle_iso_listen(), don't grab host_info_lock at all -- we're
      not accessing host_info_list or host_count, and holding this lock while
      trying to tasklet_kill the iso tasklet this can cause an ABBA deadlock if
      ohci:dma_rcv_tasklet is running and tries to grab host_info_lock in
      raw1394.c:receive_iso.  Test program attached reliably deadlocks all SMP
      machines I have been able to test without this patch.
      Signed-off-by: NAndy Wingo <wingo@pobox.com>
      Acked-by: NBen Collins <bcollins@ubuntu.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4a9949d7
    • A
      [PATCH] orinoco: limit message rate · c367c21c
      Andrew Morton 提交于
      Brice Goglin <Brice.Goglin@ens-lyon.org> reports a printk storm from this
      driver.  Fix.
      Acked-by: NDavid Gibson <hermes@gibson.dropbear.id.au>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c367c21c
    • H
      [PATCH] mm: hugetlb truncation fixes · 1c59827d
      Hugh Dickins 提交于
      hugetlbfs allows truncation of its files (should it?), but hugetlb.c often
      forgets that: crashes and misaccounting ensue.
      
      copy_hugetlb_page_range better grab the src page_table_lock since we don't
      want to guess what happens if concurrently truncated.  unmap_hugepage_range
      rss accounting must not assume the full range was mapped.  follow_hugetlb_page
      must guard with page_table_lock and be prepared to exit early.
      
      Restyle copy_hugetlb_page_range with a for loop like the others there.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1c59827d
    • R
      [PATCH] Fix cpu timers exit deadlock and races · e03d13e9
      Roland McGrath 提交于
      Oleg Nesterov reported an SMP deadlock.  If there is a running timer
      tracking a different process's CPU time clock when the process owning
      the timer exits, we deadlock on tasklist_lock in posix_cpu_timer_del via
      exit_itimers.
      
      That code was using tasklist_lock to check for a race with __exit_signal
      being called on the timer-target task and clearing its ->signal.
      However, there is actually no such race.  __exit_signal will have called
      posix_cpu_timers_exit and posix_cpu_timers_exit_group before it does
      that.  Those will clear those k_itimer's association with the dying
      task, so posix_cpu_timer_del will return early and never reach the code
      in question.
      
      In addition, posix_cpu_timer_del called from exit_itimers during execve
      or directly from timer_delete in the process owning the timer can race
      with an exiting timer-target task to cause a double put on timer-target
      task struct.  Make sure we always access cpu_timers lists with sighand
      lock held.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NChris Wright <chrisw@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e03d13e9
    • S
      [PATCH] Handle spurious page fault for hugetlb region · 3359b54c
      Seth, Rohit 提交于
      The hugetlb pages are currently pre-faulted.  At the time of mmap of
      hugepages, we populate the new PTEs.  It is possible that HW has already
      cached some of the unused PTEs internally.  These stale entries never
      get a chance to be purged in existing control flow.
      
      This patch extends the check in page fault code for hugepages.  Check if
      a faulted address falls with in size for the hugetlb file backing it.
      We return VM_FAULT_MINOR for these cases (assuming that the arch
      specific page-faulting code purges the stale entry for the archs that
      need it).
      Signed-off-by: NRohit Seth <rohit.seth@intel.com>
      
      [ This is apparently arguably an ia64 port bug. But the code won't
        hurt, and for now it fixes a real problem on some ia64 machines ]
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3359b54c
  2. 18 10月, 2005 22 次提交
  3. 17 10月, 2005 5 次提交
    • R
      [PATCH] fix black/white-only svideo input in vpx3220 decoder · de21eb63
      Ronald S. Bultje 提交于
      Fix the fact that the svideo input will only give input in black/white in
      some circumstances.  Reason is that in the PCI controller driver (zr36067),
      after setting input, we reset norm, which overwrites the input register
      with the default.  This patch makes it always set the correct value for the
      input when changing norm.
      Signed-off-by: NRonald S. Bultje <rbultje@ronald.bitfreak.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      de21eb63
    • R
      [PATCH] fix vpx3220 offset issue in SECAM · 9b3acc21
      Ronald S. Bultje 提交于
      Fix bug #5404 in kernel bugzilla.
      
      It basically updates the vpx3220 initialization tables with some newer
      values that we've had in CVS for a while (and that, for some reason, never
      ended up in the kernel...  must've gotten lost).  Those fix a ~16 pixels
      noise at the top of the picture in at least SECAM, although (now that I
      think about it) PAL was probably affected, also.
      Signed-off-by: NRonald S. Bultje <rbultje@ronald.bitfreak.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9b3acc21
    • S
      [PATCH] SVGATextMode fix · 0aec4867
      Samuel Thibault 提交于
      Fix bug 5441.
      
      I didn't know about messy programs like svgatextmode...  Couldn't this be
      integrated in some linux/drivers/video/console/svgacon.c ?...  So because
      of the existence of the svgatextmode program, the kernel is not supposed to
      touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ?
      
      Disabling the check in vgacon_resize() might help indeed, but I'm really
      not sure whether it will work for any chipset: in my patch, CRT registers
      are set at each console switch, since stty rows/cols apply to consoles
      separately...
      
      The attached solution is to keep the test, but if it fails, we assume that
      the caller knows what it does (i.e.  it is svgatextmode) and then disable
      any further call to vgacon_doresize.  Svgatextmode is usually used to
      _expand_ the display, not to shrink it.  And it is harmless in the case of
      a too big stty rows/cols: the display will just be cropped.  I tested it on
      my laptop, and it works fine with svgatextmode.
      
      A better solution would be that svgatextmode explicitely tells the kernel
      not to care about video timing, but for this an interface needs be defined
      and svgatextmode be patched.
      Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0aec4867
    • H
      [PATCH] list: add missing rcu_dereference on first element · b24d18aa
      Herbert Xu 提交于
      It seems that all the list_*_rcu primitives are missing a memory barrier
      on the very first dereference.  For example,
      
      #define list_for_each_rcu(pos, head) \
      	for (pos = (head)->next; prefetch(pos->next), pos != (head); \
      		pos = rcu_dereference(pos->next))
      
      It will go something like:
      
      	pos = (head)->next
      
      	prefetch(pos->next)
      
      	pos != (head)
      
      	do stuff
      
      We're missing a barrier here.
      
      	pos = rcu_dereference(pos->next)
      
      		fetch pos->next
      
      		barrier given by rcu_dereference(pos->next)
      
      		store pos
      
      Without the missing barrier, the pos->next value may turn out to be stale.
      In fact, if "do stuff" were also dereferencing pos and relying on
      list_for_each_rcu to provide the barrier then it may also break.
      
      So here is a patch to make sure that we have a barrier for the first
      element in the list.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: N"Paul E. McKenney" <paulmck@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b24d18aa
    • L
      Fix memory ordering bug in page reclaim · 3d80636a
      Linus Torvalds 提交于
      As noticed by Nick Piggin, we need to make sure that we check the page
      count before we check for PageDirty, since the dirty check is only valid
      if the count implies that we're the only possible ones holding the page.
      
      We always did do this, but the code needs a read-memory-barrier to make
      sure that the orderign is also honored by the CPU.
      
      (The writer side is ordered due to the atomic decrement and test on the
      page count, see the discussion on linux-kernel)
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3d80636a
  4. 16 10月, 2005 1 次提交
    • A
      [PATCH]: highest_possible_processor_id() has to be a macro · 688ce17b
      Al Viro 提交于
      	... otherwise, things like alpha and sparc64 break and break
      badly.  They define cpu_possible_map to something else in smp.h
      *AFTER* having included cpumask.h.
      
      	If that puppy is a macro, expansion will happen at the actual
      caller, when we'd already seen #define cpu_possible_map ... and we will
      get the right thing used.
      
      	As an inline helper it will be tokenized before we get to that
      define and that's it; no matter what we define later, it won't affect
      anything.  We get modules with dependency on cpu_possible_map instead
      of the right symbol (phys_cpu_present_map in case of sparc64), or outright
      link errors if they are built-in.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      688ce17b