All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Pedro Alves <palves@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	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 20:05:01 +0200	[thread overview]
Message-ID: <20140612180501.GB15795@redhat.com> (raw)
In-Reply-To: <53996A20.3030300@linux.vnet.ibm.com>

On 06/12, Anshuman Khandual wrote:
>
> > --- 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).

I think this should be self-obvious ;) otherwise why do we need to pass
the length of the buffer?

But of course I won't argue with the additional documentation, perhaps you
can re-send this patch to akpm? Usually ptrace changes are routed via -mm
tree.

But if we update the kernel header, then probably it would be more important
to update the man-page. To me the description of GETREGSET looks good, but
probably it could also mention that buflen should be multiple of regsize (as
you did above). Add Michael.

Oleg.


  reply	other threads:[~2014-06-12 18:06 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
2014-06-12 18:05             ` Oleg Nesterov [this message]
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=20140612180501.GB15795@redhat.com \
    --to=oleg@redhat.com \
    --cc=hpa@zytor.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.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.