1. 19 Apr, 2006 1 commit
  2. 24 Mar, 2006 2 commits
    • Paul Jackson's avatar
      [PATCH] cpuset memory spread: slab cache format · fffb60f9
      Paul Jackson authored
      
      
      Rewrap the overly long source code lines resulting from the previous
      patch's addition of the slab cache flag SLAB_MEM_SPREAD.  This patch
      contains only formatting changes, and no function change.
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      fffb60f9
    • Paul Jackson's avatar
      [PATCH] cpuset memory spread: slab cache filesystems · 4b6a9316
      Paul Jackson authored
      
      
      Mark file system inode and similar slab caches subject to SLAB_MEM_SPREAD
      memory spreading.
      
      If a slab cache is marked SLAB_MEM_SPREAD, then anytime that a task that's
      in a cpuset with the 'memory_spread_slab' option enabled goes to allocate
      from such a slab cache, the allocations are spread evenly over all the
      memory nodes (task->mems_allowed) allowed to that task, instead of favoring
      allocation on the node local to the current cpu.
      
      The following inode and similar caches are marked SLAB_MEM_SPREAD:
      
          file                               cache
          ====                               =====
          fs/adfs/super.c                    adfs_inode_cache
          fs/affs/super.c                    affs_inode_cache
          fs/befs/linuxvfs.c                 befs_inode_cache
          fs/bfs/inode.c                     bfs_inode_cache
          fs/block_dev.c                     bdev_cache
          fs/cifs/cifsfs.c                   cifs_inode_cache
          fs/coda/inode.c                    coda_inode_cache
          fs/dquot.c                         dquot
          fs/efs/super.c                     efs_inode_cache
          fs/ext2/super.c                    ext2_inode_cache
          fs/ext2/xattr.c (fs/mbcache.c)     ext2_xattr
          fs/ext3/super.c                    ext3_inode_cache
          fs/ext3/xattr.c (fs/mbcache.c)     ext3_xattr
          fs/fat/cache.c                     fat_cache
          fs/fat/inode.c                     fat_inode_cache
          fs/freevxfs/vxfs_super.c           vxfs_inode
          fs/hpfs/super.c                    hpfs_inode_cache
          fs/isofs/inode.c                   isofs_inode_cache
          fs/jffs/inode-v23.c                jffs_fm
          fs/jffs2/super.c                   jffs2_i
          fs/jfs/super.c                     jfs_ip
          fs/minix/inode.c                   minix_inode_cache
          fs/ncpfs/inode.c                   ncp_inode_cache
          fs/nfs/direct.c                    nfs_direct_cache
          fs/nfs/inode.c                     nfs_inode_cache
          fs/ntfs/super.c                    ntfs_big_inode_cache_name
          fs/ntfs/super.c                    ntfs_inode_cache
          fs/ocfs2/dlm/dlmfs.c               dlmfs_inode_cache
          fs/ocfs2/super.c                   ocfs2_inode_cache
          fs/proc/inode.c                    proc_inode_cache
          fs/qnx4/inode.c                    qnx4_inode_cache
          fs/reiserfs/super.c                reiser_inode_cache
          fs/romfs/inode.c                   romfs_inode_cache
          fs/smbfs/inode.c                   smb_inode_cache
          fs/sysv/inode.c                    sysv_inode_cache
          fs/udf/super.c                     udf_inode_cache
          fs/ufs/super.c                     ufs_inode_cache
          net/socket.c                       sock_inode_cache
          net/sunrpc/rpc_pipe.c              rpc_inode_cache
      
      The choice of which slab caches to so mark was quite simple.  I marked
      those already marked SLAB_RECLAIM_ACCOUNT, except for fs/xfs, dentry_cache,
      inode_cache, and buffer_head, which were marked in a previous patch.  Even
      though SLAB_RECLAIM_ACCOUNT is for a different purpose, it marks the same
      potentially large file system i/o related slab caches as we need for memory
      spreading.
      
      Given that the rule now becomes "wherever you would have used a
      SLAB_RECLAIM_ACCOUNT slab cache flag before (usually the inode cache), use
      the SLAB_MEM_SPREAD flag too", this should be easy enough to maintain.
      Future file system writers will just copy one of the existing file system
      slab cache setups and tend to get it right without thinking.
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4b6a9316
  3. 20 Mar, 2006 24 commits
  4. 14 Mar, 2006 1 commit
    • Trond Myklebust's avatar
      [PATCH] NFS: Fix a potential panic in O_DIRECT · 143f412e
      Trond Myklebust authored
      
      
      Based on an original patch by Mike O'Connor and Greg Banks of SGI.
      
      Mike states:
      
      A normal user can panic an NFS client and cause a local DoS with
      'judicious'(?) use of O_DIRECT.  Any O_DIRECT write to an NFS file where the
      user buffer starts with a valid mapped page and contains an unmapped page,
      will crash in this way.  I haven't followed the code, but O_DIRECT reads with
      similar user buffers will probably also crash albeit in different ways.
      
      Details: when nfs_get_user_pages() calls get_user_pages(), it detects and
      correctly handles get_user_pages() returning an error, which happens if the
      first page covered by the user buffer's address range is unmapped.  However,
      if the first page is mapped but some subsequent page isn't, get_user_pages()
      will return a positive number which is less than the number of pages requested
      (this behaviour is sort of analagous to a short write() call and appears to be
      intentional).  nfs_get_user_pages() doesn't detect this and hands off the
      array of pages (whose last few elements are random rubbish from the newly
      allocated array memory) to it's caller, whence they go to
      nfs_direct_write_seg(), which then totally ignores the nr_pages it's given,
      and calculates its own idea of how many pages are in the array from the user
      buffer length.  Needless to say, when it comes to transmit those uninitialised
      page* pointers, we see a crash in the network stack.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      143f412e
  5. 01 Feb, 2006 1 commit
  6. 06 Jan, 2006 5 commits
  7. 19 Dec, 2005 1 commit
  8. 04 Nov, 2005 1 commit
  9. 23 Jun, 2005 1 commit
  10. 22 Jun, 2005 1 commit
    • Trond Myklebust's avatar
      [PATCH] NFS: Fix the file size revalidation · 951a143b
      Trond Myklebust authored
      
      
       Instead of looking at whether or not the file is open for writes before
       we accept to update the length using the server value, we should rather
       be looking at whether or not we are currently caching any writes.
      
       Failure to do so means in particular that we're not updating the file
       length correctly after obtaining a POSIX or BSD lock.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      951a143b
  11. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4