• Christoph Hellwig's avatar
    ptrace: move user_enable_single_step & co prototypes to linux/ptrace.h · dacbe41f
    Christoph Hellwig authored
    While in theory user_enable_single_step/user_disable_single_step/
    user_enable_blockstep could also be provided as an inline or macro there's
    no good reason to do so, and having the prototype in one places keeps code
    size and confusion down.
    
    Roland said:
    
      The original thought there was that user_enable_single_step() et al
      might well be only an instruction or three on a sane machine (as if we
      have any of those!), and since there is only one call site inlining
      would be beneficial.  But I agree that there is no strong reason to care
      about inlining it.
    
      As to the arch changes, there is only one thought I'd add to the
      record.  It was always my thinking that for an arch where
      PTRACE_SINGLESTEP does text-modifying breakpoint insertion,
      user_enable_single_step() should not be provided.  That is,
      arch_has_single_step()=>true means that there is an arch facility with
      "pure" semantics that does not have any unexpected side effects.
      Inserting a breakpoint might do very unexpected strange things in
      multi-threaded situations.  Aside from that, it is a peculiar side
      effect that user_{enable,disable}_single_step() should cause COW
      de-sharing of text pages and so forth.  For PTRACE_SINGLESTEP, all these
      peculiarities are the status quo ante for that arch, so having
      arch_ptrace() itself do those is one thing.  But for building other
      things in the future, it is nicer to have a uniform "pure" semantics
      that arch-independent code can expect.
    
      OTOH, all such arch issues are really up to the arch maintainer.  As
      of today, there is nothing but ptrace using user_enable_single_step() et
      al so it's a distinction without a practical difference.  If/when there
      are other facilities that use user_enable_single_step() and might care,
      the affected arch's can revisit the question when someone cares about
      the quality of the arch support for said new facility.
    Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Roland McGrath <roland@redhat.com>
    Acked-by: default avatarDavid Howells <dhowells@redhat.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    dacbe41f
ptrace.h 2.67 KB