1. 13 2月, 2007 1 次提交
  2. 09 12月, 2006 1 次提交
  3. 01 10月, 2006 4 次提交
  4. 26 6月, 2006 1 次提交
    • N
      [PATCH] Prepare for __copy_from_user_inatomic to not zero missed bytes · 01408c49
      NeilBrown 提交于
      The problem is that when we write to a file, the copy from userspace to
      pagecache is first done with preemption disabled, so if the source address is
      not immediately available the copy fails *and* *zeros* *the* *destination*.
      
      This is a problem because a concurrent read (which admittedly is an odd thing
      to do) might see zeros rather that was there before the write, or what was
      there after, or some mixture of the two (any of these being a reasonable thing
      to see).
      
      If the copy did fail, it will immediately be retried with preemption
      re-enabled so any transient problem with accessing the source won't cause an
      error.
      
      The first copying does not need to zero any uncopied bytes, and doing so
      causes the problem.  It uses copy_from_user_atomic rather than copy_from_user
      so the simple expedient is to change copy_from_user_atomic to *not* zero out
      bytes on failure.
      
      The first of these two patches prepares for the change by fixing two places
      which assume copy_from_user_atomic does zero the tail.  The two usages are
      very similar pieces of code which copy from a userspace iovec into one or more
      page-cache pages.  These are changed to remove the assumption.
      
      The second patch changes __copy_from_user_inatomic* to not zero the tail.
      Once these are accepted, I will look at similar patches of other architectures
      where this is important (ppc, mips and sparc being the ones I can find).
      
      This patch:
      
      There is a problem with __copy_from_user_inatomic zeroing the tail of the
      buffer in the case of an error.  As it is called in atomic context, the error
      may be transient, so it results in zeros being written where maybe they
      shouldn't be.
      
      In the usage in filemap, this opens a window for a well timed read to see data
      (zeros) which is not consistent with any ordering of reads and writes.
      
      Most cases where __copy_from_user_inatomic is called, a failure results in
      __copy_from_user being called immediately.  As long as the latter zeros the
      tail, the former doesn't need to.  However in *copy_from_user_iovec
      implementations (in both filemap and ntfs/file), it is assumed that
      copy_from_user_inatomic will zero the tail.
      
      This patch removes that assumption, so that after this patch it will
      be safe for copy_from_user_inatomic to not zero the tail.
      
      This patch also adds some commentary to filemap.h and asm-i386/uaccess.h.
      
      After this patch, all architectures that might disable preempt when
      kmap_atomic is called need to have their __copy_from_user_inatomic* "fixed".
      This includes
       - powerpc
       - i386
       - mips
       - sparc
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      01408c49
  5. 23 6月, 2006 2 次提交
  6. 29 3月, 2006 1 次提交
  7. 23 3月, 2006 1 次提交
  8. 07 3月, 2006 1 次提交
  9. 24 2月, 2006 1 次提交
  10. 11 1月, 2006 1 次提交
  11. 10 1月, 2006 1 次提交
  12. 24 11月, 2005 1 次提交
  13. 01 11月, 2005 1 次提交
  14. 24 10月, 2005 2 次提交
  15. 19 10月, 2005 2 次提交
  16. 11 10月, 2005 1 次提交
    • A
      NTFS: The big ntfs write(2) rewrite has arrived. We now implement our own · 98b27036
      Anton Altaparmakov 提交于
            file operations ->write(), ->aio_write(), and ->writev() for regular
            files.  This replaces the old use of generic_file_write(), et al and
            the address space operations ->prepare_write and ->commit_write.
            This means that both sparse and non-sparse (unencrypted and
            uncompressed) files can now be extended using the normal write(2)
            code path.  There are two limitations at present and these are that
            we never create sparse files and that we only have limited support
            for highly fragmented files, i.e. ones whose data attribute is split
            across multiple extents.   When such a case is encountered,
            EOPNOTSUPP is returned.
      Signed-off-by: NAnton Altaparmakov <aia21@cantab.net>
      98b27036
  17. 09 9月, 2005 1 次提交
  18. 05 5月, 2005 1 次提交
  19. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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