public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: "Dmitry V. Levin" <ldv@altlinux.org>
Cc: Piotr Figiel <figiel@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	paulmck <paulmck@kernel.org>, Boqun Feng <boqun.feng@gmail.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Andrei Vagin <avagin@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Peter Oskolkov <posk@google.com>,
	Kamil Yurtsever <kyurtsever@google.com>,
	Chris Kennelly <ckennelly@google.com>,
	Paul Turner <pjt@google.com>,
	emmir@google.com, linux-man <linux-man@vger.kernel.org>,
	linux-api <linux-api@vger.kernel.org>
Subject: Re: [PATCH] ptrace: add PTRACE_GET_RSEQ_CONFIGURATION request
Date: Mon, 22 Feb 2021 09:53:10 -0500 (EST)	[thread overview]
Message-ID: <1510231959.29418.1614005590596.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20210222115726.GA30843@altlinux.org>

----- On Feb 22, 2021, at 6:57 AM, Dmitry V. Levin ldv@altlinux.org wrote:

> On Mon, Feb 22, 2021 at 11:04:43AM +0100, Piotr Figiel wrote:
> [...]
>> --- a/include/uapi/linux/ptrace.h
>> +++ b/include/uapi/linux/ptrace.h
>> @@ -102,6 +102,14 @@ struct ptrace_syscall_info {
>>  	};
>>  };
>>  
>> +#define PTRACE_GET_RSEQ_CONFIGURATION	0x420f
>> +
>> +struct ptrace_rseq_configuration {
>> +	__u64 rseq_abi_pointer;
>> +	__u32 signature;
>> +	__u32 pad;
>> +};
>> +
>>  /*
>>   * These values are stored in task->ptrace_message
>>   * by tracehook_report_syscall_* to describe the current syscall-stop.
>> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
>> index 61db50f7ca86..a936af66cf6f 100644
>> --- a/kernel/ptrace.c
>> +++ b/kernel/ptrace.c
>> @@ -31,6 +31,7 @@
>>  #include <linux/cn_proc.h>
>>  #include <linux/compat.h>
>>  #include <linux/sched/signal.h>
>> +#include <linux/minmax.h>
>>  
>>  #include <asm/syscall.h>	/* for syscall_get_* */
>>  
>> @@ -779,6 +780,22 @@ static int ptrace_peek_siginfo(struct task_struct *child,
>>  	return ret;
>>  }
>>  
>> +#ifdef CONFIG_RSEQ
>> +static long ptrace_get_rseq_configuration(struct task_struct *task,
>> +					  unsigned long size, void __user *data)
>> +{
>> +	struct ptrace_rseq_configuration conf = {
>> +		.rseq_abi_pointer = (u64)(uintptr_t)task->rseq,
>> +		.signature = task->rseq_sig,
>> +	};
>> +
>> +	size = min_t(unsigned long, size, sizeof(conf));
>> +	if (copy_to_user(data, &conf, size))
>> +		return -EFAULT;
>> +	return size;
>> +}
>> +#endif
> 
> From API perspective I suggest for such interfaces to return the amount of
> data that could have been written if there was enough room specified, e.g.
> in this case it's sizeof(conf) instead of size.

Looking at the ptrace(2) man page:

RETURN VALUE
       On success, the PTRACE_PEEK* requests return the  requested  data  (but
       see NOTES), the PTRACE_SECCOMP_GET_FILTER request returns the number of
       instructions in the BPF program, and other requests return zero.

       On error, all requests return  -1,  and  errno  is  set  appropriately.
       Since  the  value  returned by a successful PTRACE_PEEK* request may be
       -1, the caller must clear errno before the call, and then check it  af‐
       terward to determine whether or not an error occurred.

It looks like the usual behavior for ptrace requests would be to return 0 when everything
is OK. Unless there a strong motivation for doing different for this new request, I
would be tempted to use the same expected behavior than other requests on success:
return 0.

Unless there is a strong motivation for returning either size or sizeof(conf) ? If we
return sizeof(conf) to user-space, it means it should check it and deal with the
size mismatch. Is that size ever expected to change ?

Thanks,

Mathieu

> 
> 
> --
> ldv

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2021-02-22 14:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 10:04 [PATCH] ptrace: add PTRACE_GET_RSEQ_CONFIGURATION request Piotr Figiel
2021-02-22 11:57 ` Dmitry V. Levin
2021-02-22 14:53   ` Mathieu Desnoyers [this message]
2021-02-22 16:25     ` Dmitry V. Levin
2021-02-22 14:53 ` Mathieu Desnoyers
2021-02-26 14:11   ` Piotr Figiel
2021-03-03 18:55     ` Mathieu Desnoyers
2021-02-23 16:15 ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1510231959.29418.1614005590596.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@gmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=ckennelly@google.com \
    --cc=emmir@google.com \
    --cc=figiel@google.com \
    --cc=kyurtsever@google.com \
    --cc=ldv@altlinux.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=posk@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox