All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Alban Crequy <alban.crequy@gmail.com>
Cc: linux-man@vger.kernel.org, David Hildenbrand <david@kernel.org>,
	 Alban Crequy <albancrequy@microsoft.com>
Subject: Re: [PATCH] process_vm_readv.2: correct partial transfer granularity
Date: Thu, 14 May 2026 13:49:26 +0200	[thread overview]
Message-ID: <agW2O9NRtH1dxew8@devuan> (raw)
In-Reply-To: <20260514083659.139971-1-alban.crequy@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3270 bytes --]

Hi Alban,

On 2026-05-14T10:36:59+0200, Alban Crequy wrote:
> From: Alban Crequy <albancrequy@microsoft.com>
> 
> The man page claimed that partial transfers apply at the granularity
> of iovec elements and that these system calls won't split a single
> iovec element. This is correct for local iovecs (which are validated
> upfront) but incorrect for remote iovecs: the kernel processes remote
> memory at page granularity via pin_user_pages_remote(), so a partial
> transfer can occur within a single remote iovec element at a page
> boundary.
> 
> For example, if a remote iovec spans two pages and the second page is
> unmapped, the syscall returns the number of bytes from the first page
> (a partial transfer within one iovec element), not -1/EFAULT.
> 
> I verified this by testing process_vm_readv() and process_vm_writev()
> with a 2-page remote iovec where the second page was unmapped via
> munmap(). Both returned one page worth of bytes (a short read/write),
> confirming page-granularity partial transfers.
> 
> I was prompted to check the current behaviour by the LKML review on
> my patch (not merged yet) on process_vm_readv adding new flags:
> https://lore.kernel.org/lkml/8b29da5b-e260-4b77-a640-8abb447291d1@kernel.org/
> 
> The inaccurate text was introduced in commit 0b01869b0a59
> ("process_vm_readv.2: Cleanups after comments from Mike Frysinger
> and Christopher Yeoh", 2012-04-14), based on a misinterpretation of
> a review comment. The original man page text by Christopher Yeoh
> correctly described partial transfers without claiming iovec-element
> granularity.
> 
> Note: process_vm_writev.2 is a .so redirect to process_vm_readv.2,
> so this fix applies to both pages.
> 
> Fixes: 0b01869b0a59 ("process_vm_readv.2: Cleanups after comments from Mike Frysinger and Christopher Yeoh")
> Signed-off-by: Alban Crequy <albancrequy@microsoft.com>

Excellent commit message; thanks!  I've applied the patch, with some
minor tweaks in the commit message, and also addition of a comma and
a couple of line breaks in the source code.


Have a lovely day!
Alex

> ---
>  man/man2/process_vm_readv.2 | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/man/man2/process_vm_readv.2 b/man/man2/process_vm_readv.2
> index 66554a2cf..2ccfe60d0 100644
> --- a/man/man2/process_vm_readv.2
> +++ b/man/man2/process_vm_readv.2
> @@ -192,10 +192,13 @@ returns the number of bytes read and
>  returns the number of bytes written.
>  This return value may be less than the total number of requested bytes,
>  if a partial read/write occurred.
> -(Partial transfers apply at the granularity of
> +(Partial transfers apply at the granularity of pages in the remote process.
> +If a remote
>  .I iovec
> -elements.
> -These system calls won't perform a partial transfer that splits a single
> +element spans multiple pages and one of those pages is invalid
> +or not resident,
> +data may be transferred from/to the pages preceding the failing page,
> +resulting in a partial transfer that splits a single
>  .I iovec
>  element.)
>  The caller should check the return value to determine whether
> -- 
> 2.45.0
> 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2026-05-14 11:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14  8:36 [PATCH] process_vm_readv.2: correct partial transfer granularity Alban Crequy
2026-05-14 11:49 ` Alejandro Colomar [this message]

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=agW2O9NRtH1dxew8@devuan \
    --to=alx@kernel.org \
    --cc=alban.crequy@gmail.com \
    --cc=albancrequy@microsoft.com \
    --cc=david@kernel.org \
    --cc=linux-man@vger.kernel.org \
    /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.