From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0088C04AB6 for ; Tue, 28 May 2019 15:57:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 57939208C3 for ; Tue, 28 May 2019 15:57:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="aE5o2Xjl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57939208C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id ED09C6B0279; Tue, 28 May 2019 11:57:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E81A06B027A; Tue, 28 May 2019 11:57:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D4AFA6B027C; Tue, 28 May 2019 11:57:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by kanga.kvack.org (Postfix) with ESMTP id 9C8266B0279 for ; Tue, 28 May 2019 11:57:43 -0400 (EDT) Received: by mail-pg1-f197.google.com with SMTP id a21so6453236pgh.11 for ; Tue, 28 May 2019 08:57:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:subject:to:cc:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=TSW5Hn3kRTvgWzVOcFpKtrTx3K8uzf/zHhDE6UkJMhg=; b=hWYQkqYiCFztshpqhtNPhGDWXttv6d+2VB3q/PuxO5LW1SRRg+ImQlb3BvE5+/xMKe 8k7HeCpeXqiXjNLIjLlhMRsovRDQ7sPgnUlzKO7fI4rk8JmZIZ9gkyQD7K9Rvusi/H19 VRmXqAWFrqPd+JmUPsyoUcloRaIXdUqKJznJbxFLEXGrXM6XUIs+52cC/j00wCiZ31S4 LIOTgEd2Fl5dyeiLcuwCccGhWgiSZBW5401qcmmYiTHgCX+VySSOSYdooyIIGOxCnpWR vaBgZ7miBWYbsZCkwoRKQVkcgMzZCEVZZxvGhDyYZ+O9kpy0M7OgixSM/sb1b4jKl2mB LpSQ== X-Gm-Message-State: APjAAAW0uiR6IvYM5Mwhh9OEiXsbYMc5RMxFo2cwQAcHBqEfGWhcw2in cGtaNVgqAfxeo+ue6+Ph2dNtqueU123jaGGE6F+bxsj3llGaXbgIZmgNHoB3JnmFPV9sMIzTQWT Vl5IfWLWsZMtC06tLBysKRGBzmnUu/KJT0snSune/I6MENk+9V09iSY0DuvoaJRZ7Vw== X-Received: by 2002:a62:1bcc:: with SMTP id b195mr89974774pfb.75.1559059063299; Tue, 28 May 2019 08:57:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqxjWjT+PVKEqMGT+G4PdeZterFhl3Gsfd3nOIhJndVWtTiNNKR2GXz3Z0iz1ADOyyciVQju X-Received: by 2002:a62:1bcc:: with SMTP id b195mr89974691pfb.75.1559059062468; Tue, 28 May 2019 08:57:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559059062; cv=none; d=google.com; s=arc-20160816; b=aINCTPaazxLK0SJht9P5cXZN+s7mQ+5A9oaqo9cvTdSSlGjd9pFRjstzRn+7qbBpdq 6yYh6JcTVjTQebfMnVB4FGJDdDCfrASvPO4gqxDzejL34a4809QQMZK6ZpRRvS2J7tzH Qxrkt76QcHT82zUODnTBHTWbTJ8thUtBNrTkGTmXLRdZEMWurXxLw5QnCG3VRh+elFUI iahPrLuenEZ55XT/5v4QCXnWbltMtNfKhRSA8xS0c2MRMpwvF8tPZbdVJiwA9c2+ef0w DG/3UtqmDil3YPQ8wacqgNc0pRLAlOZW3pDCVd7NITbgj6srxFUJBBUHkghJka/Ltkyc Jt6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:organization:from:references:cc:to :subject:dkim-signature; bh=TSW5Hn3kRTvgWzVOcFpKtrTx3K8uzf/zHhDE6UkJMhg=; b=ZTlVquAFD/iO6niMJTGF24HBkcz+ROEWA+2CuXNbEe9j+Ji6gE4FxK8cW0K3xtLw51 0NX+SKa46AKTLQDtsbkPVorulPmaFty7zv0xJGVjc+1GNXxuQLosmFr2WW6MKyyc73uM 5k9vtCEfjt8mUB66qMWDwI8jyWGTbn4x4jpKer9FL9n8G1pAHHTuAxqujZvm4YdNh2U4 zmpfLRA26yURyxbGc6+/CM03kui5fxGN+OLTYAM019p24QMMNgp1++/KWDMjw9qXEHxm 4EvUfZ5gtVDl9Wnv5xtQ39+hTdBgYmGDY68t2nOizhZkEvaaSxDDgaIwt6aeROtJbsuU 5QrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=aE5o2Xjl; spf=pass (google.com: domain of khalid.aziz@oracle.com designates 156.151.31.86 as permitted sender) smtp.mailfrom=khalid.aziz@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from userp2130.oracle.com (userp2130.oracle.com. [156.151.31.86]) by mx.google.com with ESMTPS id w4si21631429plz.27.2019.05.28.08.57.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 May 2019 08:57:42 -0700 (PDT) Received-SPF: pass (google.com: domain of khalid.aziz@oracle.com designates 156.151.31.86 as permitted sender) client-ip=156.151.31.86; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=aE5o2Xjl; spf=pass (google.com: domain of khalid.aziz@oracle.com designates 156.151.31.86 as permitted sender) smtp.mailfrom=khalid.aziz@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4SFrsgm131787; Tue, 28 May 2019 15:57:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=TSW5Hn3kRTvgWzVOcFpKtrTx3K8uzf/zHhDE6UkJMhg=; b=aE5o2XjlUHuEPSjWqMiGpohpUiDG56sKD1IP525DG6Rta4QOMnUMBqstZq6KiG0AviOJ z3cSZigfuKuEBSdOdJrY4wH4/YduqxO8e84LYTrnjmh52FNL70GggsihlrLUW6e9zFR1 U5Qfsvf02huVroKIQgiArw5hG7xKzDZF7C5ZTmMq9NwEHKRFauk8nWrK67TKs167xUI/ SAULD82GlnTsfhP5VzlY9gJ4m4c+RYimxS8CyfO+Vs4/eFuSqTwUUqtB0SK6QcJcqc/o kk1uWuu44vp/pj598ZqsUa4QDi7Xie95D3zzPOJ+tJ3Yf7yRuTzCC66Xemmkbug5zq0A fw== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 2spw4tc7pc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 May 2019 15:57:32 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4SFu00N056848; Tue, 28 May 2019 15:57:32 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 2sr31ur9xg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 May 2019 15:57:32 +0000 Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x4SFvTsM023226; Tue, 28 May 2019 15:57:29 GMT Received: from [192.168.1.16] (/24.9.64.241) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 28 May 2019 08:57:29 -0700 Subject: Re: [PATCH 4/6] mm: add a gup_fixup_start_addr hook To: Linus Torvalds , Christoph Hellwig Cc: Paul Burton , James Hogan , Yoshinori Sato , Rich Felker , "David S. Miller" , Nicholas Piggin , linux-mips@vger.kernel.org, Linux-sh list , sparclinux@vger.kernel.org, Linux-MM , Linux List Kernel Mailing References: <20190525133203.25853-1-hch@lst.de> <20190525133203.25853-5-hch@lst.de> From: Khalid Aziz Organization: Oracle Corp Message-ID: <2eecb673-cb18-990e-0a61-900ecd056152@oracle.com> Date: Tue, 28 May 2019 09:57:25 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9270 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=864 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905280101 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9270 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=883 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905280101 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 5/25/19 11:05 AM, Linus Torvalds wrote: > [ Adding Khalid, who added the sparc64 code ] >=20 > On Sat, May 25, 2019 at 6:32 AM Christoph Hellwig wrote: >> >> This will allow sparc64 to override its ADI tags for >> get_user_pages and get_user_pages_fast. I have no idea why this >> is not required for plain old get_user_pages, but it keeps the >> existing sparc64 behavior. >=20 > This is actually generic. ARM64 has tagged pointers too. Right now the > system call interfaces are all supposed to mask off the tags, but > there's been noise about having the kernel understand them. >=20 > That said: >=20 >> +#ifndef gup_fixup_start_addr >> +#define gup_fixup_start_addr(start) (start) >> +#endif >=20 > I'd rather name this much more specifically (ie make it very much > about "clean up pointer tags") and I'm also not clear on why sparc64 > actually wants this. I thought the sparc64 rules were the same as the > (current) arm64 rules: any addresses passed to the kernel have to be > the non-tagged ones. >=20 > As you say, nothing *else* in the kernel does that address cleanup, > why should get_user_pages_fast() do it? >=20 > David? Khalid? Why does sparc64 actually need this? It looks like the > generic get_user_pages() doesn't do it. >=20 There is another discussion going on about tagged pointers on ARM64 and intersection with sparc64 code. I agree there is a generic need to mask off tags for kernel use now that ARM64 is also looking into supporting memory tagging. The need comes from sparc64 not storing tagged address in VMAs. It is not practical to store tagged addresses in VMAs because manipulation of address tags is done entirely in userspace on sparc64. Userspace is free to change tags on an address range at any time without involving kernel and constantly rotating tags is actually a security feature even. This makes it impractical for kernel to try to keep up with constantly changing tagged addresses in VMAs. Untagged addresses in VMAs means any find_vma() and brethren calls need to be passed an untagged address. On sparc64, my intent was to support address tagging for dynamically allocated data buffers only (malloc, mmap and shm specifically) and not for any generic system calls which limited the scope and amount of untagging needed in the kernel. ARM64 is working to add transparent tagged address support at C library level. Adding tagged addresses to C library requires every possible call into kernel to either handle tagged addresses or untag address at some point. Andrey found out it is not as easy as untagging addresses in functions that search through vma. Callers of find_vma() and others tend to do address arithmetic on the address stored in vma that is returned. This requires a more complex solution than just stripping tags in vma lookup routines. Since untagging addresses is a generic need required for far more than gup, I prefer the way Andrey wrote it - -- Khalid