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=-7.0 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 6812AC282CE for ; Tue, 4 Jun 2019 13:09:51 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3E1A723EAB for ; Tue, 4 Jun 2019 13:09:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Cj+m20ED"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="Lkz8dpKP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E1A723EAB Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xi2A2jVU5XmwWHwqT6VWzibyXRTVoNf0ksb6ITTeZh8=; b=Cj+m20EDR0ObGq nh1z+fZCd6iIRzZ9UaqhmDBvsJMxyHbZeTd4+9K9ng7fH9ekApZ9HGxcrnE2XidOJuuY5WRcwF9pC aUDuD80ieuMec85hXLPoxwGQTSEg3fm5ngOPS/vylhBhkSPO7+Lm45odKUrWiNxSVzS4Sjv/AMJyM kMSqwe11G7KmeG+dekWvGv445RrgO+NN79QpI13rXwrpAjqw8mQ1IUMwEj/wRx/rUL8lNssHWcpCT WOZYcz8WrbaLOvD/eJNBbo54ZXAj24Q9LLi6J8ex4A32Bt+QtdsDgP411DIgWDH78wzqUzwmLNDyt iYoImo97gjSCzgn3niAw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hY9CE-0007XN-Mn; Tue, 04 Jun 2019 13:09:46 +0000 Received: from mail-pg1-x543.google.com ([2607:f8b0:4864:20::543]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hY9CA-0007VS-R8 for linux-arm-kernel@lists.infradead.org; Tue, 04 Jun 2019 13:09:44 +0000 Received: by mail-pg1-x543.google.com with SMTP id s27so4731899pgl.2 for ; Tue, 04 Jun 2019 06:09:38 -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=zBLpk28DZpa5o94Q/0/LiLBGCkVoEs9cAD1KugSM2WY=; b=Lkz8dpKPRyddE/5l1SxtFW2tJDVJSIsNFYCOD1eigwQMuFNNmYLAz8pfUb/eNChwZF OH2h9RaIuTJvzD4zfwI4In+YKCusdO0C+/wNdpvUvPZXC2iOOrHIqrrS+koi+fxYqD+r iK2Zgy43Tahmq3qaqGtP4n+xMyhj8Yk3JvazolAsNKLfjKj1GXO3dAAQy063Hi2tMAsN GhJY2yKC3BApNCj1AkvEe/6mz6FyJyIhhdR95z/RQ7El5pARzqaaKppkgNvLbKRJzKwz N+Va7sAICkGdL463idSaVxKwCH7V2NZvNaXeQHS+go3oLu7b/Bj32cawMXuwRC+DSWx3 9rBw== 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=zBLpk28DZpa5o94Q/0/LiLBGCkVoEs9cAD1KugSM2WY=; b=GfwL4CfLss/JzTbahMhfscvV1ZRYzB68GjhCCgQS/knwIZNXyfiiYxMllCTgWY1M19 UkEQdRBI6e1EO+YE6WuruguT+A8DAXVas5GWe7D0kKBrigKOMpuHAzIPNW8vTsvT4m1a o3BPLG0LNRYdU+NWHBhH3dtDv82oMH6uQ7chC/p6rIylWFh+iN5emrWsbx2dwALdH9L4 RXgoTEIdynImTUlH1V2Rf0dk70/6BCH3rNitlyNVLSboe6iFbCgUNF2gz6i0f/RJadqi IxL5wZddl/Ln9mvnRCutaxQqSfP/JG/+CESECv5YyHQQtmlPZhW84lo1zrNe6dYUCvaT FH0g== X-Gm-Message-State: APjAAAVrISzEzs7g+7sR0DMLCK0t02zz/885wsdT5FJx3V6DUVDjSdvW ftLseFXLXOGIN3yVSWVDRoTnXhVCTLXMV5SjSROuYA== X-Google-Smtp-Source: APXvYqwE+yY3fi9MHe5pAmjH6ujV7dnKQuJJ2mvTpcdW82/qczftH0mUauffZu6ryTn350uiR7ngmmR4ga1rtqlB5p8= X-Received: by 2002:aa7:8491:: with SMTP id u17mr25575697pfn.93.1559653777333; Tue, 04 Jun 2019 06:09:37 -0700 (PDT) MIME-Version: 1.0 References: <20190603174619.GC11474@ziepe.ca> <20190604122714.GA15385@ziepe.ca> <20190604130207.GD15385@ziepe.ca> In-Reply-To: <20190604130207.GD15385@ziepe.ca> From: Andrey Konovalov Date: Tue, 4 Jun 2019 15:09:26 +0200 Message-ID: Subject: Re: [PATCH v16 12/16] IB, arm64: untag user pointers in ib_uverbs_(re)reg_mr() To: Jason Gunthorpe , Catalin Marinas X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190604_060942_884026_6336F1D7 X-CRM114-Status: GOOD ( 31.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , kvm@vger.kernel.org, Szabolcs Nagy , Will Deacon , dri-devel@lists.freedesktop.org, Linux Memory Management List , Khalid Aziz , "open list:KERNEL SELFTEST FRAMEWORK" , Felix Kuehling , Vincenzo Frascino , Jacob Bramley , Leon Romanovsky , linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org, Christoph Hellwig , Dmitry Vyukov , Dave Martin , Evgeniy Stepanov , linux-media@vger.kernel.org, Kevin Brodsky , Kees Cook , Ruben Ayrapetyan , Ramana Radhakrishnan , Alex Williamson , Mauro Carvalho Chehab , Linux ARM , Kostya Serebryany , Greg Kroah-Hartman , Yishai Hadas , LKML , Jens Wiklander , Lee Smith , Alexander Deucher , Andrew Morton , enh , Robin Murphy , Christian Koenig , Luc Van Oostenryck Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 4, 2019 at 3:02 PM Jason Gunthorpe wrote: > > On Tue, Jun 04, 2019 at 02:45:32PM +0200, Andrey Konovalov wrote: > > On Tue, Jun 4, 2019 at 2:27 PM Jason Gunthorpe wrote: > > > > > > On Tue, Jun 04, 2019 at 02:18:19PM +0200, Andrey Konovalov wrote: > > > > On Mon, Jun 3, 2019 at 7:46 PM Jason Gunthorpe wrote: > > > > > > > > > > On Mon, Jun 03, 2019 at 06:55:14PM +0200, Andrey Konovalov wrote: > > > > > > This patch is a part of a series that extends arm64 kernel ABI to allow to > > > > > > pass tagged user pointers (with the top byte set to something else other > > > > > > than 0x00) as syscall arguments. > > > > > > > > > > > > ib_uverbs_(re)reg_mr() use provided user pointers for vma lookups (through > > > > > > e.g. mlx4_get_umem_mr()), which can only by done with untagged pointers. > > > > > > > > > > > > Untag user pointers in these functions. > > > > > > > > > > > > Signed-off-by: Andrey Konovalov > > > > > > drivers/infiniband/core/uverbs_cmd.c | 4 ++++ > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > diff --git a/drivers/infiniband/core/uverbs_cmd.c b/drivers/infiniband/core/uverbs_cmd.c > > > > > > index 5a3a1780ceea..f88ee733e617 100644 > > > > > > +++ b/drivers/infiniband/core/uverbs_cmd.c > > > > > > @@ -709,6 +709,8 @@ static int ib_uverbs_reg_mr(struct uverbs_attr_bundle *attrs) > > > > > > if (ret) > > > > > > return ret; > > > > > > > > > > > > + cmd.start = untagged_addr(cmd.start); > > > > > > + > > > > > > if ((cmd.start & ~PAGE_MASK) != (cmd.hca_va & ~PAGE_MASK)) > > > > > > return -EINVAL; > > > > > > > > > > I feel like we shouldn't thave to do this here, surely the cmd.start > > > > > should flow unmodified to get_user_pages, and gup should untag it? > > > > > > > > > > ie, this sort of direction for the IB code (this would be a giant > > > > > patch, so I didn't have time to write it all, but I think it is much > > > > > saner): > > > > > > > > Hi Jason, > > > > > > > > ib_uverbs_reg_mr() passes cmd.start to mlx4_get_umem_mr(), which calls > > > > find_vma(), which only accepts untagged addresses. Could you explain > > > > how your patch helps? > > > > > > That mlx4 is just a 'weird duck', it is not the normal flow, and I > > > don't think the core code should be making special consideration for > > > it. > > > > How do you think we should do untagging (or something else) to deal > > with this 'weird duck' case? > > mlx4 should handle it around the call to find_vma like other patches > do, ideally as part of the cast from a void __user * to the unsigned > long that find_vma needs So essentially what we had a few versions ago (https://lkml.org/lkml/2019/4/30/785) plus changing unsigned longs to __user * across all IB code? I think the second part is something that's not related to this series and needs to be done separately. I can move untagging back to mlx4_get_umem_mr() though. Catalin, you've initially asked to to move untagging out of mlx4_get_umem_mr(), do you have any comments on this? > > Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel