linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Charan Teja Kalla <quic_charante@quicinc.com>
Cc: akpm@linux-foundation.org, minchan@kernel.org, surenb@google.com,
	vbabka@suse.cz, rientjes@google.com, nadav.amit@gmail.com,
	edgararriaga@google.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] Revert "mm: madvise: skip unmapped vma holes passed to process_madvise"
Date: Thu, 24 Mar 2022 13:48:05 +0100	[thread overview]
Message-ID: <Yjxoha4PLlKjEayl@dhcp22.suse.cz> (raw)
In-Reply-To: <e73da1304a88b6a8a11907045117cccf4c2b8374.1648046642.git.quic_charante@quicinc.com>

On Wed 23-03-22 20:54:09, Charan Teja Kalla wrote:
> This reverts commit 08095d6310a7 ("mm: madvise: skip unmapped vma holes
> passed to process_madvise") as process_madvise() fails to return exact
> processed bytes at other cases too. As an example: if the
> process_madvise() hits mlocked pages after processing some initial bytes
> passed in [start, end), it just returns EINVAL though some bytes are
> processed. Thus making an exception only for ENOMEM is partially fixing
> the problem of returning the proper advised bytes.
> 
> Thus revert this patch and return proper bytes advised, if there any,
> for all the error types in the following patch.

I do agree with the revert. I am not sure the above really is a proper
justification though. 08095d6310a7 was changing one (arguably) dubious
semantic by another one without a proper justification and wider
consensus which I would expect from a patch which changes an existing
semantic. Not to mention it being marked for stable tree.

But let's not nit pick on that now. Let's send this revert ASAP and use
some more time to discuss the semantic and whether any change is really
required.

> Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>

Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  mm/madvise.c | 9 +--------
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 39b712f..0d8fd17 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -1433,16 +1433,9 @@ SYSCALL_DEFINE5(process_madvise, int, pidfd, const struct iovec __user *, vec,
>  
>  	while (iov_iter_count(&iter)) {
>  		iovec = iov_iter_iovec(&iter);
> -		/*
> -		 * do_madvise returns ENOMEM if unmapped holes are present
> -		 * in the passed VMA. process_madvise() is expected to skip
> -		 * unmapped holes passed to it in the 'struct iovec' list
> -		 * and not fail because of them. Thus treat -ENOMEM return
> -		 * from do_madvise as valid and continue processing.
> -		 */
>  		ret = do_madvise(mm, (unsigned long)iovec.iov_base,
>  					iovec.iov_len, behavior);
> -		if (ret < 0 && ret != -ENOMEM)
> +		if (ret < 0)
>  			break;
>  		iov_iter_advance(&iter, iovec.iov_len);
>  	}
> -- 
> 2.7.4

-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2022-03-24 12:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-23 15:24 [PATCH 0/2] mm: madvise: return exact bytes advised with process_madvise under error Charan Teja Kalla
2022-03-23 15:24 ` [PATCH 1/2] Revert "mm: madvise: skip unmapped vma holes passed to process_madvise" Charan Teja Kalla
2022-03-24 12:48   ` Michal Hocko [this message]
2022-03-24 14:03     ` Charan Teja Kalla
2022-03-23 15:24 ` [PATCH 2/2] mm: madvise: return exact bytes advised with process_madvise under error Charan Teja Kalla
2022-03-24 13:14   ` Michal Hocko
2022-03-24 15:45     ` Charan Teja Kalla
2022-03-25  0:46       ` Minchan Kim
2022-03-25  0:48       ` Minchan Kim
2022-03-25  8:02       ` Michal Hocko

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=Yjxoha4PLlKjEayl@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=edgararriaga@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=nadav.amit@gmail.com \
    --cc=quic_charante@quicinc.com \
    --cc=rientjes@google.com \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    /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