All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Pedro Alves <palves@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	oleg@redhat.com
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, suresh.b.siddha@intel.com
Subject: Re: [PATCH v2] ptrace: Clarify PTRACE_GETREGSET/PTRACE_SETREGSET, documentation in uapi header
Date: Thu, 12 Jun 2014 14:21:44 +0530	[thread overview]
Message-ID: <53996A20.3030300@linux.vnet.ibm.com> (raw)
In-Reply-To: <53734B7D.4010504@redhat.com>

On 05/14/2014 04:24 PM, Pedro Alves wrote:
> On 05/14/14 08:10, Anshuman Khandual wrote:
>> On 05/13/2014 11:39 PM, Pedro Alves wrote:
>>> On 05/05/14 05:10, Anshuman Khandual wrote:
>>>> On 05/01/2014 07:43 PM, Pedro Alves wrote:
>>> OK, then this is what I suggest instead:
> ...
>>>> Shall I resend the patch with the your proposed changes and your "Signed-off-by" and
>>>> moving myself as "Reported-by" ?
>>>
>>> No idea of the actual policy to follow.  Feel free to do that if that's the
>>> standard procedure.
>>
>> Even I am not sure about this, so to preserve the correct authorship, would you
>> mind sending this patch ?
> 
> Here you go.  This is against current Linus'.  Please take it from
> here if necessary.
> 
> 8<------------------------------------------
> From 1237f5ac5896f3910f66df83a5093bb548006188 Mon Sep 17 00:00:00 2001
> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 14 May 2014 11:05:07 +0100
> Subject: [PATCH] ptrace: Clarify PTRACE_GETREGSET/PTRACE_SETREGSET
>  documentation in uapi header
> 
> The current comments don't explicitly state in plain words that
> iov.len must be set to the buffer's length prior to the ptrace call.
> A user might get confused and leave that uninitialized.
> 
> In the ptrace_regset function (snippet below) we see that the buffer
> length has to be a multiple of the slot/register size for the given
> NT_XXX_TYPE:
> 
>         if (!regset || (kiov->iov_len % regset->size) != 0)
>                 return -EINVAL;
> 
> Note regset->size is the size of each slot/register in the set, not
> the size of the whole set.
> 
> And then, we see here:
> 
>  kiov->iov_len = min(kiov->iov_len,
>                             (__kernel_size_t) (regset->n * regset->size));
> 
> that the kernel takes care of capping the requested length to the size
> of the whole regset.
> 
> Signed-off-by: Pedro Alves <palves@redhat.com>
> Reported-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> ---
>  include/uapi/linux/ptrace.h | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
> index cf1019e..30836b9 100644
> --- a/include/uapi/linux/ptrace.h
> +++ b/include/uapi/linux/ptrace.h
> @@ -39,12 +39,17 @@
>   * payload are exactly the same layout.
>   *
>   * This interface usage is as follows:
> - *	struct iovec iov = { buf, len};
> + *	struct iovec iov = { buf, len };
>   *
>   *	ret = ptrace(PTRACE_GETREGSET/PTRACE_SETREGSET, pid, NT_XXX_TYPE, &iov);
>   *
> - * On the successful completion, iov.len will be updated by the kernel,
> - * specifying how much the kernel has written/read to/from the user's iov.buf.
> + * On entry, iov describes the buffer's address and length.  The buffer's length
> + * must be a multiple of the size of a single register in the register set.  The
> + * kernel never reads or writes more than iov.len, and caps the buffer length to
> + * the register set's size.  In other words, the kernel reads or writes
> + * min(iov.len, regset size).  On successful completion, iov.len is updated by
> + * the kernel, specifying how much the kernel has read from / written to the
> + * user's iov.buf.
>   */
>  #define PTRACE_GETREGSET	0x4204
>  #define PTRACE_SETREGSET	0x4205

Hey Peter/Oleg,

The above patch is a documentation fix which we discussed sometime back. Could you please
kindly review and consider merging. Thank you.


  parent reply	other threads:[~2014-06-12  8:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-28 11:00 [PATCH] ptrace: Fix PTRACE_GETREGSET/PTRACE_SETREGSET in code documentation Anshuman Khandual
2014-05-01 14:13 ` Pedro Alves
2014-05-05  4:10   ` Anshuman Khandual
2014-05-13 18:09     ` Pedro Alves
2014-05-14  7:10       ` Anshuman Khandual
2014-05-14 10:54         ` [PATCH v2] ptrace: Clarify PTRACE_GETREGSET/PTRACE_SETREGSET, documentation in uapi header Pedro Alves
2014-05-20  8:23           ` Anshuman Khandual
2014-06-12  8:51           ` Anshuman Khandual [this message]
2014-06-12 18:05             ` Oleg Nesterov
2014-06-12 18:49               ` Michael Kerrisk (man-pages)

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=53996A20.3030300@linux.vnet.ibm.com \
    --to=khandual@linux.vnet.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=palves@redhat.com \
    --cc=peterz@infradead.org \
    --cc=suresh.b.siddha@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.