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 0F599C77B7F for ; Fri, 27 Jun 2025 11:32:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 972626B00B6; Fri, 27 Jun 2025 07:32:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 949DD6B00B7; Fri, 27 Jun 2025 07:32:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85F926B00B8; Fri, 27 Jun 2025 07:32:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 73D6A6B00B6 for ; Fri, 27 Jun 2025 07:32:57 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 48F34C0682 for ; Fri, 27 Jun 2025 11:32:57 +0000 (UTC) X-FDA: 83600968794.06.9E9FCC6 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf29.hostedemail.com (Postfix) with ESMTP id 233C5120009 for ; Fri, 27 Jun 2025 11:32:54 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=YOVzDqxS; spf=pass (imf29.hostedemail.com: domain of ptesarik@suse.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=ptesarik@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751023975; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3VA1K+sSxb+ZA7vsDXvA15WJBHT58z1iBmKqHJX5Tp4=; b=xXTOZzCZSeFp8whCsOG+OfipS6h3DG8K5ezRcRUQGpX6x5iaGqlhoky0gEMw9j45oQMjXY xvhnIfNPLyTXPwinLxnJREagYAMAZpwXr5TnRCXkJP/sbtoswZ3zTA8u1utoF8RQviQH+O xVfCf6VkssVQA2jMD0PlHwrH/iuZp3A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751023975; a=rsa-sha256; cv=none; b=k1Qvx8ouVjadrVdAtRFo9S9rPW6+o1XdVMTdVxLCojOcT8F7X05xilNffylFGmLnFDr5i/ lk3P2mAlUHPX+71KftK32p5byyAcudulIN0dAk0nbGWwr2Fh+szUtlfp7M2mDOsG0rEHb3 HZ/rrVfgqI/hn6v5MPrKrHOYm3TvLCM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=YOVzDqxS; spf=pass (imf29.hostedemail.com: domain of ptesarik@suse.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=ptesarik@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-450ddb35583so2992675e9.1 for ; Fri, 27 Jun 2025 04:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1751023973; x=1751628773; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=3VA1K+sSxb+ZA7vsDXvA15WJBHT58z1iBmKqHJX5Tp4=; b=YOVzDqxSU2W7IqWFHrG8o3w6qVD6+U2KNBrsV7cehTslzVN/bYSNgH8aorV9nHL+aX GgaMS0w8ryfAP1kLqJ3VlsLY7gS7UaeKMcmbt4p7zafWd9ed22mqi0O4TciYcJM/9Dfp RxfOPiBjdMOsbfEUQa9dIjAuRp/pjT50xmQimSjvJ7nZSgijN3u25g1HH7KAKF9AckIZ bcQT9IgkN2fH6I9GnOlNU4wswfDc1YXr4cqVlFzKY+7GsJ8+fnqd8w7U80f78/JC+l4D urmeGfu/7cQasLxMAJxfktgI9uyYxRgDzX7ZgyrO+xkoDm4gcSqmmKVuf42IGjZqrxWk nKng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751023973; x=1751628773; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3VA1K+sSxb+ZA7vsDXvA15WJBHT58z1iBmKqHJX5Tp4=; b=KSjdAcmU4R49O2W93gn9vRoSXewQydJCqG0t8zHD42Sl/AhOkPtHVAqoIiONLbIc2K YPan4FWi19/E1mZir0TXF6009Avq910Y4TazsrYslAvXgAqN7d751ulEYG6k6g2xlMjC wxnfufrM4P9CpKn/QsN7q2L3yYerGmGLdT54Wb/616R3Ne6b5qAIViTCklsCuDuaNoAe 2+xSAPIe+PLGHSRfRc4oUFwN+ndKnAU/9SEQOjgEq8E6VImMh/NH35GeLTkhlJwVzX9p 6jymBW+3vMNb1utlThrVe8OgjC8OCz2B8CuAh5QeBNAWsCmhHINY82bxaHV1/3DErK4T F2xA== X-Forwarded-Encrypted: i=1; AJvYcCWhXaQWyHzn+676fsjpVzJVp2dXyd/rLr4qsXcf9fzfCLJMhN5YjLQnR9GjPd/cy4QwG0OjklY80g==@kvack.org X-Gm-Message-State: AOJu0YxJU+ag8T1NJQyc1uvKnqzvTYwZuhceaYU3wzTckuMcb5yvbz/U ba1Y5/P1M/HTP4fFWeHWBNHHr9PxY76thlNzWH/K9s3zZ03s8UXsrtw9wWRv2YiZj1M= X-Gm-Gg: ASbGnctRCDy5pzDDypphJsB3I0ySQG8du94CZui8oOaaEwKheJWQHaapXpU7lZRKdRX UnL2WuX3nKGIsfSHPZ07URzia0A5JO6vr7j1kDD5OQR9K4ATi8YDE9Aclxh2cK03b8IYu8Y14Qm wYJrHmoLvzWv1cl0f6fPkM3zoHIAkBdoYuPtfD/ec0E8bdJjWU7m64VtlKchI7aKChLDF9VPNxW j0620HPUYBa4n9WtGr5md0fuOm8v+crRAtLT+avcwyOzkh+blcj9D+f9lQnhI6KYe6okb8FtRh3 hEXD9BhvvVv/1e0waIsbggij4TDUchLYDS99ffznvmhW5YCYvaNykyPTtt9wzHVm4VWZ09btkQg 9zwXiuoQvHIchUiWKbiohOh50VcsL8Ja8gX112E6enQkSwzWK9A3T0KNRGj5YICPXY/c= X-Google-Smtp-Source: AGHT+IEWZCSuqttypCq2CzG6w+lGWATA0+jX9Li2yrDFrWwmJA+OoSeGnOZU312Xh/zwCq+WJVnCjQ== X-Received: by 2002:a05:600d:10:b0:451:dee4:cd07 with SMTP id 5b1f17b1804b1-4538edf5becmr9797775e9.0.1751023973312; Fri, 27 Jun 2025 04:32:53 -0700 (PDT) Received: from mordecai.tesarici.cz (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4538a43325asm47023565e9.16.2025.06.27.04.32.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Jun 2025 04:32:53 -0700 (PDT) Date: Fri, 27 Jun 2025 13:32:46 +0200 From: Petr Tesarik To: Robin Murphy Cc: Marek Szyprowski , Bagas Sanjaya , Jonathan Corbet , Andrew Morton , Leon Romanovsky , Keith Busch , Caleb Sander Mateos , Sagi Grimberg , Jens Axboe , John Garry , "open list:DOCUMENTATION" , open list , "open list:MEMORY MANAGEMENT" , iommu@lists.linux.dev Subject: Re: [PATCH 7/8] docs: dma-api: update streaming DMA API physical address constraints Message-ID: <20250627133246.1d0a6d46@mordecai.tesarici.cz> In-Reply-To: References: <20250624133923.1140421-1-ptesarik@suse.com> <20250624133923.1140421-8-ptesarik@suse.com> <20250626070602.3d42b607@mordecai.tesarici.cz> <20250626154818.46b0cfb1@mordecai.tesarici.cz> <0f95be6d-2e13-4281-98b5-6d4311a3b98f@arm.com> <20250626214038.2d005bb5@mordecai.tesarici.cz> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.50; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: rcj6wwy6db9oos6w5wyyuw14jrn9i9r6 X-Rspamd-Queue-Id: 233C5120009 X-Rspamd-Server: rspam08 X-HE-Tag: 1751023974-757666 X-HE-Meta: U2FsdGVkX1997oJdVrYoR1GSS/LGqEVn8Mwm7CCYB+/0M9JmaqjrNJ48b67IYfa/rBZ39UGkX/jn+cACt8XpbS7JACt56GT1cdJPHn+bBvJuVBSFES7NqDQNVdCAV+X80HTHQ549jHfjRGA8YKUoDDOSraQfVkoKGPkGw4BTRdT1gkxT48Gk0PNWZkkvz0hjkllop3bk79qUwT3qCBCK8OfOlza5NQHZ7luNtZnH7Bu3TKRlO8Qrlq7z90X6PY8f0FoRl0PVtHThxdNqm1p+gan9T4XvEksvipHA6ApzDvUrdD3vQeodGKOy5N30ITrcrs/kpvMAMt/DpRXuqf92jVl3pw38wdCxZqKUVaeLu6XFz2kfx+Qdbi0nJhpfsP/FpsCSTCQ/WKLK3NAWLsqwgJX1s3pCE/7+iHP8A6E4uoAr0LppAQ6ng4l38Pwm2Sw/UkfKEpbPlq7DkGmyq/T2O1JWwcTwuGt3SHR5myTBesj82Mwl+MUMs95pFlXW18W1qUMW5bTCgNqYF7LCVRD3Ed9yU2/JwCWOeyjn3AhviYK6sGmkL7k4UP8rbP4lRYOx/ITD8q0CqJ49NfAQCRFxt4pv1CYy92vwxt+bTHFEenfhtByqPIa46K4OOpNmcoz471OqKXxc58DS5zxWcyaBuBu6BfEmXUR1HsYsbPBjpv6tKR7dFWKrDMH0ZJsvufIC7c7NpUPZ6O6xb2O0VU5pfxFjnuy9xPy86MvX82PIohiWEcYqGirsfVuhK9pZqaABoalb3WW8CmhmM1/c/6XUFTzx6tTNg/gMs3W6op/AT44YKCGaKH568XJvbOqBdZbLjOBg0/jIQDc+/VfdsShq+Yd/Hn2sL3oB05rV6i0G7piNN2aRloa0qsA1tkwlTJ4ZFR0C1NzRMTSfs1Mmrlo80n1n3GAx9D3xwUYmCl1vM+cDgMLUHfc4a2+PExvWRGTAGOkZvDgLMa01aeE5RBj CgqgaeJu GCUFZVwMuqoiJbFgDzMVD7ucpRc79KWX8cwruT27gTCwy5Mfh2cv36bjMMfgQFbkbrkGOuxgrq4uF0pzOfr+iy5YkYH5hcgbWVaJ0X9Amnt8X/0yp3R24WGHLvId8vvNDhwwt1It9wF5dZ/OAG0NFB3f7FAwX67ZZz2avRVjmilKZL5gNftTf/44rvJnRAIq/x7c5Ao1QSbrhQGF7bKdS53PGUxgosF4EgR8wSfnwsKUV9evGoLgBME/jbavw7exTV0qNZ0guC98UqI03wPCDdVFhT+6IQ7irjW2NRWxQT9eEaUmi4BMfPqw2xkDvEFB81B2qEOd6yHNogjd0eqsTKVDC7A== 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 Fri, 27 Jun 2025 12:07:56 +0100 Robin Murphy wrote: > On 2025-06-26 8:40 pm, Petr Tesarik wrote: > > On Thu, 26 Jun 2025 17:45:18 +0100 > > Robin Murphy wrote: > > > >> On 26/06/2025 2:48 pm, Petr Tesarik wrote: > >>> On Thu, 26 Jun 2025 10:58:00 +0100 > >>> Robin Murphy wrote: >[...] > >>>> It's not really that simple. SWIOTLB, ZONE_DMA, etc. require platform > >>>> support, which end users can't just turn on if it's not there to begin with. > >>> > >>> I know this very well. As you may not be aware, my ultimate goal is to > >>> get rid of ZONE_DMA and instead enhance the buddy allocator to allow > >>> allocations within an arbitrary physical address range, which will not > >>> rely on platform support. But that's another story; for now, let's just > >>> agree on how the DMA API is supposed to work. > >> > >> Indeed that might actually end up pushing things in the opposite > >> direction, at least in some cases. Right now, a driver with, say, a > >> 40-bit DMA mask is usually better off not special-casing DMA buffers, > >> and just making plain GFP_KERNEL allocations for everything (on the > >> assumption that 64-bit systems with masses of memory *should* have > >> SWIOTLB to cover things in the worst case), vs. artificially > >> constraining its DMA buffers to GFP_DMA32 and having to deal with > >> allocation failure more often. However with a more precise and flexible > >> allocator, there's then a much stronger incentive for such drivers to > >> explicitly mark *every* allocation that may be used for DMA, in order to > >> get the optimal behaviour. > > > > I have a different opinion. Most buffers that are passed to the > > streaming DMA API are I/O data (data read from/written to disk, or > > received from/sent to network). For the write/send case, these pages > > were previously allocated by user space, and at that point the kernel > > had no clue that they would be later used for device I/O. > > > > For example, consider this user-space sequence: > > > > buffer = malloc(BUFFER_SIZE); > > fill_in_data(buffer); > > res = write(fd, buffer, BUFFER_SIZE); > > > > The write(2) syscall will try to do zero copy, and that's how the > > buffer address is passed down to a device driver. If the buffer is not > > directly accessible by the device, its content must be copied to a > > different physical location. That should be done by SWIOTLB, not the > > device driver. Last chance to chose a better placement for the buffer > > was at malloc(3) time, but at that time the device driver was not > > involved at all. Er, yes, we may want to provide an ioctl to allocate > > a suitable buffer for a target device. I think DRM even had such an > > ioctl once and then removed it, because it was not used in any released > > userspace code... > > > > In short, the device driver has no control of how these buffers were > > allocated, and it's not fair to expect anything from the driver. > > Indeed, for true zero-copy to existing userspace memory then there's not > much anyone can change, hence "at least in some cases". However, there > are an awful lot of drivers/subsystems which use streaming DMA on their > own relatively short-lived kmalloc() allocations - the first example > which always comes to mind is all the interfaces like SPI, I2C, UART, > etc. which are either dmaengine clients or have their own DMA (and > indeed some of which were historically trying to do it from temporary > buffers on the stack). Heck, even alloc_skb() might end up being > commonly used if this "ethernet" thing ever catches on... I have been looking around a bit already, and I didn't see an _awful_ lot of these short-lived allocations, but yes, I've found some, and yes, most of them are in the subsystems you mentioned... Anyway, thank you for your patience with reading my DMA API docs update! Petr T