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.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 75B5EC47420 for ; Wed, 7 Oct 2020 19:47:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6F0D6206F4 for ; Wed, 7 Oct 2020 19:47:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="HqHL85ae" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F0D6206F4 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 9AF816B006E; Wed, 7 Oct 2020 15:47:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 960396B0070; Wed, 7 Oct 2020 15:47:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84EC06B0071; Wed, 7 Oct 2020 15:47:51 -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 55A806B006E for ; Wed, 7 Oct 2020 15:47:51 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E36B6180AD806 for ; Wed, 7 Oct 2020 19:47:50 +0000 (UTC) X-FDA: 77346164700.28.juice98_2b0c8a8271d2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id BE50E6C05 for ; Wed, 7 Oct 2020 19:47:50 +0000 (UTC) X-HE-Tag: juice98_2b0c8a8271d2 X-Filterd-Recvd-Size: 5448 Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Wed, 7 Oct 2020 19:47:50 +0000 (UTC) Received: by mail-oi1-f195.google.com with SMTP id 16so3727583oix.9 for ; Wed, 07 Oct 2020 12:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=orhfCBuFEmd+KVAmHbcaixIkjSSik8aIdF2Y5AlSlTI=; b=HqHL85aeU7x4vZRr8aFR2YVRrwspH04y26fUbXHdW1zHn9JiRP4t6c+95tolblKSFE g6rmEte7OQz0vHT+Gxy0F+wmZQx2vj40nuDXq6VEJEgecoLqF0as8JHJF/ZRBUJmFjHz fkLaTYyh9AGF6bz08/AxSynt04XwHMSoqg8zg= 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=orhfCBuFEmd+KVAmHbcaixIkjSSik8aIdF2Y5AlSlTI=; b=QhjItge6ne5yFAw7IGf/pxTE9nODC7ed+FLgT1LBRStM3KFD7rub2rYnJYIpnOqfJO 8KI+dd3KfcwZacQyJf2Spu7KEFSZUh+fvgnp2EKwT2w9DZXCyzEjWECGGbEOxwzbP1m/ Qv56yXsIp0kPTDTivsJEdWY0tosRtF/DqkwgzjkUXRB40x7BPLXwCRcUQh2/A5cKMESN TLQgSa6ZU+pje4I7pC8Z1jTEfuFzTcVBrU/8XfMjAX84PjNTDjW1SDPflZ0EQrMksjWi rFmdPxjB//GjirJ1rkuWWtlX+X8PspWlSaWseGksEUaGdryV+9M8aWIiQH/DAXYT2Zwp S2Xw== X-Gm-Message-State: AOAM533CA2Fu6BGFs3d+c0myUnhFxnxNmMk1IgqDYiJz8lrxYEYUlwJ7 wl3W3mllR0+kMd3+xRPHV8DhgnG4BbYHoG5do+bH+A== X-Google-Smtp-Source: ABdhPJxToTx3ndOy1U0dVrBcYAKX9wm3X1TZHa+mGhrb1Py/rD32WJ5mouUCMFv7wj7Vm8hLjOzC1v6C7W/A3Mayy3I= X-Received: by 2002:aca:6083:: with SMTP id u125mr2978051oib.14.1602100069344; Wed, 07 Oct 2020 12:47:49 -0700 (PDT) MIME-Version: 1.0 References: <20201007164426.1812530-1-daniel.vetter@ffwll.ch> <20201007164426.1812530-11-daniel.vetter@ffwll.ch> In-Reply-To: From: Daniel Vetter Date: Wed, 7 Oct 2020 21:47:37 +0200 Message-ID: Subject: Re: [PATCH 10/13] PCI: revoke mappings like devmem To: Dan Williams Cc: DRI Development , LKML , KVM list , Linux MM , Linux ARM , linux-samsung-soc , "Linux-media@vger.kernel.org" , linux-s390 , Daniel Vetter , Jason Gunthorpe , Kees Cook , Andrew Morton , John Hubbard , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Bjorn Helgaas , Linux PCI Content-Type: text/plain; charset="UTF-8" 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 Wed, Oct 7, 2020 at 9:33 PM Dan Williams wrote: > > On Wed, Oct 7, 2020 at 11:11 AM Daniel Vetter wrote: > > > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims > > the region") /dev/kmem zaps ptes when the kernel requests exclusive > > acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is > > the default for all driver uses. > > > > Except there's two more ways to access pci bars: sysfs and proc mmap > > support. Let's plug that hole. > > Ooh, yes, lets. > > > For revoke_devmem() to work we need to link our vma into the same > > address_space, with consistent vma->vm_pgoff. ->pgoff is already > > adjusted, because that's how (io_)remap_pfn_range works, but for the > > mapping we need to adjust vma->vm_file->f_mapping. Usually that's done > > at ->open time, but that's a bit tricky here with all the entry points > > and arch code. So instead create a fake file and adjust vma->vm_file. > > I don't think you want to share the devmem inode for this, this should > be based off the sysfs inode which I believe there is already only one > instance per resource. In contrast /dev/mem can have multiple inodes > because anyone can just mknod a new character device file, the same > problem does not exist for sysfs. But then I need to find the right one, plus I also need to find the right one for the procfs side. That gets messy, and I already have no idea how to really test this. Shared address_space is the same trick we're using in drm (where we have multiple things all pointing to the same underlying resources, through different files), and it gets the job done. So that's why I figured the shared address_space is the cleaner solution since then unmap_mapping_range takes care of iterating over all vma for us. I guess I could reimplement that logic with our own locking and everything in revoke_devmem, but feels a bit silly. But it would also solve the problem of having mutliple different mknod of /dev/kmem with different address_space behind them. Also because of how remap_pfn_range works, all these vma do use the same pgoff already anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch