1. 07 3月, 2007 1 次提交
  2. 20 2月, 2007 1 次提交
    • R
      [MIPS] Fixup copy_from_user_inatomic · e03b5269
      Ralf Baechle 提交于
      From the 01408c49 log message:
      
      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.
      
      < --- end cite --- >
      
      This patch finally implements at least a not so pretty solution by
      duplicating the relevant part of __copy_user.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e03b5269
  3. 14 2月, 2007 3 次提交
  4. 11 2月, 2007 1 次提交
  5. 07 2月, 2007 1 次提交
  6. 26 4月, 2006 1 次提交
  7. 22 2月, 2006 1 次提交
  8. 15 2月, 2006 1 次提交
    • R
      [MIPS] More uaccess.h fixes with gcc >= 4.0.1. · 3218357c
      Ralf Baechle 提交于
          
      From Richard Sandiford <richard@codesourcery.com>:
          
      This patch caused a miscompilation of the restore_gp_regs() block
      in restore_sigcontext().  This was in a 32-bit kernel compiled with
      GCC CVS head.
          
      restore_gp_regs() copies 64-bit user fields into 32-bit variables,
      and in this combination, the new __get_user_asm_ll32() clobbers too
      many registers.  It says:
          
      /*
       * Get a long long 64 using 32 bit registers.
       */
      {									\
      	__asm__ __volatile__(						\
      	"1:	lw	%1, (%3)				\n"	\
      	"2:	lw	%D1, 4(%3)				\n"	\
      	"	move	%0, $0					\n"	\
      	"3:	.section	.fixup,\"ax\"			\n"	\
      	"4:	li	%0, %4					\n"	\
      	"	move	%1, $0					\n"	\
      	"	move	%D1, $0					\n"	\
      	"	j	3b					\n"	\
      	"	.previous					\n"	\
      	"	.section	__ex_table,\"a\"		\n"	\
      	"	" __UA_ADDR "	1b, 4b				\n"	\
      	"	" __UA_ADDR "	2b, 4b				\n"	\
      	"	.previous					\n"	\
      	: "=r" (__gu_err), "=&r" (val)					\
      	: "0" (0), "r" (addr), "i" (-EFAULT));				\
      }
      
      and this requires val (%1) to be a 64-bit value.  In the case I saw,
      gcc was using $3 for the 32-bit val, and wasn't expecting $4 to be
      clobbered.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      3218357c
  9. 07 2月, 2006 1 次提交
  10. 30 10月, 2005 2 次提交
  11. 08 9月, 2005 1 次提交
  12. 05 9月, 2005 1 次提交
  13. 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