1. 18 Apr, 2005 4 commits
    • David S. Miller's avatar
      [PATCH] sparc64: Reduce ptrace cache flushing · dadeafdf
      David S. Miller authored
      We were flushing the D-cache excessively for ptrace() processing
      and this makes debugging threads so slow as to be totally unusable.
      
      All process page accesses via ptrace() go via access_process_vm().
      This routine, for each process page, uses get_user_pages().  That
      in turn does a flush_dcache_page() on the child pages before we
      copy in/out the ptrace request data.
      
      Therefore, all we need to do after the data movement is:
      
      1) Flush the D-cache pages if the kernel maps the page to a different
         color than userspace does.
      2) If we wrote to the page, we need to flush the I-cache on older cpus.
      
      Previously we just flushed the entire cache at the end of a ptrace()
      request, and that was beyond stupid.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      dadeafdf
    • David S. Miller's avatar
      [PATCH] sparc: Fix PTRACE_CONT bogosity · fb65b961
      David S. Miller authored
      SunOS aparently had this weird PTRACE_CONT semantic which
      we copied.  If the addr argument is something other than
      1, it sets the process program counter to whatever that
      value is.
      
      This is different from every other Linux architecture, which
      don't do anything with the addr and data args.
      
      This difference in particular breaks the Linux native GDB support
      for fork and vfork tracing on sparc and sparc64.
      
      There is no interest in running SunOS binaries using this weird
      PTRACE_CONT behavior, so just delete it so we behave like other
      platforms do.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      fb65b961
    • David S. Miller's avatar
      [PATCH] sparc64: use message queue compat syscalls · 961f8bc9
      David S. Miller authored
      A couple message queue system call entries for compat tasks
      were not using the necessary compat_sys_*() functions, causing
      some glibc test cases to fail.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      961f8bc9
    • David S. Miller's avatar
      [PATCH] sparc64: Do not flush dcache for ZERO_PAGE. · a9546f59
      David S. Miller authored
      This case actually can get exercised a lot during an ELF
      coredump of a process which contains a lot of non-COW'd
      anonymous pages.  GDB has this test case which in partiaular
      creates near terabyte process full of ZERO_PAGEes.  It takes
      forever to just walk through the page tables because of
      all of these spurious cache flushes on sparc64.
      
      With this change it takes only a second or so.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a9546f59
  2. 17 Apr, 2005 8 commits
  3. 16 Apr, 2005 28 commits