Skip to content
  1. Aug 06, 2009
  3. Jul 31, 2009
  5. Jul 30, 2009
  7. Jul 23, 2009
  9. Jul 17, 2009
  11. Jul 15, 2009
    • 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
  13. Jul 14, 2009
  15. Jul 13, 2009
    • 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
  17. Jul 12, 2009
  19. Jul 11, 2009