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=-6.3 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_GIT 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 F27AEC433E2 for ; Mon, 14 Sep 2020 13:29:32 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 96C8E21655 for ; Mon, 14 Sep 2020 13:29:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FJYW5Zpk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 96C8E21655 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 987EF89709; Mon, 14 Sep 2020 13:29:31 +0000 (UTC) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8BD9389709 for ; Mon, 14 Sep 2020 13:29:30 +0000 (UTC) Received: by mail-ed1-x530.google.com with SMTP id g4so17638483edk.0 for ; Mon, 14 Sep 2020 06:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=O337qWgiQtRxWseaQqzKcsApKROYygDiI0vsqDOyWvw=; b=FJYW5Zpkr+69Ontc35YOWyp+mL3+YJfwB6//npnOq0Ga13hSRTyG9rqdWj4+XoSTwl 0uaNEpWiH5ReO87er2LlifBH3NPFWwDgSJtyPPqhcyG9S/rx7NEmE2AK4OmD6az3c7DC ECmjZ+seRByPUAp7C5IfbE7h8FYRsyZttir92Zt789sOyIpU3j3rWB5nvqqs7dr7cMO7 peRappoBTy37hf78g1FzRQmgX/YXKNbYhx8gcXWfsYlOOW3rf6mbLtBBMJyHEnWS3jjd 9WjyGB1FJEwRD3WS9vt6zSYCrduQ5EHUPtPT6cB1Pg5lJ5U61W3Gr9AcU4++WYHupOt9 R9ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=O337qWgiQtRxWseaQqzKcsApKROYygDiI0vsqDOyWvw=; b=JqumAYjH3WVtGyb/RKFAQ1J+Pe+lPM+8s/r6beV22XhqGiAE6ITFB7mlbJtm/jlUsp qfxAQgno4NfGT2REh1EtrJWckLqabg/WPdKTuP9VkliIO5asVziklvs4MMI2jIRK7ma5 wo4AFekPO0Ra3Hx2AGjevvcTrRiXaR7ciiJnzKnnz4JyjlKWPO2oqQA11ByilKSJ9xgY pvbagqW5jyFP4AyqCuaoHoAKoHzOe5TJYMgiH063QZLV2Hcp/CyZKOeu9FEI5ed/x/w3 kzMYVkDUbG6ORVDZF+VCvtO8k2bfsOLTZtpVyyFirAAylOa7yIM+UBTjg/BTa92bh3QE aHJg== X-Gm-Message-State: AOAM532UMdH0/bY0L80E/xoN7WzAlm8+XQltcJ6lBcx8psBUI52InRKl LMxG+dIjzAFqDUHRF7LX6e8= X-Google-Smtp-Source: ABdhPJwJsiXZY3KpcwY1vzYkVg2ohf4EGDVpkoGXaNUtWvR8WeUIIoXfyp3ei6G37Iy9uvNZbC5ExA== X-Received: by 2002:aa7:d78f:: with SMTP id s15mr16965480edq.322.1600090169251; Mon, 14 Sep 2020 06:29:29 -0700 (PDT) Received: from abel.fritz.box ([2a02:908:1252:fb60:6179:d701:8021:da3d]) by smtp.gmail.com with ESMTPSA id d6sm9575625edm.31.2020.09.14.06.29.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Sep 2020 06:29:28 -0700 (PDT) From: "=?UTF-8?q?Christian=20K=C3=B6nig?=" X-Google-Original-From: =?UTF-8?q?Christian=20K=C3=B6nig?= To: akpm@linux-foundation.org Subject: Changing vma->vm_file in dma_buf_mmap() Date: Mon, 14 Sep 2020 15:29:18 +0200 Message-Id: <20200914132920.59183-1-christian.koenig@amd.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, linux-media@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Andrew, I'm the new DMA-buf maintainer and Daniel and others came up with patches extending the use of the dma_buf_mmap() function. Now this function is doing something a bit odd by changing the vma->vm_file while installing a VMA in the mmap() system call 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. In other words user space calls mmap() on one file descriptor, but get a different one mapped into your virtual address space. My question is now: Is that legal or can you think of something which breaks here? If it's not legal we should probably block any new users of the dma_buf_mmap() function and consider what should happen with the two existing ones. If that is legal I would like to document this by adding a new vma_set_file() function which does the necessary reference count dance. Thanks in advance, Christian. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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=-6.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT 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 03C78C2BC11 for ; Mon, 14 Sep 2020 13:36:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 96131208B3 for ; Mon, 14 Sep 2020 13:36:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FJYW5Zpk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726758AbgINNgJ (ORCPT ); Mon, 14 Sep 2020 09:36:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726721AbgINN3z (ORCPT ); Mon, 14 Sep 2020 09:29:55 -0400 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80183C06178A; Mon, 14 Sep 2020 06:29:31 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id l17so17571861edq.12; Mon, 14 Sep 2020 06:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=O337qWgiQtRxWseaQqzKcsApKROYygDiI0vsqDOyWvw=; b=FJYW5Zpkr+69Ontc35YOWyp+mL3+YJfwB6//npnOq0Ga13hSRTyG9rqdWj4+XoSTwl 0uaNEpWiH5ReO87er2LlifBH3NPFWwDgSJtyPPqhcyG9S/rx7NEmE2AK4OmD6az3c7DC ECmjZ+seRByPUAp7C5IfbE7h8FYRsyZttir92Zt789sOyIpU3j3rWB5nvqqs7dr7cMO7 peRappoBTy37hf78g1FzRQmgX/YXKNbYhx8gcXWfsYlOOW3rf6mbLtBBMJyHEnWS3jjd 9WjyGB1FJEwRD3WS9vt6zSYCrduQ5EHUPtPT6cB1Pg5lJ5U61W3Gr9AcU4++WYHupOt9 R9ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=O337qWgiQtRxWseaQqzKcsApKROYygDiI0vsqDOyWvw=; b=pzr0fQSV1n5q4KVvrjYOi4nMoGwueCxrrxmDHYTQAyJMhLKyja6lXnMovw9aLZqGcl BBeNMH9fAg6Cuzlzj/J5/zjgTaZgHp0umql6CLM3jioTkdwbjctai41Msa8OXB+t8dSy M7fa6JouxMeGo3v9okgTsI+yL8halUFR+gSHs7PWE2GcuVktdLaVqRDBS1l1kiVMtXBs svt+PhQMzRKG8VNIjxYTMt+AHnpu1PUAymjXwLAYDw72+qEpT861PpPbgRQcyqM0Fshi +eYhOAv4JJAnFFkG0dU8eDbF8vPWyOMwoMF+fiQqPKbuvxllCmeg/eo3skZjwVWpA5Q7 C7aA== X-Gm-Message-State: AOAM531vWl8GzaYsfC0IQxzGeOWPmPno6nVU1UgwArHQMSX9bLGL8zxO thKY6mteFRkLNf5KQFQ3UUQ= X-Google-Smtp-Source: ABdhPJwJsiXZY3KpcwY1vzYkVg2ohf4EGDVpkoGXaNUtWvR8WeUIIoXfyp3ei6G37Iy9uvNZbC5ExA== X-Received: by 2002:aa7:d78f:: with SMTP id s15mr16965480edq.322.1600090169251; Mon, 14 Sep 2020 06:29:29 -0700 (PDT) Received: from abel.fritz.box ([2a02:908:1252:fb60:6179:d701:8021:da3d]) by smtp.gmail.com with ESMTPSA id d6sm9575625edm.31.2020.09.14.06.29.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Sep 2020 06:29:28 -0700 (PDT) From: "=?UTF-8?q?Christian=20K=C3=B6nig?=" X-Google-Original-From: =?UTF-8?q?Christian=20K=C3=B6nig?= To: akpm@linux-foundation.org Cc: 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 Subject: Changing vma->vm_file in dma_buf_mmap() Date: Mon, 14 Sep 2020 15:29:18 +0200 Message-Id: <20200914132920.59183-1-christian.koenig@amd.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi Andrew, I'm the new DMA-buf maintainer and Daniel and others came up with patches extending the use of the dma_buf_mmap() function. Now this function is doing something a bit odd by changing the vma->vm_file while installing a VMA in the mmap() system call 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. In other words user space calls mmap() on one file descriptor, but get a different one mapped into your virtual address space. My question is now: Is that legal or can you think of something which breaks here? If it's not legal we should probably block any new users of the dma_buf_mmap() function and consider what should happen with the two existing ones. If that is legal I would like to document this by adding a new vma_set_file() function which does the necessary reference count dance. Thanks in advance, Christian.