On Tue, Jan 24, 2023 at 8:54 AM Gregory Price
[off-list ref] wrote:

On Tue, Jan 24, 2023 at 05:43:47PM +0100, Oleg Nesterov wrote:

quoted

I won't really argue, but...

On 01/24, Gregory Price wrote:

quoted

On Mon, Jan 23, 2023 at 08:52:29PM +0100, Oleg Nesterov wrote:

quoted

On 01/23, Gregory Price wrote:

quoted

So i think dropping 2/3 in the list is good.  If you concur i'll do
that.

Well I obviously think that 2/3 should be dropped ;)

As for 1/3 and 3/3, feel free to add my reviewed-by.

Oleg.

I'm actually going to walk my agreement back.

After one more review, the need for the proc/status entry is not to
decide whether to dump SUD settings, but for use in deciding whether to
set the SUSPEND_SYSCALL_DISPATCH option from patch 1/3.

Rather than read /proc/pid/status, CRIU can just do
PTRACE_GET_SYSCALL_USER_DISPATCH_CONFIG unconditionally
and check syscall_user_dispatch_config.mode ?

Why do want to expose SYSCALL_USER_DISPATCH in /proc/status? If this task
is not stopped you can't trust this value anyway. If it is stopped, I don't
think ptrace(PTRACE_GET_SYSCALL_USER_DISPATCH_CONFIG) is slower than reading
/proc.

but perhaps I missed something?

Oleg.

*facepalm* good point, i'm wondering if there's a reason CRIU doesn't do
the same for SECCOMP.

Because information about seccomp was in /proc/pid/status forever and we
started using it before the ptrace interface was merged. I am not sure that
this is the only reason, but  it is definitely one of them.

either way, going to drop it