All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	syzbot+693dc11fcb53120b5559@syzkaller.appspotmail.com
Subject: Re: [PATCH 1/2] mm/mempolicy: Allow lookup_node() to handle fatal signal
Date: Thu, 9 Apr 2020 08:52:58 -0400	[thread overview]
Message-ID: <20200409125258.GA362416@xz-x1> (raw)
In-Reply-To: <20200409070253.GB18386@dhcp22.suse.cz>

On Thu, Apr 09, 2020 at 09:02:53AM +0200, Michal Hocko wrote:
> This patch has been merged and it is actually wrong after ae46d2aa6a7f
> has been merged. We can either revert or I suggest just handling >0,
> like the patch below:
> 
> From 03fbe30ec61e65b0927d0d41bccc7dff5f7eafd8 Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@suse.com>
> Date: Thu, 9 Apr 2020 08:26:57 +0200
> Subject: [PATCH] mm, mempolicy: fix up gup usage in lookup_node
> 
> ba841078cd05 ("mm/mempolicy: Allow lookup_node() to handle fatal signal") has
> added a special casing for 0 return value because that was a possible
> gup return value when interrupted by fatal signal. This has been fixed
> by ae46d2aa6a7f ("mm/gup: Let __get_user_pages_locked() return -EINTR
> for fatal signal") in the mean time so ba841078cd05 can be reverted.
> This patch however doesn't go all the way to revert it because 0 return
> value is impossible. We always get an error or 1 for a single page
> request.
> 
> Fixes: ba841078cd05 ("mm/mempolicy: Allow lookup_node() to handle fatal signal")
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
>  mm/mempolicy.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 48ba9729062e..1965e2681877 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -927,10 +927,7 @@ static int lookup_node(struct mm_struct *mm, unsigned long addr)
>  
>  	int locked = 1;
>  	err = get_user_pages_locked(addr & PAGE_MASK, 1, 0, &p, &locked);
> -	if (err == 0) {
> -		/* E.g. GUP interrupted by fatal signal */
> -		err = -EFAULT;
> -	} else if (err > 0) {
> +	if (err > 0) {
>  		err = page_to_nid(p);
>  		put_page(p);
>  	}

Hi, Michal,

I'm totally not against this, but note that get_user_pages_locked()
could still return zero. Although I'm not 100% sure now on whether
npages==0 will be the only case, it won't hurt to keep this ret==0
check until we consolidate the whole gup code to never return zero.

Assuming there's another case (even possible for a future gup bug)
that could return a zero, your patch will let err be anything (which
you didn't initialize err with your patch), then the function will
return a random value.  So even if you really want this change, I
would suggest you initialize err to some error code.

I just don't see much gain we get from removing that check.

Thanks,

-- 
Peter Xu


  reply	other threads:[~2020-04-09 12:53 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-08  1:40 [PATCH 0/2] mm: Two small fixes for recent syzbot reports Peter Xu
2020-04-08  1:40 ` [PATCH 1/2] mm/mempolicy: Allow lookup_node() to handle fatal signal Peter Xu
2020-04-08 10:21   ` Michal Hocko
2020-04-08 14:20     ` Peter Xu
2020-04-08 14:30       ` Michal Hocko
2020-04-08 15:24         ` Peter Xu
2020-04-08 15:26           ` Michal Hocko
2020-04-09  7:02   ` Michal Hocko
2020-04-09 12:52     ` Peter Xu [this message]
2020-04-09 13:00       ` Peter Xu
2020-04-09 13:53       ` Michal Hocko
2020-04-09 16:42     ` Linus Torvalds
2020-04-09 16:42       ` Linus Torvalds
2020-04-14 11:04       ` Michal Hocko
2020-04-14 13:49         ` Peter Xu
2020-04-14 14:18           ` Michal Hocko
2020-04-20 12:47         ` Michal Hocko
2020-04-20 17:31           ` Linus Torvalds
2020-04-20 17:31             ` Linus Torvalds
2020-04-21  7:09             ` Michal Hocko
2020-04-08  1:40 ` [PATCH 2/2] mm/gup: Mark lock taken only after a successful retake Peter Xu
2020-04-09  0:47 ` [PATCH 0/2] mm: Two small fixes for recent syzbot reports Andrew Morton
2020-04-09 11:49   ` Matthew Wilcox
2020-04-09 13:00     ` Dmitry Vyukov
2020-04-09 13:00       ` Dmitry Vyukov
2020-04-09 18:16       ` Andrew Morton
2020-04-09 18:53         ` Linus Torvalds
2020-04-09 18:53           ` Linus Torvalds
2020-04-09 19:12           ` Andrew Morton
2020-04-09 19:46             ` Linus Torvalds
2020-04-09 19:46               ` Linus Torvalds
2020-04-09 19:56               ` Matthew Wilcox
2020-04-09 19:58                 ` Linus Torvalds
2020-04-09 19:58                   ` Linus Torvalds
2020-04-09 20:27                   ` Eric Biggers
2020-04-09 20:34                     ` Linus Torvalds
2020-04-09 20:34                       ` Linus Torvalds
2020-04-09 23:34                       ` Stephen Rothwell
2020-04-10  1:11                       ` Theodore Y. Ts'o
2020-04-09 12:55   ` Dmitry Vyukov
2020-04-09 12:55     ` Dmitry Vyukov
2020-04-09 16:32     ` Linus Torvalds
2020-04-09 16:32       ` Linus Torvalds
2020-04-09 16:58       ` Qian Cai
2020-04-09 17:05         ` Linus Torvalds
2020-04-09 17:05           ` Linus Torvalds
2020-04-09 17:58           ` Qian Cai
2020-04-09 18:06             ` Linus Torvalds
2020-04-09 18:06               ` Linus Torvalds
2020-04-09 21:14               ` Qian Cai
2020-04-10 13:12                 ` Tetsuo Handa
2020-04-10 14:26                   ` Qian Cai
2020-04-10 17:26                     ` Andrew Morton
2020-04-10 19:46                       ` Qian Cai
2020-04-09 23:29       ` Stephen Rothwell
2020-04-13 22:06         ` Qian Cai
2020-04-13 23:05           ` Jens Axboe
2020-04-14 11:12           ` Dmitry Vyukov
2020-04-14 11:12             ` Dmitry Vyukov
2020-04-14 11:59             ` Qian Cai
2020-04-14 12:05               ` Dmitry Vyukov
2020-04-14 12:05                 ` Dmitry Vyukov
2020-04-14 19:28             ` Dan Rue
2020-04-15 11:09               ` Dmitry Vyukov
2020-04-15 11:09                 ` Dmitry Vyukov
2020-04-15 16:23                 ` Dan Rue
2020-04-16  0:34             ` Stephen Rothwell
2020-05-11 15:29               ` Dmitry Vyukov
2020-05-11 15:29                 ` Dmitry Vyukov
2020-04-14  4:07         ` Hillf Danton
2020-04-14  4:31           ` Jens Axboe

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=20200409125258.GA362416@xz-x1 \
    --to=peterx@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=syzbot+693dc11fcb53120b5559@syzkaller.appspotmail.com \
    --cc=torvalds@linux-foundation.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.