1. 17 5月, 2012 4 次提交
  2. 03 5月, 2012 2 次提交
  3. 21 3月, 2012 1 次提交
  4. 20 3月, 2012 1 次提交
  5. 07 3月, 2012 1 次提交
  6. 01 3月, 2012 1 次提交
  7. 29 2月, 2012 4 次提交
  8. 15 1月, 2012 1 次提交
  9. 13 1月, 2012 2 次提交
  10. 12 1月, 2012 2 次提交
    • A
      UBIFS: fix debugging messages · d34315da
      Artem Bityutskiy 提交于
      Patch 56e46742 broke UBIFS debugging messages:
      before that commit when UBIFS debugging was enabled, users saw few useful
      debugging messages after mount. However, that patch turned 'dbg_msg()' into
      'pr_debug()', so to enable the debugging messages users have to enable them
      first via /sys/kernel/debug/dynamic_debug/control, which is very impractical.
      
      This commit makes 'dbg_msg()' to use 'printk()' instead of 'pr_debug()', just
      as it was before the breakage.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Cc: stable@kernel.org [3.0+]
      d34315da
    • A
      UBIFS: make debugging messages light again · 1f5d78dc
      Artem Bityutskiy 提交于
      We switch to dynamic debugging in commit
      56e46742 but did not take into account that
      now we do not control anymore whether a specific message is enabled or not.
      So now we lock the "dbg_lock" and release it in every debugging macro, which
      make them not so light-weight.
      
      This commit removes the "dbg_lock" protection from the debugging macros to
      fix the issue.
      
      The downside is that now our DBGKEY() stuff is broken, but this is not
      critical at all and will be fixed later.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Cc: stable@kernel.org [3.0+]
      1f5d78dc
  11. 07 1月, 2012 1 次提交
  12. 04 1月, 2012 7 次提交
  13. 14 12月, 2011 1 次提交
  14. 22 11月, 2011 1 次提交
  15. 02 11月, 2011 2 次提交
  16. 31 10月, 2011 1 次提交
    • C
      writeback: Add a 'reason' to wb_writeback_work · 0e175a18
      Curt Wohlgemuth 提交于
      This creates a new 'reason' field in a wb_writeback_work
      structure, which unambiguously identifies who initiates
      writeback activity.  A 'wb_reason' enumeration has been
      added to writeback.h, to enumerate the possible reasons.
      
      The 'writeback_work_class' and tracepoint event class and
      'writeback_queue_io' tracepoints are updated to include the
      symbolic 'reason' in all trace events.
      
      And the 'writeback_inodes_sbXXX' family of routines has had
      a wb_stats parameter added to them, so callers can specify
      why writeback is being started.
      Acked-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NCurt Wohlgemuth <curtw@google.com>
      Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
      0e175a18
  17. 26 8月, 2011 1 次提交
  18. 22 8月, 2011 1 次提交
  19. 19 8月, 2011 1 次提交
  20. 21 7月, 2011 1 次提交
    • J
      fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers · 02c24a82
      Josef Bacik 提交于
      Btrfs needs to be able to control how filemap_write_and_wait_range() is called
      in fsync to make it less of a painful operation, so push down taking i_mutex and
      the calling of filemap_write_and_wait() down into the ->fsync() handlers.  Some
      file systems can drop taking the i_mutex altogether it seems, like ext3 and
      ocfs2.  For correctness sake I just pushed everything down in all cases to make
      sure that we keep the current behavior the same for everybody, and then each
      individual fs maintainer can make up their mind about what to do from there.
      Thanks,
      Acked-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJosef Bacik <josef@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      02c24a82
  21. 08 7月, 2011 1 次提交
    • A
      UBIFS: fix master node recovery · 19495f70
      Anatolij Gustschin 提交于
      When the 1st LEB was unmapped and written but 2nd LEB not,
      the master node recovery doesn't succeed after power cut.
      We see following error when mounting UBIFS partition on NOR
      flash:
      
      UBIFS error (pid 1137): ubifs_recover_master_node: failed to recover master node
      
      Correct 2nd master node offset check is needed to fix the
      problem. If the 2nd master node is at the end in the 2nd LEB,
      first master node is used for recovery. When checking for this
      condition we should check whether the master node is exactly at
      the end of the LEB (without remaining empty space) or whether
      it is followed by an empty space less than the master node size.
      
      Artem: when the error happened, offs2 = 261120, sz = 512, c->leb_size = 262016.
      Signed-off-by: NAnatolij Gustschin <agust@denx.de>
      Signed-off-by: NArtem Bityutskiy <dedekind1@gmail.com>
      19495f70
  22. 04 7月, 2011 3 次提交