[PATCH] For selinux sake allocate a fake unlinked shmem

Hi Frank, Jim, Mark, This fix is equivalent to commit a82ac1f413712a375d5e14ef7641ce0abf7a6543 in systemtap tree. -- We allocate a fake unlinked shmem file because anonymous memory might not be granted execute permission when the selinux security hooks have their way. Signed-off-by: Srikar

Re: [PATCH 56-58] context-siginfo fixes

This was copy-and-pasted from the old code. Shouldn't we rely use UTRACE_SIGNAL_HOLD instead ? Perhaps so, but I'd rather leave it alone for now. The send_sig_info path has various other checks that could be relevant to the kludgey old ptrace semantics for this arcane case. Fresh

Re: [PATCH 53-55] (Was: Q: what user_enable_single_step() actually means?)

On 09/25, Roland McGrath wrote: it being after the syscall insn, but (in vanilla ptrace, and at the time of report_clone callbacks at utrace level) without the return value register having been written yet. And how we can implement this? regs-ax is updated right after call

Re: [PATCH 53-55] (Was: Q: what user_enable_single_step() actually means?)

On 09/25, Oleg Nesterov wrote: On 09/25, Roland McGrath wrote: it being after the syscall insn, but (in vanilla ptrace, and at the time of report_clone callbacks at utrace level) without the return value register having been written yet. And how we can implement this?

Re: [PATCH 56] ptrace_resume_signal() should use context-siginfo under -siglock

- Change ptrace_resume_signal() to use context-siginfo under -siglock, like ptrace_{get,set}siginfo() do. I don't think the log/comments give a clear picture of why this is the thing to do. To wit, I'm not even sure at the moment it is necessary. It probably is, but I have to convince myself

Re: [PATCH 53-55] (Was: Q: what user_enable_single_step() actually means?)

It's a further oddity that you can single-step (or not) into the system call and then get a ptrace stop inside it, that being for PTRACE_EVENT_FORK et al. And utrace-ptrace should be compatible here, yes? As far as the sequence of stops that a ptracer observes, the general answer is

Re: utrace_control(XXXSTEP)-is_setting_trap_flag() is not safe

And. If we have multiple tracers, then utrace_control(SINGLESTEP) just fools the caller, another engine can do utrace_control(RESUME) at any moment. Sure, but more likely nobody will. I think you are right, utrace_control() should simply consider UTRACE_XXXSTEP as UTRACE_REPORT. All else

Re: [PATCH 56] ptrace_resume_signal() should use context-siginfo under -siglock

On 09/25, Roland McGrath wrote: - Change ptrace_resume_signal() to use context-siginfo under -siglock, like ptrace_{get,set}siginfo() do. I don't think the log/comments give a clear picture of why this is the thing to do. To wit, I'm not even sure at the moment it is necessary. It