1. 10 10月, 2007 21 次提交
  2. 29 9月, 2007 1 次提交
  3. 20 7月, 2007 2 次提交
  4. 11 7月, 2007 4 次提交
  5. 22 5月, 2007 1 次提交
    • A
      Detach sched.h from mm.h · e8edc6e0
      Alexey Dobriyan 提交于
      First thing mm.h does is including sched.h solely for can_do_mlock() inline
      function which has "current" dereference inside. By dealing with can_do_mlock()
      mm.h can be detached from sched.h which is good. See below, why.
      
      This patch
      a) removes unconditional inclusion of sched.h from mm.h
      b) makes can_do_mlock() normal function in mm/mlock.c
      c) exports can_do_mlock() to not break compilation
      d) adds sched.h inclusions back to files that were getting it indirectly.
      e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
         getting them indirectly
      
      Net result is:
      a) mm.h users would get less code to open, read, preprocess, parse, ... if
         they don't need sched.h
      b) sched.h stops being dependency for significant number of files:
         on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
         after patch it's only 3744 (-8.3%).
      
      Cross-compile tested on
      
      	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
      	alpha alpha-up
      	arm
      	i386 i386-up i386-defconfig i386-allnoconfig
      	ia64 ia64-up
      	m68k
      	mips
      	parisc parisc-up
      	powerpc powerpc-up
      	s390 s390-up
      	sparc sparc-up
      	sparc64 sparc64-up
      	um-x86_64
      	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
      
      as well as my two usual configs.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8edc6e0
  6. 15 5月, 2007 1 次提交
    • T
      NFS: Fix some 'sparse' warnings... · 10afec90
      Trond Myklebust 提交于
       - fs/nfs/dir.c:610:8: warning: symbol 'nfs_llseek_dir' was not declared.
         Should it be static?
       - fs/nfs/dir.c:636:5: warning: symbol 'nfs_fsync_dir' was not declared.
         Should it be static?
       - fs/nfs/write.c:925:19: warning: symbol 'req' shadows an earlier one
       - fs/nfs/write.c:61:6: warning: symbol 'nfs_commit_rcu_free' was not
         declared. Should it be static?
       - fs/nfs/nfs4proc.c:793:5: warning: symbol 'nfs4_recover_expired_lease'
         was not declared. Should it be static?
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      10afec90
  7. 10 5月, 2007 3 次提交
  8. 08 5月, 2007 1 次提交
  9. 01 5月, 2007 2 次提交
    • N
      NFS: Fix directory caching problem - with test case and patch. · 83672d39
      Neil Brown 提交于
      Try running this script in an NFS mounted directory (Client relatively
      recent - 2.6.18 has the problem as does 2.6.20).
      
      ------------------------------------------------------
      #!/bin/bash
      #
      # This script will produce the following errormessage from tar:
      #
      #   tar: newdir/innerdir/innerfile: file changed as we read it
      
      # create dirs
      rm -rf nfstest
      mkdir -p nfstest/dir/innerdir
      
      # create files (should not be empty)
      echo "Hello World!" >nfstest/dir/file
      echo "Hello World!" >nfstest/dir/innerdir/innerfile
      
      # problem only happens if we sleep before chmod
      sleep 1
      
      # change file modes
      chmod -R a+r nfstest
      
      # rename dir
      mv nfstest/dir nfstest/newdir
      
      # tar it
      tar -cf nfstest/nfstest.tar -C nfstest newdir
      
      # restore old dir name
      mv nfstest/newdir nfstest/dir
      --------------------------------------------------------
      
      What happens:
      
      The 'chmod -R' does a readdir_plus in each directory and the results
      get cached in the page cache.  It then updates the ctime on each file
      by one second.  When this happens, the post-op attributes are used to
      update the ctime stored on the client to match the value in the kernel.
      
      The 'mv' calls shrink_dcache_parent on the directory tree which
      flushes all the dentries (so a new lookup will be required) but
      doesn't flush the inodes or pagecache.
      
      The 'tar' does a readdir on each directory, but (in the case of
      'innerdir' at least) satisfies it from the pagecache and uses the
      READDIRPLUS data to update all the inodes.  In the case of
      'innerdir/innerfile', the ctime is out of date.
      
      'tar' then calls 'lstat' on innerdir/innerfile getting an old ctime.
      It then opens the file (triggering a GETATTR), reads the content, and
      then calls fstat to see if anything has changed.  It finds that ctime
      has changed and so complains.
      
      The problem seems to be that the cache readdirplus info is kept around
      for too long.
      
      My patch below discards pagecache data for directories when
      dentry_iput is called on them.  This effectively removes the symptom
      which convinces me that I correctly understand the problem.  However
      I'm not convinced that is a proper solution, as there could easily be
      other races that trigger the same problem without being affected by
      this 'fix'.
      
      One possibility would be to require that readdirplus pagecache data be
      only used *once* to instantiate an inode.  Somehow it should then be
      invalidated so that if the dentry subsequently disappears, it will
      cause a new request to the server to fill in the stat data.
      
      Another possibility is to compare the cache_change_attribute on the
      inode with something similar for the readdirplus info and reject the
      info from readdirplus if it is too old.
      
      I haven't tried to implement these and would value other opinions
      before I do.
      
      Thanks,
      NeilBrown
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      83672d39
    • N
      NFS: Set meaningful value for fattr->time_start in readdirplus results. · 1f4eab7e
      Neil Brown 提交于
      Don't use uninitialsed value for fattr->time_start in readdirplus results.
      
      The 'fattr' structure filled in by nfs3_decode_direct does not get a
      value for ->time_start set.
      Thus if an entry is for an inode that we already have in cache,
      when nfs_readdir_lookup calls nfs_fhget, it will call nfs_refresh_inode
      and may update the inode with out-of-date information.
      
      Directories are read a page at a time, so each page could have a
      different timestamp that "should" be used to set the time_start for
      the fattr for info in that page.  However storing the timestamp per
      page is awkward.  (We could stick in the first 4 bytes and only read 4092
      bytes, but that is a bigger code change than I am interested it).
      
      This patch ignores the readdir_plus attributes if a readdir finds the
      information already in cache, and otherwise sets ->time_start to the time
      the readdir request was sent to the server.
      
      It might be nice to store - in the directory inode - the time stamp for
      the earliest readdir request that is still in the page cache, so that we
      don't ignore attribute data that we don't have to.  This patch doesn't do
      that.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      1f4eab7e
  10. 15 4月, 2007 1 次提交
  11. 13 2月, 2007 1 次提交
  12. 04 2月, 2007 2 次提交