1. 20 Oct, 2005 4 commits
    • Andy Wingo's avatar
      [PATCH] raw1394: fix locking in the presence of SMP and interrupts · 4a9949d7
      Andy Wingo authored
      
      
      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: default avatarAndy Wingo <wingo@pobox.com>
      Acked-by: default avatarBen Collins <bcollins@ubuntu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4a9949d7
    • Andrew Morton's avatar
      [PATCH] orinoco: limit message rate · c367c21c
      Andrew Morton authored
      
      
      Brice Goglin <Brice.Goglin@ens-lyon.org> reports a printk storm from this
      driver.  Fix.
      Acked-by: default avatarDavid Gibson <hermes@gibson.dropbear.id.au>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c367c21c
    • Hugh Dickins's avatar
      [PATCH] mm: hugetlb truncation fixes · 1c59827d
      Hugh Dickins authored
      
      
      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: default avatarHugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1c59827d
    • Roland McGrath's avatar
      [PATCH] Fix cpu timers exit deadlock and races · e03d13e9
      Roland McGrath authored
      
      
      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: default avatarRoland McGrath <roland@redhat.com>
      Signed-off-by: default avatarChris Wright <chrisw@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e03d13e9
  2. 19 Oct, 2005 1 commit
    • Seth, Rohit's avatar
      [PATCH] Handle spurious page fault for hugetlb region · 3359b54c
      Seth, Rohit authored
      
      
      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: default avatarRohit 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: default avatarLinus Torvalds <torvalds@osdl.org>
      3359b54c
  3. 18 Oct, 2005 14 commits
  4. 17 Oct, 2005 13 commits
    • Eric Dumazet's avatar
      [PATCH] rcu: keep rcu callback event counter · 5ee832db
      Eric Dumazet authored
      
      
      This makes call_rcu() keep track of how many events there are on the RCU
      list, and cause a reschedule event when the list gets too long.
      
      This helps keep RCU event lists down.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      5ee832db
    • Jeff Garzik's avatar
      [PATCH] Fix and clean up quirk_intel_ide_combined() configuration · cc675230
      Jeff Garzik authored
      
      
      This change makes quirk_intel_ide_combined() dependent on the precise
      conditions under which it is needed:
      
      * IDE is built in
      * IDE SATA option is not set
      * ata_piix or ahci drivers are enabled
      
      This fixes an issue where some modular configurations would not cause
      the quirk to be enabled.
      Signed-off-by: default avatarJeff Garzik <jgarzik@pobox.com>
      Signed-off-by: default avatarLinus torvalds <torvalds@osdl.org>
      cc675230
    • Oleg Nesterov's avatar
      [PATCH] posix-timers: fix task accounting · 47d6b083
      Oleg Nesterov authored
      
      
      Make sure we release the task struct properly when releasing pending
      timers.
      
      release_task() does write_lock_irq(&tasklist_lock), so it can't race
      with run_posix_cpu_timers() on any cpu.
      Signed-off-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      47d6b083
    • Trond Myklebust's avatar
      [PATCH] NFS: Fix Oopsable/unnecessary i_count manipulations in nfs_wait_on_inode() · 6ce96917
      Trond Myklebust authored
      
      
      Oopsable since nfs_wait_on_inode() can get called as part of iput_final().
      
      Unnecessary since the caller had better be damned sure that the inode won't
      disappear from underneath it anyway.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6ce96917
    • Trond Myklebust's avatar
      [PATCH] NFS: Fix cache consistency races · b3c52da3
      Trond Myklebust authored
      
      
      If the data cache has been marked as potentially invalid by nfs_refresh_inode,
      we should invalidate it rather than assume that changes are due to our own
      activity.
      
      Also ensure that we always start with a valid cache before declaring it
      to be protected by a delegation.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b3c52da3
    • Christian Krause's avatar
      [PATCH] USB: fix bug in handling of highspeed usb HID devices · 13b58ee5
      Christian Krause authored
      
      
      During the development of an USB device I found a bug in the handling of
      Highspeed HID devices in the kernel.
      
      What happened?
      
      Highspeed HID devices are correctly recognized and enumerated by the
      kernel. But even if usbhid kernel module is loaded, no HID reports are
      received by the kernel.
      
      The output of the hardware USB analyzer told me that the host doesn't
      even poll for interrupt IN transfers (even the "interrupt in" USB
      transfer are polled by the host).
      
      After some debugging in hid-core.c I've found the reason.
      
      In case of a highspeed device, the endpoint interval is re-calculated in
      driver/usb/input/hid-core.c:
      
      line 1669:
                   /* handle potential highspeed HID correctly */
                   interval = endpoint->bInterval;
                   if (dev->speed == USB_SPEED_HIGH)
                         interval = 1 << (interval - 1);
      
      Basically this calculation is correct (refer to USB 2.0 spec, 9.6.6).
      This new calculated value of "interval" is used as input for
      usb_fill_int_urb:
      
      line 1685:
      
                  usb_fill_int_urb(hid->urbin, dev, pipe, hid->inbuf, 0,
                         hid_irq_in, hid, interval);
      
      Unfortunately the same calculation as above is done a second time in
      usb_fill_int_urb in the file include/linux/usb.h:
      
      line 933:
              if (dev->speed == USB_SPEED_HIGH)
                      urb->interval = 1 << (interval - 1);
              else
                      urb->interval = interval;
      
      This means, that if the endpoint descriptor (of a high speed device)
      specifies e.g. bInterval = 7, the urb->interval gets the value:
      
      hid-core.c: interval = 1 << (7-1) = 0x40 = 64
      urb->interval = 1 << (interval -1) = 1 << (63) = integer overflow
      
      Because of this the value of urb->interval is sometimes negative and is
      rejected in core/urb.c:
      line 353:
                      /* too small? */
                      if (urb->interval <= 0)
                              return -EINVAL;
      
      The conclusion is, that the recalculaton of the interval (which is
      necessary for highspeed) should not be made twice, because this is
      simply wrong. ;-)
      
      Re-calculation in usb_fill_int_urb makes more sense, because it is the
      most general approach. So it would make sense to remove it from
      hid-core.c.
      
      Because in hid-core.c the interval variable is only used for calling
      usb_fill_int_urb, it is no problem to remove the highspeed
      re-calculation in this file.
      Signed-off-by: default avatarChristian Krause <chkr@plauener.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      13b58ee5
    • Olav Kongas's avatar
      [PATCH] isp116x-hcd: fix handling of short transfers · e9b765de
      Olav Kongas authored
      
      
      Increased use of scatter-gather by usb-storage driver after 2.6.13 has
      exposed a buggy codepath in isp116x-hcd, which was probably never
      visited before: bug happened only for those urbs, for which
      URB_SHORT_NOT_OK was set AND short transfer occurred.
      
      The fix attached was tested in 2 ways: (a) it fixed failing
      initialization of a flash drive with an embedded hub; (b) the fix was
      tested with 'usbtest' against a modified g_zero driver (on top of
      net2280), which generated short bulk IN transfers of various lengths
      including multiples and non-multiples of max_packet_length.
      Signed-off-by: default avatarOlav Kongas <ok@artecdesign.ee>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e9b765de
    • Linus Torvalds's avatar
      Increase default RCU batching sharply · 2cc78eb5
      Linus Torvalds authored
      
      
      Dipankar made RCU limit the batch size to improve latency, but that
      approach is unworkable: it can cause the RCU queues to grow without
      bounds, since the batch limiter ended up limiting the callbacks.
      
      So make the limit much higher, and start planning on instead limiting
      the batch size by doing RCU callbacks more often if the queue looks like
      it might be growing too long.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2cc78eb5
    • Ronald S. Bultje's avatar
      [PATCH] fix black/white-only svideo input in vpx3220 decoder · de21eb63
      Ronald S. Bultje authored
      
      
      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: default avatarRonald S. Bultje <rbultje@ronald.bitfreak.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      de21eb63
    • Ronald S. Bultje's avatar
      [PATCH] fix vpx3220 offset issue in SECAM · 9b3acc21
      Ronald S. Bultje authored
      
      
      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: default avatarRonald S. Bultje <rbultje@ronald.bitfreak.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      9b3acc21
    • Samuel Thibault's avatar
      [PATCH] SVGATextMode fix · 0aec4867
      Samuel Thibault authored
      
      
      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: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0aec4867
    • Herbert Xu's avatar
      [PATCH] list: add missing rcu_dereference on first element · b24d18aa
      Herbert Xu authored
      
      
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatar"Paul E. McKenney" <paulmck@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b24d18aa
    • Linus Torvalds's avatar
      Fix memory ordering bug in page reclaim · 3d80636a
      Linus Torvalds authored
      
      
      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: default avatarLinus Torvalds <torvalds@osdl.org>
      3d80636a
  5. 16 Oct, 2005 1 commit
    • Al Viro's avatar
      [PATCH]: highest_possible_processor_id() has to be a macro · 688ce17b
      Al Viro authored
      
      
      	... 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: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      688ce17b
  6. 15 Oct, 2005 7 commits