Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp5748605ybh; Wed, 7 Aug 2019 10:44:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqzEUvIDEOPuqsbMsc4MuN5TRp/9m0DQKMzA9F17y7laC+8fXGFOhIFyThos2/yrhznK7peI X-Received: by 2002:a63:481c:: with SMTP id v28mr8653290pga.50.1565199873405; Wed, 07 Aug 2019 10:44:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565199873; cv=none; d=google.com; s=arc-20160816; b=tRgnV4Kt3IOj7HSZJ0IZJ45h1ALaEmeBzhiywip3CvBiG5qzqGGWpt3MuRoChLbJnu P1BaHhNk6ebFw+t+prYY3O4KHi9uV7xaPAxttAOoF2f7LEIevV+OhsdpZoYVTk3pAigP gBUwbqkOLgqRtixSPUsPOPQ1ctnsM3AiWXMjqaqPGlo1taPeke3aQNdSra6jUqjE7IO9 DyELVWZjj/kunTNJBQfaUbYIWjXvFNeuKDGQJYkVx2UjIK4b7HurXUrvQx9pFXejuAIz ltkkefn812vLh/fj2+eAZWKCqDCdMsD6phSSTUEMvyq8fi9HYqc6LYaM2gZ1hCrtYuLd an5g== 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=8eJrnZxNMCItWIynTatJDEuA9CjWuilxGr3zPMXDYoA=; b=h1R3fl42nTnl+IJKnX5BshmWkYBmHlUOj6Lo0HE1tOGR5K9jbq4t1Ch1bMDUdH//Ow /+ZxDBRpogc9GF3kfNU5unn9SfQdFP5l1RC+L/OO5HtrL7EcLPqbeLbATM2S8nP1dhyn 8bH/u9mxDNO7z/8/K9MtJTLCAR4LcrQQ/kVOkb0IqnwfHPISzAdFJKfLfDuEJRAK0tfT QuRAy71IIU4eqwO2kcFNqCyWMqjMlwzHSfFOrtOueF6FjRejwmsqVnwzs0cHiqMfnh/N rskh65ugCXcsgmTT/Y6qqxYj+s8kg2vC99GJwnF8RXBqmG32+53enn7jm75j6jFNCLzc b/fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=lvCOFn8k; 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 t17si16483515pgu.48.2019.08.07.10.44.18; Wed, 07 Aug 2019 10:44:33 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=lvCOFn8k; 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 S2388386AbfHGRRs (ORCPT + 99 others); Wed, 7 Aug 2019 13:17:48 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:36932 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729897AbfHGRRs (ORCPT ); Wed, 7 Aug 2019 13:17:48 -0400 Received: by mail-pl1-f193.google.com with SMTP id b3so41807958plr.4 for ; Wed, 07 Aug 2019 10:17:47 -0700 (PDT) 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=8eJrnZxNMCItWIynTatJDEuA9CjWuilxGr3zPMXDYoA=; b=lvCOFn8kPw5sKWIBqAtj9nTDw5hreHjOLB8fZD9LK4XqWLqI/y9ZOZsE/4TR27f4Um 7sNjnMM7si41kfySDx/t9SNrRsRpe9RSjuTSsxtP/LZWsBQ/9wQ/cD4jAY9Afx15eKqx drzyP65XIEr5B54raR+/HRbXQh7LyawRCf3zPKIRTqPoYkdFiyNYDBtM/quaMKyDYY7N e0hyz+AA4niyiPyNwzehq1Nhy/KS415dSI2CnjbBlju4Nld2LwgPUsvJDvfBXebX8Wbi Nmslq3Y7cfQOcqEViWBEfcEzC2SDosb0kffCvwGdMnZ05+LE89QNyyYCkt8oyQaFasdF n/vQ== 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=8eJrnZxNMCItWIynTatJDEuA9CjWuilxGr3zPMXDYoA=; b=hXkibDPxvMfmrirFqVA9AKjqxcOQB0m8oO2iT3mfUqlc3DJq8r7KJchgQBbgnZeJBv YRZOp6zF5amtDg5vlkGQGaRD9RsDXSAbBhUZCImn3hgGcqVrRH8UAeGwaXr0KBYFDUY6 CzYXNt/5bgOgb/15nNIN1XUqPS9qGUL4cKzdDcxTc5Vv8zeB18MJ6HnQPdIcBYEo6O1x favxansONe7c4qJz9p7rntJ+7Sbz6FNkGosPdU5zqif6/gu0bm8m/MwIUPY55D0rvgQn gIlHBvk8LX9kq69d5LXtbjZpUzpq0rYNzyojtBjpJHxB6w17qn/M2bDNjrwGI6gkz0D3 vHLQ== X-Gm-Message-State: APjAAAUhHBWiKdwiZdwvDsyo4tqk5WUrEWw+M3py1DKmTqRubdutJaUg WhVWu6iDwXA4lzNZyIXxj4WmpPcqCz1NhRG7xNnIMQ== X-Received: by 2002:a65:4b8b:: with SMTP id t11mr8596413pgq.130.1565198266795; Wed, 07 Aug 2019 10:17:46 -0700 (PDT) MIME-Version: 1.0 References: <20190724140212.qzvbcx5j2gi5lcoj@willie-the-truck> <20190724142059.GC21234@fuggles.cambridge.arm.com> <20190806171335.4dzjex5asoertaob@willie-the-truck> In-Reply-To: <20190806171335.4dzjex5asoertaob@willie-the-truck> From: Andrey Konovalov Date: Wed, 7 Aug 2019 19:17:35 +0200 Message-ID: Subject: Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel To: Will Deacon , Andrew Morton Cc: Will Deacon , Vincenzo Frascino , Catalin Marinas , Mark Rutland , kvm@vger.kernel.org, Szabolcs Nagy , dri-devel@lists.freedesktop.org, Kostya Serebryany , Khalid Aziz , "open list:KERNEL SELFTEST FRAMEWORK" , Felix Kuehling , Jacob Bramley , Leon Romanovsky , linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org, Christoph Hellwig , Jason Gunthorpe , Linux ARM , Dave Martin , Evgeniy Stepanov , linux-media@vger.kernel.org, Kevin Brodsky , Kees Cook , Ruben Ayrapetyan , Ramana Radhakrishnan , Alex Williamson , Mauro Carvalho Chehab , Dmitry Vyukov , Linux Memory Management List , Greg Kroah-Hartman , Yishai Hadas , LKML , Jens Wiklander , Lee Smith , Alexander Deucher , enh , Robin Murphy , Christian Koenig , Luc Van Oostenryck 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 Tue, Aug 6, 2019 at 7:13 PM Will Deacon wrote: > > On Wed, Jul 24, 2019 at 03:20:59PM +0100, Will Deacon wrote: > > On Wed, Jul 24, 2019 at 04:16:49PM +0200, Andrey Konovalov wrote: > > > On Wed, Jul 24, 2019 at 4:02 PM Will Deacon wrote: > > > > On Tue, Jul 23, 2019 at 08:03:29PM +0200, Andrey Konovalov wrote: > > > > > Should this go through the mm or the arm tree? > > > > > > > > I would certainly prefer to take at least the arm64 bits via the arm64 tree > > > > (i.e. patches 1, 2 and 15). We also need a Documentation patch describing > > > > the new ABI. > > > > > > Sounds good! Should I post those patches together with the > > > Documentation patches from Vincenzo as a separate patchset? > > > > Yes, please (although as you say below, we need a new version of those > > patches from Vincenzo to address the feedback on v5). The other thing I > > should say is that I'd be happy to queue the other patches in the series > > too, but some of them are missing acks from the relevant maintainers (e.g. > > the mm/ and fs/ changes). > > Ok, I've queued patches 1, 2, and 15 on a stable branch here: > > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/tbi > > which should find its way into -next shortly via our for-next/core branch. > If you want to make changes, please send additional patches on top. > > This is targetting 5.4, but I will drop it before the merge window if > we don't have both of the following in place: > > * Updated ABI documentation with Acks from Catalin and Kevin Catalin has posted a new version today. > * The other patches in the series either Acked (so I can pick them up) > or queued via some other tree(s) for 5.4. So we have the following patches in this series: 1. arm64: untag user pointers in access_ok and __uaccess_mask_ptr 2. arm64: Introduce prctl() options to control the tagged user addresses ABI 3. lib: untag user pointers in strn*_user 4. mm: untag user pointers passed to memory syscalls 5. mm: untag user pointers in mm/gup.c 6. mm: untag user pointers in get_vaddr_frames 7. fs/namespace: untag user pointers in copy_mount_options 8. userfaultfd: untag user pointers 9. drm/amdgpu: untag user pointers 10. drm/radeon: untag user pointers in radeon_gem_userptr_ioctl 11. IB/mlx4: untag user pointers in mlx4_get_umem_mr 12. media/v4l2-core: untag user pointers in videobuf_dma_contig_user_get 13. tee/shm: untag user pointers in tee_shm_register 14. vfio/type1: untag user pointers in vaddr_get_pfn 15. selftests, arm64: add a selftest for passing tagged pointers to kernel 1, 2 and 15 have been picked by Will. 11 has been picked up by Jason. 9, 10, 12, 13 and 14 have acks from their subsystem maintainers. 3 touches generic lib code, I'm not sure if there's a dedicated maintainer for that. The ones that are left are the mm ones: 4, 5, 6, 7 and 8. Andrew, could you take a look and give your Acked-by or pick them up directly? > > Make sense? > > Cheers, > > Will Thanks!