All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, suresh.b.siddha@intel.com
Subject: Re: [PATCH] ptrace: Fix PTRACE_GETREGSET/PTRACE_SETREGSET in code documentation
Date: Thu, 01 May 2014 15:13:21 +0100	[thread overview]
Message-ID: <53625681.8010905@redhat.com> (raw)
In-Reply-To: <1398682853-7541-1-git-send-email-khandual@linux.vnet.ibm.com>

On 04/28/2014 12:00 PM, Anshuman Khandual wrote:
> The current documentation is bit misleading and does not explicitly
> specify that iov.len need to be initialized failing which kernel
> may just ignore the ptrace request and never read from/write into
> the user specified buffer. This patch fixes the documentation.

Well, it kind of does, here:

*      struct iovec iov = { buf, len};

> @@ -43,8 +43,12 @@
>   *
>   *	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.
> + * A non-zero value upto the max size of data expected to be written/read by the
> + * kernel in response to any NT_XXX_TYPE request type must be assigned to iov.len
> + * before initiating the ptrace call. If iov.len is 0, then kernel will neither
> + * read from or write into the user buffer specified. On 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.

I really appreciate that you're trying to make this clearer, but I
find the new sentence very hard to read/reason.  :-/

I suggest:

 * 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 equal to or shorter than the size of the NT_XXX_TYPE regset.
+ * On successful completion, iov.len is updated by the kernel, specifying how
+ * much the kernel has written/read to/from the user's iov.buf.

I'm not sure I understood what you're saying correctly, though.  Specifically,
I don't know whether the buffer's length must really be shorter than the
size of the NT_XXX_TYPE regset.

> The current documentation is bit misleading and does not explicitly
> specify that iov.len need to be initialized failing which kernel
> may just ignore the ptrace request and never read from/write into
> the user specified buffer.

You're saying that if iov.len is larger than the NT_XXX_TYPE regset,
then the kernel returns _success_, but actually doesn't fill the
buffer?  That sounds like a bug to me.

-- 
Pedro Alves


  reply	other threads:[~2014-05-01 14:13 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 [this message]
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
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=53625681.8010905@redhat.com \
    --to=palves@redhat.com \
    --cc=hpa@zytor.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.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.