1. 27 2月, 2010 3 次提交
  2. 23 2月, 2010 1 次提交
  3. 11 2月, 2010 1 次提交
  4. 13 1月, 2010 1 次提交
  5. 12 1月, 2010 1 次提交
  6. 17 12月, 2009 3 次提交
  7. 10 12月, 2009 1 次提交
    • C
      vfs: Implement proper O_SYNC semantics · 6b2f3d1f
      Christoph Hellwig 提交于
      While Linux provided an O_SYNC flag basically since day 1, it took until
      Linux 2.4.0-test12pre2 to actually get it implemented for filesystems,
      since that day we had generic_osync_around with only minor changes and the
      great "For now, when the user asks for O_SYNC, we'll actually give
      O_DSYNC" comment.  This patch intends to actually give us real O_SYNC
      semantics in addition to the O_DSYNC semantics.  After Jan's O_SYNC
      patches which are required before this patch it's actually surprisingly
      simple, we just need to figure out when to set the datasync flag to
      vfs_fsync_range and when not.
      
      This patch renames the existing O_SYNC flag to O_DSYNC while keeping it's
      numerical value to keep binary compatibility, and adds a new real O_SYNC
      flag.  To guarantee backwards compatiblity it is defined as expanding to
      both the O_DSYNC and the new additional binary flag (__O_SYNC) to make
      sure we are backwards-compatible when compiled against the new headers.
      
      This also means that all places that don't care about the differences can
      just check O_DSYNC and get the right behaviour for O_SYNC, too - only
      places that actuall care need to check __O_SYNC in addition.  Drivers and
      network filesystems have been updated in a fail safe way to always do the
      full sync magic if O_DSYNC is set.  The few places setting O_SYNC for
      lower layers are kept that way for now to stay failsafe.
      
      We enforce that O_DSYNC is set when __O_SYNC is set early in the open path
      to make sure we always get these sane options.
      
      Note that parisc really screwed up their headers as they already define a
      O_DSYNC that has always been a no-op.  We try to repair it by using it for
      the new O_DSYNC and redefinining O_SYNC to send both the traditional
      O_SYNC numerical value _and_ the O_DSYNC one.
      
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andreas Dilger <adilger@sun.com>
      Acked-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Acked-by: NUlrich Drepper <drepper@redhat.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJan Kara <jack@suse.cz>
      6b2f3d1f
  8. 14 11月, 2009 1 次提交
  9. 02 11月, 2009 1 次提交
    • K
      MIPS: Fix machine check exception in kmap_coherent() · 0f334a3e
      Kevin Cernekee 提交于
      On an SMP system with cache aliases, the following sequence of events may
      happen:
      
      1) copy_user_highpage() runs on CPU0, invoking kmap_coherent() to create a
         temporary mapping in the fixmap region
      2) copy_page() starts on CPU0
      3) CPU1 sends CPU0 an IPI asking CPU0 to run local_r4k_flush_cache_page()
      4) CPU0 takes the interrupt, interrupting copy_page()
      5) local_r4k_flush_cache_page() on CPU0 calls kmap_coherent() again
      6) The second invocation of kmap_coherent() on CPU0 tries to use the
         same fixmap virtual address that was being used by copy_user_highpage()
      7) CPU0 throws a machine check exception for the TLB address conflict
      
      Fixed by creating an extra set of fixmap entries for use in interrupt
      handlers.  This prevents fixmap VA conflicts between copy_user_highpage()
      running in user context, and local_r4k_flush_cache_page() invoked from an
      SMP IPI.
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      0f334a3e
  10. 01 10月, 2009 1 次提交
  11. 24 9月, 2009 1 次提交
  12. 23 9月, 2009 3 次提交
  13. 22 9月, 2009 1 次提交
  14. 18 9月, 2009 4 次提交
  15. 04 8月, 2009 3 次提交
  16. 13 7月, 2009 1 次提交
  17. 25 6月, 2009 1 次提交
  18. 22 6月, 2009 1 次提交
  19. 17 6月, 2009 10 次提交
  20. 21 5月, 2009 1 次提交
    • G
      MIPS: 64-bit: Fix system lockup. · a5e696e5
      Greg Ungerer 提交于
      The address range size calculation inside local_flush_tlb_kernel_range()
      is being truncated by a too small size variable holder on 64-bit systems.
      The truncated size can result in an erroneous tlbsize check that means we
      sit spinning inside a loop trying to flush a hige number of TLB entries.
      This is for all intents and purposes a system hang. Fix by using an
      appropriately sized valiable to hold the size.
      
      [Ralf: Greg's original patch submission identified the issue and fixed one
      instance in tlb-r4k.c but there there were several more.  For consistency
      I also modified tlb-r3k.c even though that file is only used on 32-bit.]
      Signed-off-by: NGreg Ungerer <gerg@snapgear.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a5e696e5