1. 18 May, 2010 5 commits
  2. 11 May, 2010 1 commit
  3. 08 May, 2010 1 commit
  4. 06 May, 2010 1 commit
  5. 26 Apr, 2010 1 commit
    • Jerome Glisse's avatar
      drm/radeon/kms: R3XX-R4XX fix GPU reset code · a1e9ada3
      Jerome Glisse authored
      Previous reset code leaded to computer hard lockup (need to unplug
      the power too reboot the computer) on various configuration. This
      patch change the reset code to avoid hard lockup. The GPU reset
      is failing most of the time but at least user can log in remotely
      or properly shutdown the computer.
      
      Two issues were leading to hard lockup :
      - Writting to the scratch register lead to hard lockup most likely
      because the write back mecanism is in fuzy state after GPU lockup.
      - Resetting the GPU memory controller and not reinitializing it
      after leaded to hard lockup. We did only reinitialize in case of
      successfull reset thus unsuccessfull reset quickly leaded to hard
      lockup.
      Signed-off-by: default avatarJerome Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      a1e9ada3
  6. 23 Apr, 2010 3 commits
  7. 20 Apr, 2010 22 commits
  8. 19 Apr, 2010 6 commits
    • Linus Torvalds's avatar
      Linux 2.6.34-rc5 · 01bf0b64
      Linus Torvalds authored
      01bf0b64
    • Rik van Riel's avatar
      rmap: add exclusively owned pages to the newest anon_vma · e8a03feb
      Rik van Riel authored
      The recent anon_vma fixes cause many anonymous pages to end up
      in the parent process anon_vma, even when the page is exclusively
      owned by the current process.
      
      Adding exclusively owned anonymous pages to the top anon_vma
      reduces rmap scanning overhead, especially in workloads with
      forking servers.
      
      This patch adds a parameter to __page_set_anon_rmap that can
      be used to indicate whether or not the added page is exclusively
      owned by the current process.
      
      Pages added through page_add_new_anon_rmap are exclusively
      owned by the current process, and can be added to the top
      anon_vma.
      
      Pages added through page_add_anon_rmap can be either shared
      or exclusively owned, so we do the conservative thing and
      add it to the oldest anon_vma.
      
      A next step would be to add the exclusive parameter to
      page_add_anon_rmap, to be used from functions where we do
      know for sure whether a page is exclusively owned.
      Signed-off-by: default avatarRik van Riel <riel@redhat.com>
      Reviewed-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Lightly-tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Reviewed-by: default avatarMinchan Kim <minchan.kim@gmail.com>
      [ Edited to look nicer  - Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e8a03feb
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ecryptfs/ecryptfs-2.6 · 9b030e20
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ecryptfs/ecryptfs-2.6:
        eCryptfs: Turn lower lookup error messages into debug messages
        eCryptfs: Copy lower directory inode times and size on link
        ecryptfs: fix use with tmpfs by removing d_drop from ecryptfs_destroy_inode
        ecryptfs: fix error code for missing xattrs in lower fs
        eCryptfs: Decrypt symlink target for stat size
        eCryptfs: Strip metadata in xattr flag in encrypted view
        eCryptfs: Clear buffer before reading in metadata xattr
        eCryptfs: Rename ecryptfs_crypt_stat.num_header_bytes_at_front
        eCryptfs: Fix metadata in xattr feature regression
      9b030e20
    • Tyler Hicks's avatar
      eCryptfs: Turn lower lookup error messages into debug messages · 9f37622f
      Tyler Hicks authored
      Vaugue warnings about ENAMETOOLONG errors when looking up an encrypted
      file name have caused many users to become concerned about their data.
      Since this is a rather harmless condition, I'm moving this warning to
      only be printed when the ecryptfs_verbosity module param is 1.
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      9f37622f
    • Tyler Hicks's avatar
      eCryptfs: Copy lower directory inode times and size on link · 3a8380c0
      Tyler Hicks authored
      The timestamps and size of a lower inode involved in a link() call was
      being copied to the upper parent inode.  Instead, we should be
      copying lower parent inode's timestamps and size to the upper parent
      inode.  I discovered this bug using the POSIX test suite at Tuxera.
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      3a8380c0
    • Jeff Mahoney's avatar
      ecryptfs: fix use with tmpfs by removing d_drop from ecryptfs_destroy_inode · 133b8f9d
      Jeff Mahoney authored
      Since tmpfs has no persistent storage, it pins all its dentries in memory
      so they have d_count=1 when other file systems would have d_count=0.
      ->lookup is only used to create new dentries. If the caller doesn't
      instantiate it, it's freed immediately at dput(). ->readdir reads
      directly from the dcache and depends on the dentries being hashed.
      
      When an ecryptfs mount is mounted, it associates the lower file and dentry
      with the ecryptfs files as they're accessed. When it's umounted and
      destroys all the in-memory ecryptfs inodes, it fput's the lower_files and
      d_drop's the lower_dentries. Commit 4981e081 added this and a d_delete in
      2008 and several months later commit caeeeecf removed the d_delete. I
      believe the d_drop() needs to be removed as well.
      
      The d_drop effectively hides any file that has been accessed via ecryptfs
      from the underlying tmpfs since it depends on it being hashed for it to
      be accessible. I've removed the d_drop on my development node and see no
      ill effects with basic testing on both tmpfs and persistent storage.
      
      As a side effect, after ecryptfs d_drops the dentries on tmpfs, tmpfs
      BUGs on umount. This is due to the dentries being unhashed.
      tmpfs->kill_sb is kill_litter_super which calls d_genocide to drop
      the reference pinning the dentry. It skips unhashed and negative dentries,
      but shrink_dcache_for_umount_subtree doesn't. Since those dentries
      still have an elevated d_count, we get a BUG().
      
      This patch removes the d_drop call and fixes both issues.
      
      This issue was reported at:
      https://bugzilla.novell.com/show_bug.cgi?id=567887Reported-by: default avatarÁrpád Bíró <biroa@demasz.hu>
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Cc: Dustin Kirkland <kirkland@canonical.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      133b8f9d