1. 29 Jul, 2009 8 commits
  2. 23 Jul, 2009 1 commit
  3. 16 Jul, 2009 2 commits
  4. 14 Jul, 2009 1 commit
    • Jesse Barnes's avatar
      drm/i915: FIFO watermark calculation fixes · dff33cfc
      Jesse Barnes authored
      I discovered several bugs in the FIFO code that was recently applied.
      Some of them fell into the "how did this ever work" category, since in
      some cases we were using the wrong FIFO size values, and the
      calculations ended up being way off.
      
      This patch fixes all the bugs I found, and works well on my GM45, 915GM
      and 855GM test machines; but as usual with these sorts of patches
      broader testing is definitely requested (in particular this patch
      affects 830, 845 and 865 for which I don't have test hardware).
      
      Overall, the patch clarifies the watermark calculation function by
      adding some comments and debug info, and making the variable names a
      bit clearer.  The "get FIFO size" portion of the code has also been
      corrected, so we should be able to properly detect the FIFO allocations
      for each pipe, for use in the watermark calculation.
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      dff33cfc
  5. 13 Jul, 2009 4 commits
  6. 12 Jul, 2009 5 commits
    • Linus Torvalds's avatar
      Merge branch 'kmemleak' of git://linux-arm.org/linux-2.6 · 7638d532
      Linus Torvalds authored
      * 'kmemleak' of git://linux-arm.org/linux-2.6:
        kmemleak: Remove alloc_bootmem annotations introduced in the past
        kmemleak: Add callbacks to the bootmem allocator
        kmemleak: Allow partial freeing of memory blocks
        kmemleak: Trace the kmalloc_large* functions in slub
        kmemleak: Scan objects allocated during a scanning episode
        kmemleak: Do not acquire scan_mutex in kmemleak_open()
        kmemleak: Remove the reported leaks number limitation
        kmemleak: Add more cond_resched() calls in the scanning thread
        kmemleak: Renice the scanning thread to +10
      7638d532
    • Artem Bityutskiy's avatar
      AFS: Fix compilation warning · dd0d9a46
      Artem Bityutskiy authored
      Fix the following warning:
      
        fs/afs/dir.c: In function 'afs_d_revalidate':
        fs/afs/dir.c:567: warning: 'fid.vnode' may be used uninitialized in this function
        fs/afs/dir.c:567: warning: 'fid.unique' may be used uninitialized in this function
      
      by marking the 'fid' variable as an uninitialized_var.  The problem is
      that gcc doesn't always manage to work out that fid is always set on the
      path through the function that uses it.
      
      Cc: linux-afs@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dd0d9a46
    • Alexey Dobriyan's avatar
      headers: smp_lock.h redux · 405f5571
      Alexey Dobriyan authored
      * Remove smp_lock.h from files which don't need it (including some headers!)
      * Add smp_lock.h to files which do need it
      * Make smp_lock.h include conditional in hardirq.h
        It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT
      
        This will make hardirq.h inclusion cheaper for every PREEMPT=n config
        (which includes allmodconfig/allyesconfig, BTW)
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      405f5571
    • Julien Tinnes's avatar
      personality: fix PER_CLEAR_ON_SETID · f9fabcb5
      Julien Tinnes authored
      We have found that the current PER_CLEAR_ON_SETID mask on Linux doesn't
      include neither ADDR_COMPAT_LAYOUT, nor MMAP_PAGE_ZERO.
      
      The current mask is READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE.
      
      We believe it is important to add MMAP_PAGE_ZERO, because by using this
      personality it is possible to have the first page mapped inside a
      process running as setuid root.  This could be used in those scenarios:
      
       - Exploiting a NULL pointer dereference issue in a setuid root binary
       - Bypassing the mmap_min_addr restrictions of the Linux kernel: by
         running a setuid binary that would drop privileges before giving us
         control back (for instance by loading a user-supplied library), we
         could get the first page mapped in a process we control.  By further
         using mremap and mprotect on this mapping, we can then completely
         bypass the mmap_min_addr restrictions.
      
      Less importantly, we believe ADDR_COMPAT_LAYOUT should also be added
      since on x86 32bits it will in practice disable most of the address
      space layout randomization (only the stack will remain randomized).
      Signed-off-by: default avatarJulien Tinnes <jt@cr0.org>
      Signed-off-by: default avatarTavis Ormandy <taviso@sdf.lonestar.org>
      Cc: stable@kernel.org
      Acked-by: default avatarChristoph Hellwig <hch@infradead.org>
      Acked-by: default avatarKees Cook <kees@ubuntu.com>
      Acked-by: default avatarEugene Teo <eugene@redhat.com>
      [ Shortened lines and fixed whitespace as per Christophs' suggestion ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f9fabcb5
    • Linus Torvalds's avatar
      Don't use '-fwrapv' compiler option: it's buggy in gcc-4.1.x · a137802e
      Linus Torvalds authored
      This causes kernel images that don't run init to completion with certain
      broken gcc versions.
      
      This fixes kernel bugzilla entry:
      	http://bugzilla.kernel.org/show_bug.cgi?id=13012
      
      I suspect the gcc problem is this:
      	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
      
      Fix the problem by using the -fno-strict-overflow flag instead, which
      not only does not exist in the known-to-be-broken versions of gcc (it
      was introduced later than fwrapv), but seems to be much less disturbing
      to gcc too: the difference in the generated code by -fno-strict-overflow
      are smaller (compared to using neither flag) than when using -fwrapv.
      Reported-by: default avatarBarry K. Nathan <barryn@pobox.com>
      Pushed-by: default avatarFrans Pop <elendil@planet.nl>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a137802e
  7. 11 Jul, 2009 19 commits