1. 26 6月, 2008 1 次提交
  2. 20 5月, 2008 1 次提交
  3. 13 5月, 2008 1 次提交
  4. 12 5月, 2008 1 次提交
    • R
      sparc32: Fix build. · b5e10df6
      Robert Reif 提交于
      Fix sparc32 build error due to undefined bool type.
      
      CC [M] fs/ocfs2/dlm/userdlm.o
      In file included from include/asm/sigcontext.h:6,
      from include/asm/signal.h:5,
      from include/linux/signal.h:4,
      from fs/ocfs2/dlm/userdlm.c:30:
      include/asm/ptrace.h:42: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or 
      ‘__attribute__’ before ‘pt_regs_is_syscall’
      include/asm/ptrace.h:47: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or 
      ‘__attribute__’ before ‘pt_regs_clear_syscall’
      make[3]: *** [fs/ocfs2/dlm/userdlm.o] Error 1
      make[2]: *** [fs/ocfs2/dlm] Error 2
      make[1]: *** [fs/ocfs2] Error 2
      make: *** [fs] Error 2
      Signed-off-by: NRobert Reif <reif@earthlink.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5e10df6
  5. 11 5月, 2008 2 次提交
    • D
      sparc: Fix debugger syscall restart interactions. · 28e61036
      David S. Miller 提交于
      So, forever, we've had this ptrace_signal_deliver implementation
      which tries to handle all of the nasties that can occur when the
      debugger looks at a process about to take a signal.  It's meant
      to address all of these issues inside of the kernel so that the
      debugger need not be mindful of such things.
      
      Problem is, this doesn't work.
      
      The idea was that we should do the syscall restart business first, so
      that the debugger captures that state.  Otherwise, if the debugger for
      example saves the child's state, makes the child execute something
      else, then restores the saved state, we won't handle the syscall
      restart properly because we lose the "we're in a syscall" state.
      
      The code here worked for most cases, but if the debugger actually
      passes the signal through to the child unaltered, it's possible that
      we would do a syscall restart when we shouldn't have.
      
      In particular this breaks the case of debugging a process under a gdb
      which is being debugged by yet another gdb.  gdb uses sigsuspend
      to wait for SIGCHLD of the inferior, but if gdb itself is being
      debugged by a top-level gdb we get a ptrace_stop().  The top-level gdb
      does a PTRACE_CONT with SIGCHLD to let the inferior gdb see the
      signal.  But ptrace_signal_deliver() assumed the debugger would cancel
      out the signal and therefore did a syscall restart, because the return
      error was ERESTARTNOHAND.
      
      Fix this by simply making ptrace_signal_deliver() a nop, and providing
      a way for the debugger to control system call restarting properly:
      
      1) Report a "in syscall" software bit in regs->{tstate,psr}.
         It is set early on in trap entry to a system call and is fully
         visible to the debugger via ptrace() and regsets.
      
      2) Test this bit right before doing a syscall restart.  We have
         to do a final recheck right after get_signal_to_deliver() in
         case the debugger cleared the bit during ptrace_stop().
      
      3) Clear the bit in trap return so we don't accidently try to set
         that bit in the real register.
      
      As a result we also get a ptrace_{is,clear}_syscall() for sparc32 just
      like sparc64 has.
      
      M68K has this same exact bug, and is now the only other user of the
      ptrace_signal_deliver hook.  It needs to be fixed in the same exact
      way as sparc.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28e61036
    • D
      sparc: Fix ptrace() detach. · 986bef85
      David S. Miller 提交于
      Forever we had a PTRACE_SUNOS_DETACH which was unconditionally
      recognized, regardless of the personality of the process.
      
      Unfortunately, this value is what ended up in the GLIBC sys/ptrace.h
      header file on sparc as PTRACE_DETACH and PT_DETACH.
      
      So continue to recognize this old value.  Luckily, it doesn't conflict
      with anything we actually care about.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      986bef85
  6. 03 5月, 2008 1 次提交
  7. 02 5月, 2008 3 次提交
  8. 29 4月, 2008 3 次提交
  9. 28 4月, 2008 1 次提交
    • N
      mm: introduce pte_special pte bit · 7e675137
      Nick Piggin 提交于
      s390 for one, cannot implement VM_MIXEDMAP with pfn_valid, due to their memory
      model (which is more dynamic than most).  Instead, they had proposed to
      implement it with an additional path through vm_normal_page(), using a bit in
      the pte to determine whether or not the page should be refcounted:
      
      vm_normal_page()
      {
      	...
              if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) {
                      if (vma->vm_flags & VM_MIXEDMAP) {
      #ifdef s390
      			if (!mixedmap_refcount_pte(pte))
      				return NULL;
      #else
                              if (!pfn_valid(pfn))
                                      return NULL;
      #endif
                              goto out;
                      }
      	...
      }
      
      This is fine, however if we are allowed to use a bit in the pte to determine
      refcountedness, we can use that to _completely_ replace all the vma based
      schemes.  So instead of adding more cases to the already complex vma-based
      scheme, we can have a clearly seperate and simple pte-based scheme (and get
      slightly better code generation in the process):
      
      vm_normal_page()
      {
      #ifdef s390
      	if (!mixedmap_refcount_pte(pte))
      		return NULL;
      	return pte_page(pte);
      #else
      	...
      #endif
      }
      
      And finally, we may rather make this concept usable by any architecture rather
      than making it s390 only, so implement a new type of pte state for this.
      Unfortunately the old vma based code must stay, because some architectures may
      not be able to spare pte bits.  This makes vm_normal_page a little bit more
      ugly than we would like, but the 2 cases are clearly seperate.
      
      So introduce a pte_special pte state, and use it in mm/memory.c.  It is
      currently a noop for all architectures, so this doesn't actually result in any
      compiled code changes to mm/memory.o.
      
      BTW:
      I haven't put vm_normal_page() into arch code as-per an earlier suggestion.
      The reason is that, regardless of where vm_normal_page is actually
      implemented, the *abstraction* is still exactly the same. Also, while it
      depends on whether the architecture has pte_special or not, that is the
      only two possible cases, and it really isn't an arch specific function --
      the role of the arch code should be to provide primitive functions and
      accessors with which to build the core code; pte_special does that. We do
      not want architectures to know or care about vm_normal_page itself, and
      we definitely don't want them being able to invent something new there
      out of sight of mm/ code. If we made vm_normal_page an arch function, then
      we have to make vm_insert_mixed (next patch) an arch function too. So I
      don't think moving it to arch code fundamentally improves any abstractions,
      while it does practically make the code more difficult to follow, for both
      mm and arch developers, and easier to misuse.
      
      [akpm@linux-foundation.org: build fix]
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Acked-by: NCarsten Otte <cotte@de.ibm.com>
      Cc: Jared Hulbert <jaredeh@gmail.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7e675137
  10. 27 4月, 2008 1 次提交
    • D
      sparc: Remove old style signal frame support. · 5526b7e4
      David S. Miller 提交于
      Back around the same time we were bootstrapping the first 32-bit sparc
      Linux kernel with a SunOS userland, we made the signal frame match
      that of SunOS.
      
      By the time we even started putting together a native Linux userland
      for 32-bit Sparc we realized this layout wasn't sufficient for Linux's
      needs.
      
      Therefore we changed the layout, yet kept support for the old style
      signal frame layout in there.  The detection mechanism is that we had
      sys_sigaction() start passing in a negative signal number to indicate
      "new style signal frames please".
      
      Anyways, no binaries exist in the world that use the old stuff.  In
      fact, I bet Jakub Jelinek and myself are the only two people who ever
      had such binaries to be honest.
      
      So let's get rid of this stuff.
      
      I added an assertion using WARN_ON_ONCE() that makes sure 32-bit
      applications are passing in that negative signal number still.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5526b7e4
  11. 24 4月, 2008 1 次提交
  12. 22 4月, 2008 1 次提交
  13. 21 4月, 2008 1 次提交
  14. 18 4月, 2008 1 次提交
  15. 17 4月, 2008 1 次提交
  16. 03 4月, 2008 1 次提交
    • C
      kvm: provide kvm.h for all architecture: fixes headers_install · dd135ebb
      Christian Borntraeger 提交于
      Currently include/linux/kvm.h is not considered by make headers_install,
      because Kbuild cannot handle " unifdef-$(CONFIG_FOO) += foo.h.  This problem
      was introduced by
      
      commit fb56dbb3
      Author: Avi Kivity <avi@qumranet.com>
      Date:   Sun Dec 2 10:50:06 2007 +0200
      
          KVM: Export include/linux/kvm.h only if $ARCH actually supports KVM
      
          Currently, make headers_check barfs due to <asm/kvm.h>, which <linux/kvm.h>
          includes, not existing.  Rather than add a zillion <asm/kvm.h>s, export kvm.
          only if the arch actually supports it.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      
      which makes this an 2.6.25 regression.
      
      One way of solving the issue is to enhance Kbuild, but Avi and David conviced
      me, that changing headers_install is not the way to go.  This patch changes
      the definition for linux/kvm.h to unifdef-y.
      
      If  unifdef-y is used for linux/kvm.h "make headers_check" will fail on all
      architectures without asm/kvm.h.  Therefore, this patch also provides
      asm/kvm.h on all architectures.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Acked-by: NAvi Kivity <avi@qumranet.com>
      Cc: Sam Ravnborg <sam@ravnborg.org
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dd135ebb
  17. 29 2月, 2008 1 次提交
  18. 10 2月, 2008 1 次提交
  19. 09 2月, 2008 17 次提交