Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp149666ybz; Tue, 21 Apr 2020 06:31:25 -0700 (PDT) X-Google-Smtp-Source: APiQypIv9RuYX4JS+Wo/jv0QxIUyCGNVXldDO2ieD+3WwlM2D/trbKze5sPoGE3AhVYrxOAh/VtE X-Received: by 2002:a05:6402:1d1c:: with SMTP id dg28mr2771027edb.315.1587475885727; Tue, 21 Apr 2020 06:31:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587475885; cv=none; d=google.com; s=arc-20160816; b=Gz9RJpVaUCAEE8zp1tPu+sgjjrMUIClcSV8LnkjqpvmBbNWxQc95K0MGjRhn+iRN+/ MM6UJYqj9GF0dEFokIe35C5md8lQPMIl5phetj1Vk0+Kp01YG1Qn+YCHBtzuA2zUU2gE YsDlGehi13Bg3t4fCWXX93Ddj2wYWkjdMaKJ2EemnTJhZd8iCTFezdnBL2BdrZNwU4FY 6Z9tVJbqP6z0ob3qfSzPSs3x7xn9z6QpYdlWRF0EWF+a2ckVA6rFlWpbsu/2UDC+5T4k MaKbPmHTF+UYZUjBZgFumwOX1/bFv2GF4aUklxmjE6jcYEeLTFXqt43RIiF2beNoekMj uwHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=O1Ti1KIvSIMKpnNlcfoK/lyDq223f9fsTlxlc6OUn10=; b=nxAvsQFC3qBVqUbKvODiHY7NHwNeri3uOby7HE0aIFFV56/qNlE9ICCl4PlXkzA1f6 VYGYXt2Pi80J7mUiKPvr9NiMJhDOhEAkRFdWQtJRC1oKAwzTARELqldPSm3ZQOx6OA27 fy60A4z9xlYHX5Mm0XRpX1NtsN+OZaIbNwf0Lh/YNFJhX52CYROAQgetnes+um0PSOZf pOwjgy66GwJ7Q8rtr6vqXly7iS7A/3MiDp6XQHLPjUROxGGt/wDu2wkP4XnERiS3Qbyd DFtaTAegyqsj45FgRUV89Nv3UBSF18TSlHWazx0eOgsG7X+Hq4oTLbqLJSN72imdhyjC Y1ZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GFldD7iE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h14si1522090edv.50.2020.04.21.06.31.01; Tue, 21 Apr 2020 06:31:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GFldD7iE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728847AbgDUN3Y (ORCPT + 99 others); Tue, 21 Apr 2020 09:29:24 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:53174 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726018AbgDUN3X (ORCPT ); Tue, 21 Apr 2020 09:29:23 -0400 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: in-reply-to:in-reply-to:references:references; bh=O1Ti1KIvSIMKpnNlcfoK/lyDq223f9fsTlxlc6OUn10=; b=GFldD7iENmILOzgqaxgwdtJ7oMh/N9R8VZigDSor6dHeKyEid4fHcY0w+PJYxctclHDQ74 CBWA7PSwkSxIqg4emOlW9vfVBPiyootIsumYC2GjGFw23m6jTDtuCrNKfPa3gEo0JUeVpf oYPigCLgT1C7MgtcXz6Na0XAS1IUhOE= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-14-zpQmYi5ZP1yCEmIbScggYw-1; Tue, 21 Apr 2020 09:29:19 -0400 X-MC-Unique: zpQmYi5ZP1yCEmIbScggYw-1 Received: by mail-qv1-f70.google.com with SMTP id p12so13805530qvm.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=muI/w4FHPAGpdK6CET9C7qIZF9Fu5krtTa5VF16d5176hgEt+00xNzJT5hOLufe9Zi 1SlymDufwXOSxaPvyhW3J4v50NPhvPSTSAriuP06/8yu8WjK4SWfE3pwul945zfkhtGa Jd8Xcm8lu+DLlaWp3R9/k/UkiKshvkGG0FnIerQqlN+4H5TPWqwd+LBDFxxzd11cAWq5 t9J+wylqPq0UOEDUE5gxSlMRb3HSgm70DdwEtrahA7KlLSGYSYH9oWl5jeaxqacqrUdu oopI0hc/hnS2ImpmBYX7nSvJNCxYxxxjYkYaT6TM+MPS+mAgNChRl5em7FBM2CZ5pZ1b XFHg== X-Gm-Message-State: AGi0PuYjZiMCbTcJ7EmRYIWSmyQRpGtC7xFvnusQeQjUspNJpYjF+aLJ q+x1/3722SL8bCOrvoQQoNa5PQtvJOi8vPQ/dzXonOFH7TRqB/iSRRwA8oGbB6mup0TPuyBF8C4 cbdGTrpDHOPrGIkFBY+fYIwNg X-Received: by 2002:ad4:4182:: with SMTP id e2mr20461675qvp.61.1587475759127; Tue, 21 Apr 2020 06:29:19 -0700 (PDT) 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200421071026.18394-1-mhocko@kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 21, 2020 at 09:10:26AM +0200, Michal Hocko wrote: > From: Michal Hocko > > 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 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. > > Signed-off-by: Michal Hocko > --- > mm/gup.c | 5 +++++ > mm/mempolicy.c | 5 +---- > 2 files changed, 6 insertions(+), 4 deletions(-) > > 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, struct mm_struct *mm, > } > EXPORT_SYMBOL_GPL(fixup_user_fault); > > +/* > + * 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 mentioning __get_user_pages? > + */ > static __always_inline long __get_user_pages_locked(struct task_struct *tsk, > struct mm_struct *mm, > unsigned 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, 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); > } Again, this is my totally humble opinion: I'm fine with removing the comment, however I still don't think it's helpful at all to explicitly remove a check against invalid return value (err==0), especially if that's the only functional change in this patch. Thanks, -- Peter Xu