Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp7545881yba; Thu, 2 May 2019 11:46:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqx+CJF7dpPAVzp7ol39rsyHBy+k+NuAKOJqWEqS4bYFD4EBLv6T8Dwxep6Eo1Nbe+CHIacv X-Received: by 2002:a63:8949:: with SMTP id v70mr5702551pgd.196.1556822766599; Thu, 02 May 2019 11:46:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556822766; cv=none; d=google.com; s=arc-20160816; b=0npHqHNLRrugO9NRZalIGEPST3qVKAZlu9h4aH1wcm5Eqv/HPr63NdTljjObWrQ73k i3vT0xsYKVVU+5vk+YghJpOS9Od6BM3xCUBoiH1AuMhukVb+rjvB+9xbemcC2LlDxEft 0NC1wCoNstF0T4RujsYHlfnoNHF0EVGhLFiqUka9JI99cThQiRXFlqitiM5YU9vXvQi0 DD5tcXKGj6bWV4MGL2zoz00bfMrQoe4zTV4cTCH8Yq5Mvn4FHhhk6GHOQO4kqwE3ekGi KHi6B0pQmRkiRPQ6bmsMPOx7p8l9KTBBWmoy5WtLFrN0nKigURSvSOkTYfSndiYz1frc c/aA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=0H6/1V6/5CIKh3CDtEYPw4qJMt0j8mXo9dQuEOmaJ2c=; b=qV30GfQnvla7Y8jBZeRn0FKciVvghqZpjJO4hcM1j3z2+siH9nCCCUYCVfQ9QSt6XK noKuZOi+qzNI2ntUNz3gbiRzn/G3pqC+9IfzT6qJTb8cz5fcVpXt9lwiv7Sr9QzlH5o8 5eYe/KhmEku/Yx5cC7StDo2UPjJM/FHLyO0WgGU1FIb25Sw2DUndtfVZ2jDpeVW236d5 CKe6251l2eGV71W/Uj5my+c8wXyCX7dSDXAjBcSb+Gaup7Ysb+Yq3kwrpDHJJjfxXefG nbRBkORoP/lS3+DcVqqJspi58iobegvVHj2cdTLhwQ672fSNq9L24X9as03KyQTTOpVv X3zQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=TAjDKfRe; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w10si24752584pgr.296.2019.05.02.11.45.50; Thu, 02 May 2019 11:46:06 -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=@ziepe.ca header.s=google header.b=TAjDKfRe; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726457AbfEBSop (ORCPT + 99 others); Thu, 2 May 2019 14:44:45 -0400 Received: from mail-yw1-f68.google.com ([209.85.161.68]:34353 "EHLO mail-yw1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726196AbfEBSoo (ORCPT ); Thu, 2 May 2019 14:44:44 -0400 Received: by mail-yw1-f68.google.com with SMTP id u14so2373038ywe.1 for ; Thu, 02 May 2019 11:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=0H6/1V6/5CIKh3CDtEYPw4qJMt0j8mXo9dQuEOmaJ2c=; b=TAjDKfRewk/UKamdlBYp4Z/f6fr9mzmhTBqPKn6Tso2lr/AkBQ1LMwAK9XIDmPfqWH 1X2g+ZiCkYEJEIfn+6n2PJc1Ev9G5K81J+GgEo5MfNluS5utNruV2aiJWOsWhO1L39V3 Z6C+J9uqiqXPYgQ6dcQSGANxw+xbHRVZAHWyN5hgFksgs/XhUgIKGl/0h+zrDIy2eofo aoMe+6WRmr7JILlqWxy3H4DaUeYvmUJdygIwom0nYWR8nN82LMnNt4srD1UZaJjPLcot OJpUgaV5+1lK6hPsIBFneSFAOj6A3kBGy7IE9y3T5wB9bI5Hesqt1uBVI3nJujocribj yDpA== 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:user-agent; bh=0H6/1V6/5CIKh3CDtEYPw4qJMt0j8mXo9dQuEOmaJ2c=; b=QjU8eMwQaeDzSuyK99CEPr0HUiItYlxubdGGims0g/8UieczN8O/jsnOjwNQPNxGUQ LEh1X/Wog/gVYoQHStn15QHLPQJi4DkFewoiqkjFF21q40NXz8WO6G1jrYP7mEdsqLgW HXl0j6Xlw8pEaUM1D/4kQMxsBHB5xsvAGkrN/2vMsIZGGWybZclLpC7YR1DI0ViG2gSa aZ+UEm0wvHFsmv40m9xfYNz+3oT+sLC+VWo/R5hebaBq9su9Sc2r8yhHOfNBt0lDVDfP j+Gbbls2ikmQTl2Des/h2EkNQ8xw59bxedL9kErhBCWBrWOAkLmLyLutO46Rh9ze7fUM wfdg== X-Gm-Message-State: APjAAAUM2zRENrGTEYO+0eOFa6bYCwJVFKsvfQCvjW60wTUmo/mq+9FE dqBUAxRQCwMFhnrsSccD2liU8Q== X-Received: by 2002:a25:5d0f:: with SMTP id r15mr4433647ybb.373.1556822683578; Thu, 02 May 2019 11:44:43 -0700 (PDT) Received: from ziepe.ca (adsl-173-228-226-134.prtc.net. [173.228.226.134]) by smtp.gmail.com with ESMTPSA id q204sm16965820ywq.44.2019.05.02.11.44.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 02 May 2019 11:44:42 -0700 (PDT) Received: from jgg by jggl.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1hMGhG-00026A-3l; Thu, 02 May 2019 15:44:42 -0300 Date: Thu, 2 May 2019 15:44:42 -0300 From: Jason Gunthorpe To: Catalin Marinas Cc: Leon Romanovsky , Andrey Konovalov , Will Deacon , Robin Murphy , Kees Cook , Greg Kroah-Hartman , Andrew Morton , Vincenzo Frascino , Eric Dumazet , "David S. Miller" , Yishai Hadas , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Dmitry Vyukov , Kostya Serebryany , Evgeniy Stepanov , Ramana Radhakrishnan , Ruben Ayrapetyan , Luc Van Oostenryck , Dave Martin , Kevin Brodsky , Szabolcs Nagy Subject: Re: [PATCH v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr Message-ID: <20190502184442.GA31165@ziepe.ca> References: <1e2824fd77e8eeb351c6c6246f384d0d89fd2d58.1553093421.git.andreyknvl@google.com> <20190429180915.GZ6705@mtr-leonro.mtl.com> <20190430111625.GD29799@arrakis.emea.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190430111625.GD29799@arrakis.emea.arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 30, 2019 at 12:16:25PM +0100, Catalin Marinas wrote: > > Interesting, the followup question is why mlx4 is only one driver in IB which > > needs such code in umem_mr. I'll take a look on it. > > I don't know. Just using the light heuristics of find_vma() shows some > other places. For example, ib_umem_odp_get() gets the umem->address via > ib_umem_start(). This was previously set in ib_umem_get() as called from > mlx4_get_umem_mr(). Should the above patch have just untagged "start" on > entry? I have a feeling that there needs to be something for this in the odp code.. Presumably mmu notifiers and what not also use untagged pointers? Most likely then the umem should also be storing untagged pointers. This probably becomes problematic because we do want the tag in cases talking about the base VA of the MR.. Jason