From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pdx-out-012.esa.us-west-2.outbound.mail-perimeter.amazon.com (pdx-out-012.esa.us-west-2.outbound.mail-perimeter.amazon.com [35.162.73.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F0082FE04E for ; Thu, 14 May 2026 15:54:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=35.162.73.231 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778774053; cv=none; b=FAgWLEv2JZ+b1TuEJgLM2dNHjE7iTR/JPuGQ/LU6ilQVM9y8v2kvIy4hO1AcnjIdH5g79TkzH413vT8hsC3134x1UDc3hufGWneM7jWiJBjWlWTeUsgX/0+nvqsa7kTrdeNtxY/euotWi1aXPILJaazNgNSHjJZaq9q57LJfDso= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778774053; c=relaxed/simple; bh=ABWor0hSw9ObAB//O09ZQ4QmOM7hH264llT7XT3yaLc=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=guJqDGcXLnNIK19u6vtfRX49/UhI8i6BA9G+G/T/UMjxaUj67zu1BHHa7eAJbDsRTqErKpJyL4njjU644ePsChMAggYgu9jjCX3N/iRUXnZQbQqLpOU6E61qBHr1i+S7o+Hxh9xVe0FdxV4WfKlxbnu8jRr+Hgb4V1cUiXaolgQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com; spf=pass smtp.mailfrom=amazon.com; dkim=pass (2048-bit key) header.d=amazon.com header.i=@amazon.com header.b=WM8mYzWB; arc=none smtp.client-ip=35.162.73.231 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=amazon.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=amazon.com header.i=@amazon.com header.b="WM8mYzWB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazoncorp2; t=1778774052; x=1810310052; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ABWor0hSw9ObAB//O09ZQ4QmOM7hH264llT7XT3yaLc=; b=WM8mYzWBdXFpIR/yB6qdFNBl5cshSOSHplb8uDxZJO0tOVzOzuAi/at5 agVB2ZXWIIQvmeD1Bl3kUAaIzJJsfCMY6ZOSZV3YwctQtKPkjA6xfORNF TgqcY8ymbdRKclz7GRyAaR3HltLqstEz8PmbX6ds8KztZv98J+BuBEqNm vLLqtvpwlcNAGw7ixBim0c+KzXn5c07MzU60c9E3yaZPj3TflanMmGLgz Zbr31xsUKkiL5H4nYGBcist5ltgdwdzVSr12TcJGvJwMKe8hUIulQY0Sl 3hgZCOphSzDptDnqrAhdfwpmPxxTCvSbA/FK4eU56lWDZunVPReaL3gMQ g==; X-CSE-ConnectionGUID: bKH4obfCQRe3YYOAXpuL/w== X-CSE-MsgGUID: utQZSqdzRziB3kMozNhOXg== X-IronPort-AV: E=Sophos;i="6.23,234,1770595200"; d="scan'208";a="19453559" Received: from ip-10-5-0-115.us-west-2.compute.internal (HELO smtpout.naws.us-west-2.prod.farcaster.email.amazon.dev) ([10.5.0.115]) by internal-pdx-out-012.esa.us-west-2.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 May 2026 15:54:12 +0000 Received: from EX19MTAUWC001.ant.amazon.com [205.251.233.105:25939] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.6.235:2525] with esmtp (Farcaster) id f63615bd-221c-45ea-8047-9311c65d1092; Thu, 14 May 2026 15:54:11 +0000 (UTC) X-Farcaster-Flow-ID: f63615bd-221c-45ea-8047-9311c65d1092 Received: from EX19D001UWA001.ant.amazon.com (10.13.138.214) by EX19MTAUWC001.ant.amazon.com (10.250.64.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.37; Thu, 14 May 2026 15:54:11 +0000 Received: from dev-dsk-ravib-2a-f2262d1b.us-west-2.amazon.com (10.169.187.85) by EX19D001UWA001.ant.amazon.com (10.13.138.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.37; Thu, 14 May 2026 15:54:11 +0000 From: Ravi Kumar Bandi To: CC: , , , , , , Subject: Re: [PATCH] resource: export iomem_get_mapping() for loadable modules Date: Thu, 14 May 2026 15:54:05 +0000 Message-ID: <20260514155405.7998-1-ravib@amazon.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <6a04c6ba958b2_107b100f9@djbw-dev.notmuch> References: <6a04c6ba958b2_107b100f9@djbw-dev.notmuch> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: EX19D033UWC001.ant.amazon.com (10.13.139.218) To EX19D001UWA001.ant.amazon.com (10.13.138.214) On 5/13/26, Dan Williams (nvidia) wrote: > I took a look and there are some problems here. > > My first thought was, "why does the endpoint driver need to do this? The > PCI core device removal should be responsible for zapping mappings." > > 2 things defeat this: > > 1/ for sysfs bar mappings, the unmap_mapping_range() in > kernfs_drain_open_files() misses mappings established against > the shared iomem_get_mapping(). > > 2/ procfs access to BAR space has never unmapped on device removal > > The practical implication of this is that userspace mappings of BARs can > survive past device removal. As for mitigations, with IO_STRICT_DEVMEM > the kernel will zap them before use, with LOCKDOWN the mappings can not > be established, and CAP_SYS_RAWIO is required (for procfs) to create > these mappings. Hello Dan, thank you for the review and guidance. > > I recall that Sima added support for ioport mmap revoke support in: > > 636b21b50152 PCI: Revoke mappings like devmem > > ...but given revoke_iomem() only evacuates at request_mem_region() time, > I do not see how that ever worked. > > We could do something like the following for kernfs regression in the > near term, or just proceed with making revoke_iomem() something that the > PCI core does unconditionally by physical address on device removal. > That would also fix the procfs gap. > > Ravi, I think your time is best spent getting the PCI core to handle the > unmap on device removal. Agree. Thank you for the pointers, I will work on it and get back here. > > -- >8 -- > Subject: resource: Fix PCI/sysfs mmap revocation vs CONFIG_IO_STRICT_DEVMEM=n > > From: Dan Williams