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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 17A89C433E2 for ; Wed, 16 Sep 2020 09:54:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5030B22211 for ; Wed, 16 Sep 2020 09:54:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="kLEN0Bss" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5030B22211 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 98A0E6B0003; Wed, 16 Sep 2020 05:54:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 93C706B0037; Wed, 16 Sep 2020 05:54:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 851316B0055; Wed, 16 Sep 2020 05:54:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id 713176B0003 for ; Wed, 16 Sep 2020 05:54:05 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 226F1181AEF1D for ; Wed, 16 Sep 2020 09:54:05 +0000 (UTC) X-FDA: 77268463650.02.bite43_5613a6827119 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id EF2CA10123FB7 for ; Wed, 16 Sep 2020 09:54:04 +0000 (UTC) X-HE-Tag: bite43_5613a6827119 X-Filterd-Recvd-Size: 7538 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Wed, 16 Sep 2020 09:54:04 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id s13so2127283wmh.4 for ; Wed, 16 Sep 2020 02:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=2iYj6uXZfdILOqgogXly8EZQExVDmJHzJxebCj3FO2Y=; b=kLEN0BssrrGNNSneN66oFCjjAadmKcUDJz92qqA1hlRweOfcEvHYpQdfeRRtwkF4EQ dcUsTbuHAmwH/0mnTlAiojEnwfsHgztTx14z7ldzdOZ3sB9zWn6RU/pryOBlEtk4a/OV Z84xyaG+7QYeXaJ7WzDVD282q5e3iYHLjHFlY= 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 :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=2iYj6uXZfdILOqgogXly8EZQExVDmJHzJxebCj3FO2Y=; b=arwQVsvTru896P9HV6VjWtrJXcnzlTk44FllHlAIzV+DABvN3V1ClhuBWuD0vhLjFI hgXS/imJDZ/WxgD5gi5nkaRSTDVCLHUn8/zpVwjs88olnif/jSHZCZfvgrqoqC/Ay3sH q3xs2M9UlFnW12NamR/JIWxsg5Hnoh7dr/NTPy45feIrVl8tftQO6s8PwyaMXNumZyQ8 YaY2XYvnnIUz78/5hVylW5Hx/kqNV3DMPu8EUu6WnTZ7WghZvdARuJdMbawquKOP2WC2 hOKjVtO9yZFhwTQe0VTVgk0MMSJpxuSezP9ouoxoaGu81EaHHXnbvzk7AV1HKN+zpL27 u8ng== X-Gm-Message-State: AOAM533iYGXdRhl/ihrW8n8vBSQuR4OCjFLgBpEVAMHHvlaDLAuKYtMj JaP4FK/6U7vc6QlbwxvArzAcyw== X-Google-Smtp-Source: ABdhPJx8T8vv6SboEWDzt863SflX4VsUCD5E76qf3ZL+BjSfaIFA4+TQRt4D0/rFrg4RphT0bDAcYQ== X-Received: by 2002:a1c:7912:: with SMTP id l18mr3807909wme.124.1600250042604; Wed, 16 Sep 2020 02:54:02 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id i83sm4609049wma.22.2020.09.16.02.54.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2020 02:54:01 -0700 (PDT) Date: Wed, 16 Sep 2020 11:53:59 +0200 From: Daniel Vetter To: christian.koenig@amd.com Cc: Jason Gunthorpe , akpm@linux-foundation.org, sumit.semwal@linaro.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Daniel Vetter Subject: Re: Changing vma->vm_file in dma_buf_mmap() Message-ID: <20200916095359.GD438822@phenom.ffwll.local> Mail-Followup-To: christian.koenig@amd.com, Jason Gunthorpe , akpm@linux-foundation.org, sumit.semwal@linaro.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20200914132920.59183-1-christian.koenig@amd.com> <40cd26ae-b855-4627-5a13-4dcea5d622f6@gmail.com> <20200914140632.GD1221970@ziepe.ca> <9302e4e0-0ff0-8b00-ada1-85feefb49e88@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <9302e4e0-0ff0-8b00-ada1-85feefb49e88@gmail.com> X-Operating-System: Linux phenom 5.7.0-1-amd64 X-Rspamd-Queue-Id: EF2CA10123FB7 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 Content-Transfer-Encoding: quoted-printable 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 Mon, Sep 14, 2020 at 08:26:47PM +0200, Christian K=F6nig wrote: > Am 14.09.20 um 16:06 schrieb Jason Gunthorpe: > > On Mon, Sep 14, 2020 at 03:30:47PM +0200, Christian K=F6nig wrote: > > > Am 14.09.20 um 15:29 schrieb Christian K=F6nig: > > > > Hi Andrew, > > > >=20 > > > > I'm the new DMA-buf maintainer and Daniel and others came up with > > > > patches extending the use of the dma_buf_mmap() function. > > > >=20 > > > > Now this function is doing something a bit odd by changing the > > > > vma->vm_file while installing a VMA in the mmap() system call > > It doesn't look obviously safe as mmap_region() has an interesting mi= x > > of file and vma->file > >=20 > > Eg it calls mapping_unmap_writable() using both routes >=20 > Thanks for the hint, going to take a look at that code tomorrow. >=20 > > What about security? Is it OK that some other random file, maybe in > > another process, is being linked to this mmap? >=20 > Good question, I have no idea. That's why I send out this mail. >=20 > > > > The background here is that DMA-buf allows device drivers to > > > > export buffer which are then imported into another device > > > > driver. The mmap() handler of the importing device driver then > > > > find that the pgoff belongs to the exporting device and so > > > > redirects the mmap() call there. > > So the pgoff is some virtualized thing? >=20 > Yes, absolutely. Maybe notch more context. Conceptually the buffer objects we use to manag= e gpu memory are all stand-alone objects, internally refcounted and everything. And if you export them as a dma-buf, then they are indeed stand-alone file descriptors like any other. But within the driver, we generally need thousands of these, and that tends to bring fd exhaustion problems with it. That's why all the private buffer objects which aren't shared with other process or other drivers ar= e handles only valid for a specific fd instance of the drm chardev (each open gets their own namespace), and only for ioctls done on that chardev. And for mmap we assign fake (but unique across all open fd on it) offsets within the overall chardev. Hence all the pgoff mangling and re-mangling. Now for unmap_mapping_range we'd like it to find all such fake offset aliases pointing at the one underlying buffer object: - mmap on the dma-buf fd, at offset 0 - mmap on the drm chardev where the buffer was originally allocated, at s= ome unique offset - mmap on the drm chardev where the buffer was imported, again at some (likely) different unique (for that chardev) offset. So to make unmap_mapping_range work across the entire delegation change we'd actually need to change the vma->vma_file and pgoff twice: - once when forwarding from the importing drm chardev to the dma-buf - once when forwarding from the dma-buf to the exported drm chardev fake offset, which (mostly for historical reasons) is considered the canonical fake offset We can't really do the delegation in userspace because: - the importer might not have access to the exporters drm chardev, it onl= y gets the dma-buf. If we'd give it the underlying drm chardev it could d= o stuff like issue rendering commands, breaking the access model. - the dma-buf fd is only used to establish the sharing, once it's importe= d everywhere it generally gets closed. Userspace could re-export it and then call mmap on that, but feels a bit contrived. - especially on SoC platforms this has already become uapi. It's not a bi= g problem because the drivers that really need unmap_mapping_range to wor= k are the big gpu drivers with discrete vram, where mappings need to be invalidate when moving buffer objects in/out of vram. Hence why we'd like to be able to forward aliasing mappings and adjust th= e file and pgoff, while hopefully everything keeps working. I thought this would work, but Christian noticed it doesn't really. Cheers, Daniel >=20 > Christian. >=20 > >=20 > > Jason >=20 --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch