From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2301C54FC9 for ; Tue, 21 Apr 2020 13:29:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5D6A0206F4 for ; Tue, 21 Apr 2020 13:29:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="J6aJSrd7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D6A0206F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BB48F8E0005; Tue, 21 Apr 2020 09:29:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B651E8E0003; Tue, 21 Apr 2020 09:29:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A2CBD8E0005; Tue, 21 Apr 2020 09:29:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by kanga.kvack.org (Postfix) with ESMTP id 8984C8E0003 for ; Tue, 21 Apr 2020 09:29:22 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4D6AB52AC for ; Tue, 21 Apr 2020 13:29:22 +0000 (UTC) X-FDA: 76731943764.05.pie87_6edd4da6b9a35 X-HE-Tag: pie87_6edd4da6b9a35 X-Filterd-Recvd-Size: 6678 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Tue, 21 Apr 2020 13:29:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587475761; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=okftzn3qyOOVe0/R0flnPCpJayj0R+vUXkL98S88Inc=; b=J6aJSrd7TuqFNa9PzU5oem6pg/s5yO/Rsykxjsic55DPjVUY84uSmlOaR++NCqrnfxJMRO xCPs4vorMSg0NEbF2khJWxEUm1uIJKsKHhyRiwOIOSN6BlYcImjamHbi1JZTGFXzaR+RuH OHf2dcwmFLefA/xTIqyqV90t47VXVzo= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-331-lFKV3MnfMc-cUso0uBkHIg-1; Tue, 21 Apr 2020 09:29:19 -0400 X-MC-Unique: lFKV3MnfMc-cUso0uBkHIg-1 Received: by mail-qt1-f199.google.com with SMTP id w6so10212874qtt.21 for ; Tue, 21 Apr 2020 06:29:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=O1Ti1KIvSIMKpnNlcfoK/lyDq223f9fsTlxlc6OUn10=; b=g2RoxZWs+cljvJgjDW5gLNbm/l2iUy0n9XmLHICP6ABRlmF7YGsyiF+bmFa/qxwZoY ZbXDVtP18MB0VPYLpLBrpK3MzagK+6XfjwdSsxfdJo4BoODPjxHn/CKsq6EorXqREdG9 gL9U61xTIJ5g2mbClppkEmbGDBRUVXbagF3atzsAV/VEf9IWfDxXsT6ksEzae64BvLvV G7N8GJdbJy8PDY1RQ+XBluQCBoQm5WKuj/u/EywZNKYje+fo50PdYkQ66uXqGDLZqHxb BoNHB5jCnnssETpVDVnb1AKE3SPxrE6I6LPYULHHkBLoNShKQfPJplneA6m1HYmKaBrz Rt8g== X-Gm-Message-State: AGi0PuZrfzoq9hzXjo42An2lYxN98rHM3fb9mvUyIh/jwfoj3RhBu9iq k0JUtxs3hjKNm8iyvLYxWyEaiL1eP5lrCxgQoJnQkdouOAvBg9oXogPpIR9a7uuWd1ZGUAwLs8d hVwRZfeiz3ks= X-Received: by 2002:ad4:4182:: with SMTP id e2mr20461679qvp.61.1587475759128; Tue, 21 Apr 2020 06:29:19 -0700 (PDT) X-Google-Smtp-Source: APiQypJsiUBEHqJ13cKuqmmb3+dM/Zyr5+I1tbzXHGGGKGAJv4bPlLe0giYLbYXDDNiFHwxQe0usGg== X-Received: by 2002:ad4:4182:: with SMTP id e2mr20461667qvp.61.1587475758859; Tue, 21 Apr 2020 06:29:18 -0700 (PDT) Received: from xz-x1 ([2607:9880:19c0:32::2]) by smtp.gmail.com with ESMTPSA id v188sm1739882qkh.47.2020.04.21.06.29.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Apr 2020 06:29:18 -0700 (PDT) Date: Tue, 21 Apr 2020 09:29:16 -0400 From: Peter Xu To: Michal Hocko Cc: Andrew Morton , Linus Torvalds , linux-mm@kvack.org, LKML , Michal Hocko Subject: Re: [PATCH] mm, mempolicy: fix up gup usage in lookup_node Message-ID: <20200421132916.GE420399@xz-x1> References: <20200421071026.18394-1-mhocko@kernel.org> MIME-Version: 1.0 In-Reply-To: <20200421071026.18394-1-mhocko@kernel.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Apr 21, 2020 at 09:10:26AM +0200, Michal Hocko wrote: > From: Michal Hocko >=20 > 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. >=20 > This patch however doesn't go all the way to revert it because the check > for 0 is wrong and confusing here. Firstly it is inherently unsafe to > access the page when get_user_pages_locked returns 0 (aka no page > returned). > Fortunatelly this will not happen because get_user_pages_locked will not > return 0 when nr_pages > 0 unless FOLL_NOWAIT is specified which is not > the case here. Document this potential error code in gup code while we > are at it. >=20 > Signed-off-by: Michal Hocko > --- > mm/gup.c | 5 +++++ > mm/mempolicy.c | 5 +---- > 2 files changed, 6 insertions(+), 4 deletions(-) >=20 > diff --git a/mm/gup.c b/mm/gup.c > index 50681f0286de..a8575b880baf 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -980,6 +980,7 @@ static int check_vma_flags(struct vm_area_struct *vma= , unsigned long gup_flags) > * -- If nr_pages is >0, but no pages were pinned, returns -errno. > * -- If nr_pages is >0, and some pages were pinned, returns the number = of > * pages pinned. Again, this may be less than nr_pages. > + * -- 0 return value is possible when the fault would need to be retried= . > * > * The caller is responsible for releasing returned @pages, via put_page= (). > * > @@ -1247,6 +1248,10 @@ int fixup_user_fault(struct task_struct *tsk, stru= ct mm_struct *mm, > } > EXPORT_SYMBOL_GPL(fixup_user_fault); > =20 > +/* > + * Please note that this function, unlike __get_user_pages will not > + * return 0 for nr_pages > 0 without FOLL_NOWAIT It's a bit unclear to me on whether "will not return 0" applies to "this function" or "__get_user_pages"... Might be easier just to avoid mentionin= g __get_user_pages? > + */ > static __always_inline long __get_user_pages_locked(struct task_struct *= tsk, > =09=09=09=09=09=09struct mm_struct *mm, > =09=09=09=09=09=09unsigned long start, > 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, unsigne= d long addr) > =20 > =09int locked =3D 1; > =09err =3D get_user_pages_locked(addr & PAGE_MASK, 1, 0, &p, &locked); > -=09if (err =3D=3D 0) { > -=09=09/* E.g. GUP interrupted by fatal signal */ > -=09=09err =3D -EFAULT; > -=09} else if (err > 0) { > +=09if (err > 0) { > =09=09err =3D page_to_nid(p); > =09=09put_page(p); > =09} Again, this is my totally humble opinion: I'm fine with removing the commen= t, however I still don't think it's helpful at all to explicitly remove a chec= k against invalid return value (err=3D=3D0), especially if that's the only fu= nctional change in this patch. Thanks, --=20 Peter Xu