1. 09 Sep, 2007 1 commit
  2. 04 Sep, 2007 5 commits
  3. 02 Sep, 2007 2 commits
    • David Howells's avatar
      [MTD] Initialise s_flags in get_sb_mtd_aux() · 48440e89
      David Howells authored
      Initialise s_flags in get_sb_mtd_aux() from the flags parameter.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      48440e89
    • Jason Lunz's avatar
      [JFFS2] fix write deadlock regression · fc0e0197
      Jason Lunz authored
      I've bisected the deadlock when many small appends are done on jffs2 down to
      this commit:
      
      commit 6fe6900e
      Author: Nick Piggin <npiggin@suse.de>
      Date:   Sun May 6 14:49:04 2007 -0700
      
          mm: make read_cache_page synchronous
      
          Ensure pages are uptodate after returning from read_cache_page, which allows
          us to cut out most of the filesystem-internal PageUptodate calls.
      
          I didn't have a great look down the call chains, but this appears to fixes 7
          possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in
          ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in
          block2mtd.  All depending on whether the filler is async and/or can return
          with a !uptodate page.
      
      It introduced a wait to read_cache_page, as well as a
      read_cache_page_async function equivalent to the old read_cache_page
      without any callers.
      
      Switching jffs2_gc_fetch_page to read_cache_page_async for the old
      behavior makes the deadlocks go away, but maybe reintroduces the
      use-before-uptodate problem? I don't understand the mm/fs interaction
      well enough to say.
      
      [It's fine. dwmw2.]
      Signed-off-by: default avatarJason Lunz <lunz@falooley.org>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      fc0e0197
  4. 01 Sep, 2007 23 commits
  5. 31 Aug, 2007 9 commits