Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp3473832imb; Tue, 5 Mar 2019 10:11:12 -0800 (PST) X-Google-Smtp-Source: APXvYqyUPFsXenDvMRA/UPJ/lxOqMczhaPjZxqAwIa21f8vnzKnEw78iFXNAs51SsM4nSOCscWTl X-Received: by 2002:a17:902:b101:: with SMTP id q1mr2589161plr.296.1551809472299; Tue, 05 Mar 2019 10:11:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551809472; cv=none; d=google.com; s=arc-20160816; b=0GQcnJQTMnQq39aVP9iFT5dlwOFpWwjftgOhpCuL5nT57K24ROkQroUxL2yQ7rRocR u+D7OzBROagCS7wU+86McjJI00HFgc7hKCZ2qHZ9/0+T/djG7clPWkRPHOPCnJEcH969 WrBlC1QcN6grWB59ui+0frDv75C1mzBiGAF4RIMqPFAn9y1W4V9zO69LZzogMFLKp/aq TPJZqSewTCz5wrZtdUN6aI9vmba0viEfk3DPbEt966Zz1AqCcCKxI9e675Wzl2CvG0js qI+ZlfZxoXfbD97nfmbKE/6YPMxwgr20CHylrWO871WtcnJUWthRfd9IkKzImMRLUn7s /StQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=gHJM1QM5EJjUOY2FDdaKsqaFOXK3eKenoExJbNcqN4g=; b=TNepmW8VPGgnQEXZQ+SeBZ/hUM4a1jg/XkvbFnY5BmCpIksQEhfUo1IevzIXGv+iw8 XLFDcVrzuNK6eb2P0ChNvFUNC/iHEwxIhGPYp5bZn6PkySHRHd1PcZdMXF3I4E4BPK4z auA/yIJ6xlxqqEkddYqu+d0YcbD7LJotSrSP+vx2PuE0owC7nmwdtCa/rLT8vXZJZ5bp scJsuCyWdwBaELdx1NtoENeXRloI6SadOj08ybCbWblRT0veZhv2LeTDH2C04IH2KDP7 4dpLP1BtqBmawXWZhOrCcu5kuj8AMNKxp61XiLED+c/i1h5jwWsViyPw5YjTCmfoRPKl MHAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=p2Y8hdNn; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h22si8232363pgv.533.2019.03.05.10.10.56; Tue, 05 Mar 2019 10:11:12 -0800 (PST) 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; dkim=pass header.i=@google.com header.s=20161025 header.b=p2Y8hdNn; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730089AbfCERru (ORCPT + 99 others); Tue, 5 Mar 2019 12:47:50 -0500 Received: from mail-pg1-f195.google.com ([209.85.215.195]:36336 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730075AbfCERrt (ORCPT ); Tue, 5 Mar 2019 12:47:49 -0500 Received: by mail-pg1-f195.google.com with SMTP id r124so6127965pgr.3 for ; Tue, 05 Mar 2019 09:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gHJM1QM5EJjUOY2FDdaKsqaFOXK3eKenoExJbNcqN4g=; b=p2Y8hdNnqthiWdPWaqmFy7b/8k5R5/BmM19TtexhhrWTduZyd1hXY4SAlsKdKjdcPI sat72+hX+ZkqOFLb8LdG6frRV2OtpqnIvtHde17vUlUIvR5ceD/KeoyIS1GlzP+N5xK/ u9EerRuH/goJiFrHsvZzQvnJBSrIj70uKlg5qfpjpHnK+3pQf5iWM67T1SrG4ybBTvVt nLxM02ayT0Y0fMLUulujQe30SOR0DSgftsFb1H6mDwY74OgZRJx4phYor6WZSVxbIsDK myhDVYqAdqOKhriLkvtPoMwKzAS1kM6d+LD+r4uhhuiNhJStX3Y7uIGJ0qshrYteS8OD MDIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gHJM1QM5EJjUOY2FDdaKsqaFOXK3eKenoExJbNcqN4g=; b=m2pAuc7BWlGIWW6bO4+6khcXFGg/JLfGBg/CjHNhGXWaIBJpibr00aJ9rY/nthDRwh rJHWz0A+e1d9ci77kVR8ZsvA/m/NlQXjHtHDTJ5dRpouxSGhZyKgKVDIrm0EpYWCzLQR oHSo1GG9PQqHgmwtY95TK8983Lhej9wrHgxWvGHy5ca1rn/hFGV2GutMgbFjah66ovs/ ynt13c8PxjQm0s7xQHD2Ai3LSQ1KwB/cCKpFfkH8FS/oN0n5yLsirLfGl25qwKS5gd3H BBbCFL3FnITdtO3M1nQeYrpyGaU54ZFTS0eWE8wmH+I9/eU2fB89g9N9zJPUab1bklMi imRw== X-Gm-Message-State: APjAAAWl0XPbhA5g8X33BJo2Ol8LfqjHZ3b6k+d1OVIarOJ2z3qqLR69 kP//v2XX1fNlqQeU+pFrbUpjWIpRsrrDRj7q7Ou3ow== X-Received: by 2002:a65:6651:: with SMTP id z17mr2299629pgv.95.1551808068440; Tue, 05 Mar 2019 09:47:48 -0800 (PST) MIME-Version: 1.0 References: <8343cd77ca301df15839796f3b446b75ce5ffbbf.1550839937.git.andreyknvl@google.com> <73f2f3fe-9a66-22a1-5aae-c282779a75f5@intel.com> <20190301165908.GA130541@arrakis.emea.arm.com> In-Reply-To: From: Andrey Konovalov Date: Tue, 5 Mar 2019 18:47:37 +0100 Message-ID: Subject: Re: [PATCH v10 07/12] fs, arm64: untag user pointers in fs/userfaultfd.c To: Dave Hansen Cc: Catalin Marinas , Will Deacon , Mark Rutland , Robin Murphy , Kees Cook , Kate Stewart , Greg Kroah-Hartman , Andrew Morton , Ingo Molnar , "Kirill A . Shutemov" , Shuah Khan , Vincenzo Frascino , Linux ARM , "open list:DOCUMENTATION" , Linux Memory Management List , linux-arch , "open list:KERNEL SELFTEST FRAMEWORK" , LKML , Dmitry Vyukov , Kostya Serebryany , Evgeniy Stepanov , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Chintan Pandya , Luc Van Oostenryck , Dave Martin , Kevin Brodsky , Szabolcs Nagy Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 1, 2019 at 7:37 PM Dave Hansen wrote: > > On 3/1/19 8:59 AM, Catalin Marinas wrote: > >>> So, we have to patch all these sites before the tagged values get to the > >>> point of hitting the vma lookup functions. Dumb question: Why don't we > >>> just patch the vma lookup functions themselves instead of all of these > >>> callers? > >> That might be a working approach as well. We'll still need to fix up > >> places where the vma fields are accessed directly. Catalin, what do > >> you think? > > Most callers of find_vma*() always follow it by a check of > > vma->vma_start against some tagged address ('end' in the > > userfaultfd_(un)register()) case. So it's not sufficient to untag it in > > find_vma(). > > If that's truly the common case, sounds like we should have a find_vma() > that does the vma_end checking as well. Then at least the common case > would not have to worry about tagging. It seems that a lot of find_vma() callers indeed do different kinds of checking/subtractions of vma->vma_start and a tagged address, which look hardly unifiable. So untagging the addresses in find_vma() callers looks like a more suitable solution.