1. 17 Oct, 2006 1 commit
  2. 11 Oct, 2006 7 commits
  3. 03 Oct, 2006 1 commit
  4. 29 Sep, 2006 1 commit
  5. 27 Sep, 2006 5 commits
  6. 27 Aug, 2006 1 commit
  7. 27 Jun, 2006 1 commit
  8. 25 Mar, 2006 2 commits
  9. 23 Mar, 2006 1 commit
  10. 28 Oct, 2005 1 commit
    • Al Viro's avatar
      [PATCH] gfp_t: fs/* · 27496a8c
      Al Viro authored
      
      
       - ->releasepage() annotated (s/int/gfp_t), instances updated
       - missing gfp_t in fs/* added
       - fixed misannotation from the original sweep caught by bitwise checks:
         XFS used __nocast both for gfp_t and for flags used by XFS allocator.
         The latter left with unsigned int __nocast; we might want to add a
         different type for those but for now let's leave them alone.  That,
         BTW, is a case when __nocast use had been actively confusing - it had
         been used in the same code for two different and similar types, with
         no way to catch misuses.  Switch of gfp_t to bitwise had caught that
         immediately...
      
      One tricky bit is left alone to be dealt with later - mapping->flags is
      a mix of gfp_t and error indications.  Left alone for now.
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      27496a8c
  11. 07 Sep, 2005 3 commits
    • Jan Kara's avatar
      [PATCH] Change ll_rw_block() calls in JBD · 26707699
      Jan Kara authored
      
      
      We must be sure that the current data in buffer are sent to disk.  Hence we
      have to call ll_rw_block() with SWRITE.
      
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      26707699
    • Mark Fasheh's avatar
      [PATCH] kjournald: missing JFS_UNMOUNT check · cbf0d27a
      Mark Fasheh authored
      
      
      It seems that kjournald() may be missing a check of the JFS_UNMOUNT flag
      before calling schedule().  This showed up in testing of OCFS2 recovery
      where our recovery thread would hang in journal_kill_thread() called from
      journal_destroy() because kjournald never got a chance to read the flag to
      shut down before the schedule().
      
      Zach pointed out the missing check which led me to hack up this trivial
      patch.  It's been tested many times now and I have yet to reproduce the
      hang, which was happening very regularly before.
      
      <mild rant>
      I'm guessing that we could really use some wait_event() calls with helper
      functions in, well, most of jbd these days which would make a ton of the
      wait code there vastly cleaner.
      </mild rant>
      
      As for why this doesn't happen in ext3 (or OCFS2 during normal
      mount/unmount of the local nodes journal), I think it may that the specific
      timing of events in the ocfs2 recovery thread exposes a race there.
      Because ocfs2_replay_journal() is only interested in playing back the
      journal, initialization and shutdown happen very quicky with no other
      metadata put into that specific journal.
      
      Acked-by: default avatar"Stephen C. Tweedie" <sct@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      cbf0d27a
    • Adrian Bunk's avatar
      [PATCH] fs/jbd/: cleanups · 022a4a7b
      Adrian Bunk authored
      
      
      This patch contains the following cleanups:
      - make needlessly global functions static
      - journal.c: remove the unused global function __journal_internal_check
                   and move the check to journal_init
      - remove the following write-only global variable:
        - journal.c: current_journal
      - remove the following unneeded EXPORT_SYMBOL:
        - journal.c: journal_recover
      
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      Acked-by: default avatarAndreas Dilger <adilger@clusterfs.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      022a4a7b
  12. 25 Jun, 2005 1 commit
    • Christoph Lameter's avatar
      [PATCH] Cleanup patch for process freezing · 3e1d1d28
      Christoph Lameter authored
      
      
      1. Establish a simple API for process freezing defined in linux/include/sched.h:
      
         frozen(process)		Check for frozen process
         freezing(process)		Check if a process is being frozen
         freeze(process)		Tell a process to freeze (go to refrigerator)
         thaw_process(process)	Restart process
         frozen_process(process)	Process is frozen now
      
      2. Remove all references to PF_FREEZE and PF_FROZEN from all
         kernel sources except sched.h
      
      3. Fix numerous locations where try_to_freeze is manually done by a driver
      
      4. Remove the argument that is no longer necessary from two function calls.
      
      5. Some whitespace cleanup
      
      6. Clear potential race in refrigerator (provides an open window of PF_FREEZE
         cleared before setting PF_FROZEN, recalc_sigpending does not check
         PF_FROZEN).
      
      This patch does not address the problem of freeze_processes() violating the rule
      that a task may only modify its own flags by setting PF_FREEZE. This is not clean
      in an SMP environment. freeze(process) is therefore not SMP safe!
      
      Signed-off-by: default avatarChristoph Lameter <christoph@lameter.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3e1d1d28
  13. 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