Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp327764img; Wed, 20 Mar 2019 01:17:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqx6Aem/xMzBydr6uACa5KtHGYKlQE+Zy0w9xgziXTt0RXmPIa28MUmz1UWWpuHz6O0Zao+S X-Received: by 2002:a17:902:a714:: with SMTP id w20mr6790801plq.331.1553069869281; Wed, 20 Mar 2019 01:17:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553069869; cv=none; d=google.com; s=arc-20160816; b=oE7Mj73gX1i20p5yXn/IBiCrodTzd+f4gwT8uxVuptVRjsRWhOnRVRUviT4dSbdfq8 3QAfPHskWIW+n8BEr0tTXPARxTpStR3P90v1ZlQ+y9tBpIE8/fE66cof7Esy02zcdKJu k3TI/u62zaRx4lhxKd0L6sNjXgyy4WIncTp30p9N/Ace03QXtFSU++chO8SEzKXVWM4U S0rXSB9zs9h9hPbBkCaztNxzdB6Jr239icR36OPFViZ6+5wqjb/6C+LV696ceO3segbb qLmLF0xVoxitnbCWPUYRnXFgtylpUzJJ37miEoFGQGvB5prkcJYqqFtvEtg5o+xuJt/S LAlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=gMOuqOcjvcH0Tt3eGgc58YsblYaSfwnwK1xt4I6S798=; b=Nu9AApSC6MPrsj+kG2jIvUKwUTA8M15ctkIJU1gzblgalAgxZrhD7kV95gGj4Awm67 tgxcYp7svL2tgBR82v1KIrrZAJqPZBY+mdtYqMxVs2g8rvU8POIMQrvs7WSzrszFwRdQ K+cg2ox8041+Ev+qfIGROH3LgVZ1CyJ0dwPQVzvYFy5pVaJr29qv9658rhQXGvZN+zHS aOiYKlpFyInw0sUGKKbBqzE0HoCWPL96X9QDz+JQUyD9aeTx26hD3PuEqOAoDvRSub3Q gjL6DXJQad00/e7g0NcKcYgrJll7fgnMTV7oXTHXIdsM7gcYRQU6FdT05Yi8SjLj8xqp zcow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r34si1154491pgl.120.2019.03.20.01.17.33; Wed, 20 Mar 2019 01:17:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727843AbfCTIQs (ORCPT + 99 others); Wed, 20 Mar 2019 04:16:48 -0400 Received: from charybdis-ext.suse.de ([195.135.221.2]:60098 "EHLO suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726686AbfCTIQs (ORCPT ); Wed, 20 Mar 2019 04:16:48 -0400 Received: by suse.de (Postfix, from userid 1000) id 83BD2461B; Wed, 20 Mar 2019 09:16:46 +0100 (CET) Date: Wed, 20 Mar 2019 09:16:46 +0100 From: Oscar Salvador To: Yang Shi Cc: chrubis@suse.cz, vbabka@suse.cz, kirill@shutemov.name, akpm@linux-foundation.org, stable@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: mempolicy: make mbind() return -EIO when MPOL_MF_STRICT is specified Message-ID: <20190320081643.3c4m5tec5vx653sn@d104.suse.de> References: <1553020556-38583-1-git-send-email-yang.shi@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1553020556-38583-1-git-send-email-yang.shi@linux.alibaba.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 20, 2019 at 02:35:56AM +0800, Yang Shi wrote: > Fixes: 6f4576e3687b ("mempolicy: apply page table walker on queue_pages_range()") > Reported-by: Cyril Hrubis > Cc: Vlastimil Babka > Cc: stable@vger.kernel.org > Suggested-by: Kirill A. Shutemov > Signed-off-by: Yang Shi > Signed-off-by: Oscar Salvador Hi Yang, thanks for the patch. Some observations below. > } > page = pmd_page(*pmd); > @@ -473,8 +480,15 @@ static int queue_pages_pmd(pmd_t *pmd, spinlock_t *ptl, unsigned long addr, > ret = 1; > flags = qp->flags; > /* go to thp migration */ > - if (flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)) > + if (flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)) { > + if (!vma_migratable(walk->vma)) { > + ret = -EIO; > + goto unlock; > + } > + > migrate_page_add(page, qp->pagelist, flags); > + } else > + ret = -EIO; if (!(flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)) || !vma_migratable(walk->vma)) { ret = -EIO; goto unlock; } migrate_page_add(page, qp->pagelist, flags); unlock: spin_unlock(ptl); out: return ret; seems more clean to me? > unlock: > spin_unlock(ptl); > out: > @@ -499,8 +513,10 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned long addr, > ptl = pmd_trans_huge_lock(pmd, vma); > if (ptl) { > ret = queue_pages_pmd(pmd, ptl, addr, end, walk); > - if (ret) > + if (ret > 0) > return 0; > + else if (ret < 0) > + return ret; I would go with the following, but that's a matter of taste I guess. if (ret < 0) return ret; else return 0; > } > > if (pmd_trans_unstable(pmd)) > @@ -521,11 +537,16 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned long addr, > continue; > if (!queue_pages_required(page, qp)) > continue; > - migrate_page_add(page, qp->pagelist, flags); > + if (flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)) { > + if (!vma_migratable(vma)) > + break; > + migrate_page_add(page, qp->pagelist, flags); > + } else > + break; I might be missing something, but AFAICS neither vma nor flags is going to change while we are in queue_pages_pte_range(), so, could not we move the check just above the loop? In that way, 1) we only perform the check once and 2) if we enter the loop we know that we are going to do some work, so, something like: index af171ccb56a2..7c0e44389826 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -487,6 +487,9 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned long addr, if (pmd_trans_unstable(pmd)) return 0; + if (!(flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)) || !vma_migratable(vma)) + return -EIO; + pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl); for (; addr != end; pte++, addr += PAGE_SIZE) { if (!pte_present(*pte)) > } > pte_unmap_unlock(pte - 1, ptl); > cond_resched(); > - return 0; > + return addr != end ? -EIO : 0; If we can do the above, we can leave the return value as it was. -- Oscar Salvador SUSE L3