Received: by 10.213.65.68 with SMTP id h4csp2246544imn; Thu, 5 Apr 2018 11:29:55 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/6gvxEN/2kNxV/n/3PFdOEJAhCr9nYGhMv0loPyIEY1xkrxiBlinrjOeBSYyk3ai+Ok2D+ X-Received: by 10.99.0.200 with SMTP id 191mr15538570pga.33.1522952995635; Thu, 05 Apr 2018 11:29:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522952995; cv=none; d=google.com; s=arc-20160816; b=l3Tl8BubMVC7SYXUhy4auuLUgHyp0FiNsCIH4/XDqvpKmHOwCxlu7V3eCdsnlxNdQf QMtbRXKKdYmRiNut+j11F4UxmhlBx8IM3v/NP2JCuhzfsVSPY+taqyan4EQznd7I1bRG AAYcc6oZXyMFx9A75gdM3thGs49808KOryK0QcFycozywxS8pdA/rZHPIBfXQ+d+UQXv QpAtDa129tZJ3VyxntE63O8oYGFhMnYMNGTof7JmyrcZpo17YYdGJz6rjjwSSuRKKRIP Xfhl4LF2Bv3XzVuY8PVzko18JP1XBMEFHCEPsDcS9IktGCr2cXUMhW4nf4u3NeNz0urp H6oQ== 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 :arc-authentication-results; bh=5p521ZdmvfQg+RTIqdDQVaeplqZqx5isCCfzodCgTBM=; b=lg9AxA2AVp7zcRxoUYoS1v5V3T+KqYJItW3Pd6bc3WflpkW/3edqIDtxDzMVOWistT yU+3ONgX9eCOofWoFI82Q5hOaY6hLt4Ic1DlsXQirj9CPfM+SNw0Hf9d/Q3PxBX76ND6 /35Kb6TCg46nev9w+pt9GpDPTPMPwg1rF/5mqWqC7LaHFqB3M+M/q6l+DgJuOhe+fpVM NP9LkN3VP88ApoDeiJcfbPHD1/iwmVf9+MyJgKGLD1Equh75AIGxjlAwDIYlrsj5LV44 LvPZvUt6wfgcPU3VPD2UZG8xDYWGXamYqDHK2TEZaQeTCojR62DYVsmaUxHEjyB0a54Z 7jYg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u10si5850366pgc.532.2018.04.05.11.29.40; Thu, 05 Apr 2018 11:29:55 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751867AbeDES23 (ORCPT + 99 others); Thu, 5 Apr 2018 14:28:29 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:34838 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751442AbeDES21 (ORCPT ); Thu, 5 Apr 2018 14:28:27 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9D32477067; Thu, 5 Apr 2018 18:28:26 +0000 (UTC) Received: from redhat.com (ovpn-122-62.rdu2.redhat.com [10.10.122.62]) by smtp.corp.redhat.com (Postfix) with SMTP id 52C4D2166BAE; Thu, 5 Apr 2018 18:28:25 +0000 (UTC) Date: Thu, 5 Apr 2018 21:28:25 +0300 From: "Michael S. Tsirkin" To: Linus Torvalds Cc: Al Viro , Linux Kernel Mailing List , stable , syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com, linux-mm , "Kirill A. Shutemov" , Andrew Morton , Huang Ying , Jonathan Corbet , Peter Zijlstra , Thomas Gleixner , Thorsten Leemhuis Subject: Re: [PATCH] gup: return -EFAULT on access_ok failure Message-ID: <20180405211945-mutt-send-email-mst@kernel.org> References: <1522431382-4232-1-git-send-email-mst@redhat.com> <20180405045231-mutt-send-email-mst@kernel.org> <20180405171009-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 05 Apr 2018 18:28:26 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 05 Apr 2018 18:28:26 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mst@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 05, 2018 at 08:40:05AM -0700, Linus Torvalds wrote: > On Thu, Apr 5, 2018 at 7:17 AM, Michael S. Tsirkin wrote: > > > > I wonder however whether all the following should be changed then: > > > > static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm, > > > > ... > > > > if (!vma || check_vma_flags(vma, gup_flags)) > > return i ? : -EFAULT; > > > > is this a bug in __get_user_pages? > > Note the difference between "get_user_pages()", and "get_user_pages_fast()". > > It's the *fast* versions that just return the number of pages pinned. > > The non-fast ones will return an error code for various cases. > > Why? > > The non-fast cases actually *have* various error cases. They can block > and get interrupted etc. > > The fast cases are basically "just get me the pages, dammit, and if > you can't get some page, stop". > > At least that's one excuse for the difference in behavior. > > The real excuse is probably just "that's how it worked" - the fast > case just walked the page tables and that was it. > > Linus I see, thanks for the clarification Linus. to repeat what you are saying IIUC __get_user_pages_fast returns 0 if it can't pin any pages and that is by design. Returning 0 on error isn't usual I think so I guess this behaviour should we well documented. That part of my patch was wrong and should be replaced with a doc update. What about get_user_pages_fast though? That's the other part of the patch. Right now get_user_pages_fast does: ret = get_user_pages_unlocked(start, nr_pages - nr, pages, write ? FOLL_WRITE : 0); /* Have to be a bit careful with return values */ if (nr > 0) { if (ret < 0) ret = nr; else ret += nr; } so an error on the 1st page gets propagated to the caller, and that get_user_pages_unlocked eventually calls __get_user_pages so it does return an error sometimes. Would it be correct to apply the second part of the patch then (pasted below for reference) or should get_user_pages_fast and all its callers be changed to return 0 on error instead? @@ -1806,9 +1809,12 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write, len = (unsigned long) nr_pages << PAGE_SHIFT; end = start + len; + if (nr_pages <= 0) + return 0; + if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ, (void __user *)start, len))) - return 0; + return -EFAULT; if (gup_fast_permitted(start, nr_pages, write)) { local_irq_disable(); -- MST