1. 10 Oct, 2008 6 commits
  2. 09 Oct, 2008 1 commit
    • Trond Myklebust's avatar
      NFS: Fix attribute updates · 03254e65
      Trond Myklebust authored
      This fixes a regression seen when running the Connectathon testsuite
      against an ext3 filesystem. The reason was that the inode was constantly
      being marked as 'just updated' by the jiffy wraparound test.
      This again meant that newer GETATTR calls were failing to pass the
      nfs_inode_attrs_need_update() test unless the changes caused a ctime update
      on the server, since they were perceived as having been started before the
      latest inode update.
      
      Given that nfs_inode_attrs_need_update() already checks for wraparound
      of nfsi->last_updated, we can drop the buggy "protection" in
      nfs_update_inode().
      
      Also make a slight micro-optimisation of nfs_inode_attrs_need_update(): we
      are more often going to see time_after(fattr->time_start, nfsi->last_updated)
      be true, rather than seeing an update of ctime/size, so put that test
      first to ensure that we optimise away the ctime/size tests.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      03254e65
  3. 08 Oct, 2008 1 commit
  4. 07 Oct, 2008 30 commits
  5. 06 Oct, 2008 2 commits
    • Linus Torvalds's avatar
      Linux 2.6.27-rc9 · 4330ed8e
      Linus Torvalds authored
      4330ed8e
    • Mathieu Desnoyers's avatar
      Marker depmod fix core kernel list · 87f3b6b6
      Mathieu Desnoyers authored
      * Theodore Ts'o (tytso@mit.edu) wrote:
      >
      > I've been playing with adding some markers into ext4 to see if they
      > could be useful in solving some problems along with Systemtap.  It
      > appears, though, that as of 2.6.27-rc8, markers defined in code which is
      > compiled directly into the kernel (i.e., not as modules) don't show up
      > in Module.markers:
      >
      > kvm_trace_entryexit arch/x86/kvm/kvm-intel  %u %p %u %u %u %u %u %u
      > kvm_trace_handler arch/x86/kvm/kvm-intel  %u %p %u %u %u %u %u %u
      > kvm_trace_entryexit arch/x86/kvm/kvm-amd  %u %p %u %u %u %u %u %u
      > kvm_trace_handler arch/x86/kvm/kvm-amd  %u %p %u %u %u %u %u %u
      >
      > (Note the lack of any of the kernel_sched_* markers, and the markers I
      > added for ext4_* and jbd2_* are missing as wel.)
      >
      > Systemtap apparently depends on in-kernel trace_mark being recorded in
      > Module.markers, and apparently it's been claimed that it used to be
      > there.  Is this a bug in systemtap, or in how Module.markers is getting
      > built?   And is there a file that contains the equivalent information
      > for markers located in non-modules code?
      
      I think the problem comes from "markers: fix duplicate modpost entry"
      (commit d35cb360)
      
      Especially :
      
        -   add_marker(mod, marker, fmt);
        +   if (!mod->skip)
        +     add_marker(mod, marker, fmt);
          }
          return;
         fail:
      
      Here is a fix that should take care if this problem.
      
      Thanks for the bug report!
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Tested-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      CC: Greg KH <greg@kroah.com>
      CC: David Smith <dsmith@redhat.com>
      CC: Roland McGrath <roland@redhat.com>
      CC: Sam Ravnborg <sam@ravnborg.org>
      CC: Wenji Huang <wenji.huang@oracle.com>
      CC: Takashi Nishiie <t-nishiie@np.css.fujitsu.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      87f3b6b6