1. 10 Oct, 2008 4 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 28 commits
  5. 06 Oct, 2008 6 commits
    • Trond Myklebust's avatar
      NFS: Clean up nfs_sb_active/nfs_sb_deactive · 1daef0a8
      Trond Myklebust authored
      
      
      Instead of causing umount requests to block on server->active_wq while the
      asynchronous sillyrename deletes are executing, we can use the sb->s_active
      counter to obtain a reference to the super_block, and then release that
      reference in nfs_async_unlink_release().
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      1daef0a8
    • Trond Myklebust's avatar
      NFS: Fix nfs_file_llseek() · d5e66348
      Trond Myklebust authored
      
      
      After the BKL removal patches were applied to the rest of the NFS code, the
      BKL protection in nfs_file_llseek() is no longer sufficient to ensure that
      inode->i_size is read safely in generic_file_llseek_unlocked().
      
      In order to fix the situation, we either have to replace the naked read of
      inode->i_size in generic_file_llseek_unlocked() with i_size_read(), or the
      whole thing needs to be executed under the inode->i_lock;
      In order to avoid disrupting other filesystems, avoid touching
      generic_file_llseek_unlocked() for now...
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      d5e66348
    • 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
    • Linus Torvalds's avatar
      Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb · afed26d1
      Linus Torvalds authored
      * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb:
        kgdb: call touch_softlockup_watchdog on resume
        kgdb, x86: Avoid invoking kgdb_nmicallback twice per NMI
      afed26d1
    • Linus Torvalds's avatar
      Merge branch 'x86-fixes-for-linus' of... · 6106611e
      Linus Torvalds authored
      Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        x86: gart iommu have direct mapping when agp is present too
      6106611e