Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp575959ybz; Wed, 15 Apr 2020 14:22:15 -0700 (PDT) X-Google-Smtp-Source: APiQypKRJe5jtrMRBHrwP+vzrNRhHPgKEsZ1X1mnlP9HnAfnwuJAfFuLtHQrA7xG4RoNQ6PjDtJc X-Received: by 2002:a17:906:7d15:: with SMTP id u21mr6762950ejo.364.1586985735770; Wed, 15 Apr 2020 14:22:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586985735; cv=none; d=google.com; s=arc-20160816; b=M6FuYkgRxjwBsO/m5iPMy1e/FEn6vROAjTqq5ScLPX/Wjbzi80pcEtzPPnYU3abxMT aCMjHfGLgKKm3IuJjH5Y1lRr90Ndzdw5kXrqMuIpXxIrFlTJt1ZyEkYX043AgtFzL1VE VbCRgvDiWBxpPuL/oK6i5//qAtB90HIC8aR3CTidA9ZvPzrnIX7SDaLXmq71dF3kmG5Z Twe1Z7IH8X/qPVxm+Zs1op2kf7xB25/lR4pSscwKb/5zaZgA8Yc9m1Ihll/5ADGM502v 226aJLc2LXydhv4NzryZ0CmJaoHxn5xsz7s2WXO+MqODu96Y4XVsLkj0vYCLz7+TWF77 6odQ== 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; bh=mlggN6FzV3SvAILUurU6iRo1X00FeZKjeDeaqGYILUU=; b=t9qPRZOM3pbrji7CGseQ2IGCrZXxC8KP4mi3ickN6PhclHmSgsLzwJnigMavF0ZG+G fn13OUvtl2UdLR4xi2R/3yzcswKdJEkxpmPczM5KJ77QVya4ucuDelhhEf5FwHx5A1kl gDaRW+FQ8o8DABeM2/qzjBZVt3owmeB0oTXltd4wgAS4d0psPe6BWYQOIHFCDXxa9/ZI 2VdEbb0TnN9ZUvj2ieOP7HDw+J6M51/9KfF5B7c3Qpu5rPjwaHGGG/kepe/bMiw6Cm5H Dm4PJ9076IA29r5/mXOB9KMm5hC/D4ev1DUmQEKypR5jIVjJFbecuQtsECJQkZcyt3Rl rjqg== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k2si5580282edl.244.2020.04.15.14.21.52; Wed, 15 Apr 2020 14:22:15 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2438899AbgDNLEi (ORCPT + 99 others); Tue, 14 Apr 2020 07:04:38 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:43900 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2438877AbgDNLEd (ORCPT ); Tue, 14 Apr 2020 07:04:33 -0400 Received: by mail-wr1-f67.google.com with SMTP id i10so13792180wrv.10 for ; Tue, 14 Apr 2020 04:04:32 -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=mlggN6FzV3SvAILUurU6iRo1X00FeZKjeDeaqGYILUU=; b=UzgeQf0hjsFwTEnZqViPuikm8T4xtCsNKfJnOY3DMqT7V9Y90UVkKJiGhVSxlGoNmC PZ78ByL7iQioTmgejDVY4q5kaNwI2ek1Gr0mubiyQHmYHoCdjDHjK/GAY66LxnpyHF6w MWZuV7T83ejlsNzPHQQnPLYZXKoyg40+lFx8+NOPdp9bgrWGWVPR6lJhFZXOCTWoW950 c2v0jQgpoq2iurJUjMl6n/LNbQKofHuO3eYI2p77Dvz877HOiWozkYRL9E5UV3WGh8fK deQOBqRA5P/ScuCyV6oZe5JMBSf6sNsxH0nEzwhqvd8zhc9s5nnOBwWbc6TE9oU7ijhg SXhQ== X-Gm-Message-State: AGi0PuarHKoaa694XEqpmnkMqRQTwswYl3gqPRIvL6rzVc4S89srykK0 d23aKhiHQ7XSuaJjfFbHtaQ= X-Received: by 2002:adf:e604:: with SMTP id p4mr10544113wrm.257.1586862271812; Tue, 14 Apr 2020 04:04:31 -0700 (PDT) Received: from localhost (ip-37-188-180-223.eurotel.cz. [37.188.180.223]) by smtp.gmail.com with ESMTPSA id c83sm15732559wmd.23.2020.04.14.04.04.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2020 04:04:30 -0700 (PDT) Date: Tue, 14 Apr 2020 13:04:29 +0200 From: Michal Hocko To: Linus Torvalds Cc: Peter Xu , Linux Kernel Mailing List , Linux-MM , Andrew Morton , syzbot+693dc11fcb53120b5559@syzkaller.appspotmail.com Subject: Re: [PATCH 1/2] mm/mempolicy: Allow lookup_node() to handle fatal signal Message-ID: <20200414110429.GF4629@dhcp22.suse.cz> References: <20200408014010.80428-1-peterx@redhat.com> <20200408014010.80428-2-peterx@redhat.com> <20200409070253.GB18386@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 09-04-20 09:42:20, Linus Torvalds wrote: > On Thu, Apr 9, 2020 at 12:03 AM Michal Hocko wrote: > > > > This patch however doesn't go all the way to revert it because 0 return > > value is impossible. > > I'm not convinced it's impossible. __get_user_pages is documented as * -- If nr_pages is 0, returns 0. * -- 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. but let me double check the actual code... There seem to be only one exception the above rule AFAICS. faultin_page returning EBUSY will be overriden to either 0 for the first page or return the number of already pinned pages. So nr_pages > 0 && ret = 0 is indeed possible from __get_user_pages :/ That will be the case only for VM_FAULT_RETRY, thoug. Now __get_user_pages_locked behaves differently. It keeps retrying the fault until it succeeds unless FOLL_NOWAIT is specified. Then it would return 0. Why we need to return 0 is not really clear to me but it seem to be a long term behavior. I believe we need to document it. > And if it is, then the current code is harmless. Yes from the above it seems that the check is indeed harmless becasue this path doesn't use FOLL_NOWAIT and so it will never see 0 return. I find a reference to EINTR confusing so I would still love to change that. > Now, I do agree that we probably should go through and clarify the > whole range of different get_user_pages() cases of returning zero (or > not doing so), but right now it's so confusing that I'd prefer to keep > that (possibly unnecessary) belt-and-suspenders check for zero in > there. > > If/when somebody actually does a real audit and the result is "these > functions cannot return zero" and it's documented, then we can remove > those checks. Would you mind this patch instead? commit bc6c0fa7c7fb5eb54963dca65ae4a62ba04c9efa Author: Michal Hocko Date: Thu Apr 9 08:26:57 2020 +0200 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 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 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 + */ 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); } -- Michal Hocko SUSE Labs