Skip to content

cloud-kernel
cloud-kernel

yiicenne / cloud-kernel
与 Fork 源项目一致

Fork自 openanolis / cloud-kernel

通知 1
Star 0
Fork 0
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 12 9月, 2006 5 次提交
  3. 10 9月, 2006 2 次提交
  5. 09 9月, 2006 4 次提交
  7. 08 9月, 2006 1 次提交
  9. 07 9月, 2006 5 次提交
  11. 04 9月, 2006 1 次提交
  13. 03 9月, 2006 1 次提交
    • G
      [ARM] 3762/1: Fix ptrace cache coherency bug for ARM1136 VIPT nonaliasing Harvard caches · a188ad2b
      由 George G. Davis 提交于 
      Patch from George G. Davis

Resolve ARM1136 VIPT non-aliasing cache coherency issues observed when
using ptrace to set breakpoints and cleanup copy_{to,from}_user_page()
while we're here as requested by Russell King because "it's also far
too heavy on non-v6 CPUs".

NOTES:

1. Only access_process_vm() calls copy_{to,from}_user_page().
2. access_process_vm() calls get_user_pages() to pin down the "page".
3. get_user_pages() calls flush_dcache_page(page) which ensures cache
   coherency between kernel and userspace mappings of "page".  However
   flush_dcache_page(page) may not invalidate I-Cache over this range
   for all cases, specifically, I-Cache is not invalidated for the VIPT
   non-aliasing case.  So memory is consistent between kernel and user
   space mappings of "page" but I-Cache may still be hot over this
   range.  IOW, we don't have to worry about flush_cache_page() before
   memcpy().
4. Now, for the copy_to_user_page() case, after memcpy(), we must flush
   the caches so memory is consistent with kernel cache entries and
   invalidate the I-Cache if this mm region is executable.  We don't
   need to do anything after memcpy() for the copy_from_user_page()
   case since kernel cache entries will be invalidated via the same
   process above if we access "page" again.  The flush_ptrace_access()
   function (borrowed from SPARC64 implementation) is added to handle
   cache flushing after memcpy() for the copy_to_user_page() case.
Signed-off-by: NGeorge G. Davis <gdavis@mvista.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a188ad2b
  15. 02 9月, 2006 3 次提交
  17. 31 8月, 2006 14 次提交
  19. 30 8月, 2006 4 次提交
    • D
      [ARM] 3750/3: Fix double VFP emulation for EABI kernels · 0355b3e0
      由 Daniel Jacobowitz 提交于 
      Patch from Daniel Jacobowitz

vfp_put_double didn't work in a CONFIG_AEABI kernel.  By swapping
the arguments, we arrange for them to be in the same place regardless
of ABI.  I made the same change to vfp_put_float for consistency.
Signed-off-by: NDaniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      0355b3e0
    • M
      [S390] broken copy_in_user function. · af313e5a
      由 Martin Schwidefsky 提交于 
      The copy_in_user primitive does not work as advertised. If the source
and target area are available copy_in_user copies one byte too much.
If one of the memory areas is not available it does not copy as much
data as it can, but up to 257 bytes less.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      af313e5a
    • P
      [POWERPC] Fix irq enable/disable in smp_generic_take_timebase · 467c3780
      由 Paul Mackerras 提交于 
      Eran Ben-Avi <eranpublic@yahoo.com> pointed out that the arch/ppc version
of smp_generic_take_timebase disables interrupts on entry but exits without
restoring them.  However, both it and the arch/powerpc version have another
problem, which is that they use local_irq_disable/enable rather than
local_irq_save/restore, and they are called with interrupts disabled.

This fixes both problems; it changes a return to a break in the arch/ppc
version, and changes both versions to use local_irq_save/restore.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      467c3780
    • P
      [POWERPC] Fix problem with time not advancing on 32-bit platforms · e0d872d5
      由 Paul Mackerras 提交于 
      This fixes a problem introduced in 5db9fa95.
The last_jiffy per-cpu variable is only 32 bits on 32-bit machines, but it
was being compared with a 64-bit quantity (tb_next_jiffy), which resulted in
time not advancing.

This fixes it by changing last_jiffy to be 64 bits on all platforms.  With
this, we no longer need tb_last_stamp as a 32-bit version of tb_last_jiffy,
so this gets rid of tb_last_stamp and we just use tb_last_jiffy instead.
This also fixes a bug when the boot cpu is not online, because using
tb_last_stamp could have caused the wrong timebase origin value to be used
when calculating the time of day.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e0d872d5