mirror of https://lore.kernel.org/lkml/
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome