1. 25 Dec, 2008 2 commits
    • Al Viro's avatar
      [S390] audit: get s390 ret_from_fork in sync with other architectures · 8f2961c3
      Al Viro authored
      	On s390 we have ret_from_fork jump not to the "do all work we
      normally do on return from syscall" as on x86, ppc, etc., but to the
      "do all such work except audit".  Historical reasons - the codepath
      triggered when we have AUDIT process flag set is separated from the
      normall one and they converge at sysc_return, which is the common
      part of post-syscall work.  And does not include calling audit_syscall_exit() -
      that's done in the end of sysc_tracesys path, just before that path jumps
      to sysc_return.
      
      	IOW, the child returning from fork()/clone()/vfork() doesn't
      call audit_syscall_exit() at all, so no matter what we do with its
      audit context, we are not going to see the audit entry.
      
      	The fix is simple: have ret_from_fork go to the point just past
      the call of sys_.... in the 'we have AUDIT flag set' path.  There we
      have (64bit variant; for 31bit the situation is the same):
      sysc_tracenogo:
              tm      __TI_flags+7(%r9),(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT)
              jz      sysc_return
              la      %r2,SP_PTREGS(%r15)     # load pt_regs
              larl    %r14,sysc_return        # return point is sysc_return
              jg      do_syscall_trace_exit
      which is precisely what we need - check the flag, bugger off to sysc_return
      if not set, otherwise call do_syscall_trace_exit() and bugger off to
      sysc_return.  r9 has just been properly set by ret_from_fork itself,
      so we are fine.
      
      	Tested on s390x, seems to work fine.  WARNING: it's been about
      16 years since my last contact with 3X0 assembler[1], so additional
      review would be very welcome.  I don't think I've managed to screw it
      up, but...
      
      [1] that *was* in another country and besides, the box is dead...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      8f2961c3
    • Heiko Carstens's avatar
      [S390] cpu topology: fix cpu_core_map initialization · 5439050f
      Heiko Carstens authored
      Common code doesn't call arch_update_cpu_topology() anymore on
      cpu hotplug. But our architecture backend relied on that in order to
      update the cpu_core_map. For machines without cpu topology support
      this leads uninitialized cpu_core_maps for later on added cpus.
      
      To solve this just initialize the maps with cpu_possible_map, since
      that will be always valid for machines without topology support.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      5439050f
  2. 24 Dec, 2008 8 commits
  3. 23 Dec, 2008 7 commits
  4. 22 Dec, 2008 7 commits
  5. 20 Dec, 2008 4 commits
  6. 19 Dec, 2008 12 commits