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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23882D75BA3 for ; Thu, 21 Nov 2024 03:37:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3BA546B007B; Wed, 20 Nov 2024 22:37:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 369A76B0083; Wed, 20 Nov 2024 22:37:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2587B6B0085; Wed, 20 Nov 2024 22:37:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 070B96B007B for ; Wed, 20 Nov 2024 22:37:29 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9146C1C7DD9 for ; Thu, 21 Nov 2024 03:37:28 +0000 (UTC) X-FDA: 82808689782.08.347EE3D Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf08.hostedemail.com (Postfix) with ESMTP id 365EC160003 for ; Thu, 21 Nov 2024 03:36:52 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QVpv6bUN; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of kbusch@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=kbusch@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732160179; a=rsa-sha256; cv=none; b=2x2KhEiV1g4u+KSbh2hUMULPO+cB53pEaGXfLB2wW307bjuyOna7HXlFweV+I2Cnuoys1m vQehBNRaZGMQPmSTsWAlCdrzg7ieHA68eFDnBlIdIS4oLOmRgMchhBMUdTG4wAJswQDMT9 DAgLFIQoPNfMQSfcObYOvMoKK6F00QE= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QVpv6bUN; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of kbusch@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=kbusch@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732160179; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=dgnH8zbI3RWMuAyuSr0roKUlfFDIJ10BCcxDXOZ/p2A=; b=LGtX7LhtjNqNOdEHE79q0nKOuQK7KGjEAmBEACKOxCQOxnBqtrweXsFtQt4pR5hQykHJyh TheK6pbpbHm3MIc5Y19yicZ9LLEMMKW72aGsE4oDnHlAlejwGbnPTd93taRzlg5bvw62lc 7vBEILDKU5ntbilPEEYC0WHRhqFuwGQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id D7C42A41FF4; Thu, 21 Nov 2024 03:35:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7413FC4CECD; Thu, 21 Nov 2024 03:37:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732160245; bh=3UP2eHaDWDrJPiKnzRnbJl7JGs1fZg4KYMdG7Ofx+cA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QVpv6bUNY4qYtP9yhhbnckfD6mzXease6np9KXJhVUPOnNVdlCXNAOeYSdJJXswRD wPZx8UzBsQAaBbIZbIq0ZMfFFcRA0/Kvj2ezhYAS8KLMZaHHHKM4/VMWnkkfljYvon HcjpK7/1vajS2QvUwLELYTkHnSLuF1HR6XyBxoQJ1WyyVBfmZQDqkcLWxmMnwfH+86 RC5bohq/nHs/iJYIDnIyBLnQEKTy0fKMgUlhUCzc7sOzCqquOJBuHbtjluz6l3Lrba K/pLV0nAHBFb75XpEYacCSyfiC5cVCLgFsJP00OLB41vP3G0EA12xezNFwFdpTx7qN d+GF25WnOusXQ== Date: Wed, 20 Nov 2024 20:37:23 -0700 From: Keith Busch To: Brian Johannesmeyer Cc: Christoph Hellwig , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, Raphael Isemann , Cristiano Giuffrida , Herbert Bos , Greg KH Subject: Re: [RFC v2 0/2] dmapool: Mitigate device-controllable mem. corruption Message-ID: References: <20241119205529.3871048-1-bjohannesmeyer@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 365EC160003 X-Rspamd-Server: rspam01 X-Stat-Signature: u73ta3dx1b1c3zzox6epu9c396s9wf5b X-HE-Tag: 1732160212-847218 X-HE-Meta: U2FsdGVkX18YVT1866MPbCYcI2uWgLRb7XpgOcTfTKIyaJRv2XXQpzh9G+hhmxXSB5JCZWXCP9JVYDILSB51+QDmUG/8P2F2pwtEyOj3/IxU5camG+zqMGXXc9Jly4hhHLcnMH+QdlPUUfz4hgyXgDrdQXI/FreuMdtRiEsKIDNsVSjv5eXPrK1y2a+5JYJzZhkRfjK+Aav3GuZa+XIRyUgvE+ltQGGxF+gN1jb19xhrzBV9LZigIJ4DgySZR73bRdm6rWBpEqceBE8h26i8uX28h9LuUUFLsWg2xXeiE3j9kFjnEUTkPlLRwZWuXLXKKy6WF7Nz2jRVspwx7T5NVFsRSTS7KI/IascFmCHcBHuuVoL6a+GAmDFJYTs5JFOfqhCBgLxDT5pXkp+G9gwdR2ms0SnL1edEhSsxjwQKEpvaLUj4j1LmGG7vqEReuAjJmC4R6dfRBts32SgB4+KnjeqchNQ6AMDPby0S0JpzI78Bq6vy5vF7JFVK/8dC3y7e4wgszqFHBaWcH43jfhoePa4vNJhGbMEd+1YCIUZ+iNdgbdpv7WfSU/IEKdr8YgEppkVuSyDHAaKBF33Vsx9Z39nFu0KKoZzrshkCgcYBO1chKhg4BGPqFN1h4RW826OOOWBwVODqInkpDbIJz9rkRGKM89iBxLtC0L9UzvC5wYzt0JQODxmiwCuEh0m/UoZJwOrggjlZlh0GHrL/e7mUGksjYE7UG4PBRLsC/4l6dOZx8puYpiaWU6BPORXZ369I/oHNiCMyhPac/dSMpeevMk+e+gArJ5oGJZFjGkjbdbITn7L68/3CeLQBDflW1Nt8c9OqohU+Be+GyVvePZWjJEaSJO8wIvzh/THhh0IkfRk3QjzUF4y0dfGUw7QkgPGGW4Jykb2utheBXXjzTtqB4xoU5+mS4au6wCERZMuqzPgSIZq0pA3puzw0PgeUyIoIYTYFwSKDw16pN4aZtp/ qX6NT5En pKGV3b4p5qMZGb4zqe+kHyZBewuOeCXsGV26DVyQR2d6XsKSb91Ibo80YLCyr1HRxGga+faUqOdeYk3bshQMB4z6fPHKAOu6benQFBGBld+/i+Bu3cOzqglUbKSnpp+t0gN+2gMlaDLV5gzdBtrF1QcZO8nyTn8QaBW80j5jCnH7WuGied+KVH9LJII0wx0p5egQZa0Kqo5ZvCbUV0f3Pq/U2q03O5uJcjqPnJrUYMKyGT0MymOTiQXRnZSlXJs4nfBAz 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: List-Subscribe: List-Unsubscribe: On Wed, Nov 20, 2024 at 02:58:54PM -0700, Brian Johannesmeyer wrote: > These results are consistent across multiple runs. It seems that with > DMAPOOL_DEBUG disabled, the patches introduce a significant > performance hit. Let me know if you have any suggestions or further > tests you'd like me to run. That's what I was afraid of. I was working on the dma pool because it showed significant lock contention on the pool for storage heavy workloads, so cutting down the critical section was priority. With the current kernel, the dma pool doesn't even register on the profiles anymore, so it'd be great to keep it that way. The idea for embedding the links in freed blocks was assuming a driver wouldn't ask the kernel to free a dma block if the mapped device was still using it. Untrustworthy hardware is why we can't have nice things... Here's my quick thoughts at this late hour, though I might have something else tomorrow. If the links are external to the dma addr being freed, then I think you need to change the entire alloc/free API to replace the dma_addr_t handle with a new type, like a tuple of { dma_addr_t, priv_list_link } That should make it possible to preserve the low constant time to alloc and free in the critical section, which I think is a good thing to have. I found 170 uses of dma_pool_alloc, and 360 dma_pool_free in the kernel, so changing the API is no small task. :(