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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,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 EF49FC2D0A3 for ; Wed, 4 Nov 2020 08:44:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 65511208C7 for ; Wed, 4 Nov 2020 08:44:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="SO6a9eIH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 65511208C7 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 AC2166B006E; Wed, 4 Nov 2020 03:44:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A72106B0070; Wed, 4 Nov 2020 03:44:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 961276B0071; Wed, 4 Nov 2020 03:44:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id 66DAB6B006E for ; Wed, 4 Nov 2020 03:44:17 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0DC49181AC9CB for ; Wed, 4 Nov 2020 08:44:17 +0000 (UTC) X-FDA: 77446098954.13.sky62_0a135c0272bf Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id E631B18140B69 for ; Wed, 4 Nov 2020 08:44:16 +0000 (UTC) X-HE-Tag: sky62_0a135c0272bf X-Filterd-Recvd-Size: 5469 Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Wed, 4 Nov 2020 08:44:16 +0000 (UTC) Received: by mail-oi1-f195.google.com with SMTP id m143so12071721oig.7 for ; Wed, 04 Nov 2020 00:44:15 -0800 (PST) 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=ycqoIkcF9lPtiJBVMgjq7zwCX8Gyu6JCtVXT12jKTV8=; b=SO6a9eIH6r+EzFThZ6MTARjwHEtx6LFHOpOvFgwKmnw7LjZXHcgycyhZfUmdSwXoni 9VPCbgc6ODqmZSPJVN4eXwn3IqpRr3uXKNjrMKGfBOBHLutZLHhso+mS3OiPqxM7Q6/l K5a5NNqZWoxju2yJSN+OURI61y0XID3dk0Roo= 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=ycqoIkcF9lPtiJBVMgjq7zwCX8Gyu6JCtVXT12jKTV8=; b=kJzMRNhd541tXVAaJ8D2Cy4wQ9LwVcGUDu/cNvh2HKP4+R10rzw/qjiFWo/dcvfZU4 KJ/2CsGDDP1e6sFRRpATDgG4Fe3l/kNIOoEWJ/+cYMcIdxZxhC8Davx8S+/1WAkIgqmK jZwylR/oIENU2S0tXuguQeKV5d0z2DN3OHStotEz8a6AV0hMagX2bvMIbh+5CDWM1LrW RiVLHVNgKimjI30NCsRp7MKMr/u2XxEJxNhjm8RGz02NpvpFHN7AaI0/GKNv7X/gC4gU LRjys9Bh9YczH/3sGIdJwCYHyVgCt6q8oAvIT7bxFV9npk3R6tCWpIEd8/vrxRAD4qaV MwhA== X-Gm-Message-State: AOAM530PPhptMTI3uheTKkdvpRla9xRP0Smx+si8YriBdAXYUZVpgpwU muDj8mohySkRY377jWCEtr3y6XfjoVuH4mNW/wguOw== X-Google-Smtp-Source: ABdhPJzFeuCQlV5NJZ+3HUxdvXgtCAFGX/0rEF7qnn1uI6qUI3Z5/MsHqFAcH2CxUPAQE20CBPAAF7SeJ5phPHzYaRc= X-Received: by 2002:aca:b141:: with SMTP id a62mr1813813oif.101.1604479455139; Wed, 04 Nov 2020 00:44:15 -0800 (PST) MIME-Version: 1.0 References: <20201030100815.2269-12-daniel.vetter@ffwll.ch> <20201103212840.GA266427@bjorn-Precision-5520> In-Reply-To: From: Daniel Vetter Date: Wed, 4 Nov 2020 09:44:04 +0100 Message-ID: Subject: Re: [PATCH v5 11/15] PCI: Obey iomem restrictions for procfs mmap To: Dan Williams Cc: Bjorn Helgaas , DRI Development , LKML , KVM list , Linux MM , Linux ARM , linux-samsung-soc , "Linux-media@vger.kernel.org" , 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 Tue, Nov 3, 2020 at 11:09 PM Dan Williams wrote: > On Tue, Nov 3, 2020 at 1:28 PM Bjorn Helgaas wrote: > > On Fri, Oct 30, 2020 at 11:08:11AM +0100, Daniel Vetter wrote: > > > There's three ways to access PCI BARs from userspace: /dev/mem, sysfs > > > files, and the old proc interface. Two check against > > > iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM, > > > this starts to matter, since we don't want random userspace having > > > access to PCI BARs while a driver is loaded and using it. > > > > > > Fix this by adding the same iomem_is_exclusive() check we already have > > > on the sysfs side in pci_mmap_resource(). > > > > > > References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges") > > > Signed-off-by: Daniel Vetter > > > > This is OK with me but it looks like IORESOURCE_EXCLUSIVE is currently > > only used in a few places: > > > > e1000_probe() calls pci_request_selected_regions_exclusive(), > > ne_pci_probe() calls pci_request_regions_exclusive(), > > vmbus_allocate_mmio() calls request_mem_region_exclusive() > > > > which raises the question of whether it's worth keeping > > IORESOURCE_EXCLUSIVE at all. I'm totally fine with removing it > > completely. > > Now that CONFIG_IO_STRICT_DEVMEM upgrades IORESOURCE_BUSY to > IORESOURCE_EXCLUSIVE semantics the latter has lost its meaning so I'd > be in favor of removing it as well. Still has some value since it enforces exclusive access even if the config isn't enabled, and iirc e1000 had some fun with userspace tools clobbering the firmware and bricking the chip. Another thing I kinda wondered, since pci maintainer is here: At least in drivers/gpu I see very few drivers explicitly requestion regions (this might be a historical artifact due to the shadow attach stuff before we had real modesetting drivers). And pci core doesn't do that either, even when a driver is bound. Is this intentional, or should/could we do better? Since drivers work happily without reserving regions I don't think "the drivers need to remember to do this" will ever really work out well. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch