Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 18 Jan 2023 21:40:32 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Gregory Price <gregory.price@memverge.com>
Cc:     linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
        krisman@collabora.com, tglx@linutronix.de, luto@kernel.org,
        oleg@redhat.com, ebiederm@xmission.com, akpm@linux-foundation.org,
        adobriyan@gmail.com, corbet@lwn.net, shuah@kernel.org
Subject: Re: [PATCH 1/3] ptrace,syscall_user_dispatch: Implement Syscall User
 Dispatch Suspension
Message-ID: <Y8hZQI6UfDHhH3tj@hirez.programming.kicks-ass.net>
References: <20230109153348.5625-1-gregory.price@memverge.com>
 <20230109153348.5625-2-gregory.price@memverge.com>
 <Y8gpZ+T/re7mEDjB@hirez.programming.kicks-ass.net>
 <CAD3UvdSpOMAOUm1CYJ5vOyEsiVZCQdiWaTmXjq1vWVFq1DhQ0w@mail.gmail.com>
 <Y8hNS4aCkkOLv1M/@memverge.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y8hNS4aCkkOLv1M/@memverge.com>
Precedence: bulk

On Wed, Jan 18, 2023 at 02:49:31PM -0500, Gregory Price wrote:
> On Wed, Jan 18, 2023 at 02:41:00PM -0500, Gregory Price wrote:
> > ---------- Forwarded message ---------
> > From: Peter Zijlstra <peterz@infradead.org>
> > Date: Wed, Jan 18, 2023 at 12:16 PM
> > Subject: Re: [PATCH 1/3] ptrace,syscall_user_dispatch: Implement Syscall
> > User Dispatch Suspension
> > To: Gregory Price <gourry.memverge@gmail.com>
> > 
> > 
> > On Mon, Jan 09, 2023 at 10:33:46AM -0500, Gregory Price wrote:
> > > @@ -36,6 +37,10 @@ bool syscall_user_dispatch(struct pt_regs *regs)
> > >       struct syscall_user_dispatch *sd = &current->syscall_dispatch;
> > >       char state;
> > >
> > > +     if (IS_ENABLED(CONFIG_CHECKPOINT_RESTORE) &&
> > > +                     unlikely(current->ptrace &
> > PT_SUSPEND_SYSCALL_USER_DISPATCH))
> > > +             return false;
> > > +
> > >       if (likely(instruction_pointer(regs) - sd->offset < sd->len))
> > >               return false;
> > >
> > 
> > So by making syscall_user_dispatch() return false, we'll make
> > syscall_trace_enter() continue to handle things, and supposedly you want
> > to land in ptrace_report_syscall_entry(), right?
> >
> > ... snip ...
> > 
> > Should setting this then not also depend on having
> > SYSCALL_WORK_SYSCALL_TRACE set? Because without that, you get 'funny'
> > things.
> 
> Hm, this is an interesting question.  My thoughts are that I want the
> process to handle the syscall as-if syscall user dispatch was not
> present at all, regardless of SYSCALL_TRACE.
> 
> This is because some software, like CRIU, actually injects syscalls to
> run in the context of the software in an effort to collect resources.

Oh, right. I used to know that.

> So I actually *want* those 'funny' things to occur, because they're most
> likely intentional.  I don't necessarily want to intercept system calls
> that subsequently occur (although i might).
> 
> So if this feature required SYSCALL_TRACE, you would no longer be able
> to inject system calls ala CRIU.

Yeah, I suppose you're right. It makes it a very sharp instrument, but I
suppose you get what you asked for.