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 9E410C36010 for ; Mon, 7 Apr 2025 09:50:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41BF66B000C; Mon, 7 Apr 2025 05:50:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C95C6B000D; Mon, 7 Apr 2025 05:50:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 293656B000E; Mon, 7 Apr 2025 05:50:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 08B0F6B000C for ; Mon, 7 Apr 2025 05:50:41 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B1588C1103 for ; Mon, 7 Apr 2025 09:50:42 +0000 (UTC) X-FDA: 83306778324.21.85CD5BC Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by imf23.hostedemail.com (Postfix) with ESMTP id 88980140002 for ; Mon, 7 Apr 2025 09:50:40 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=aQ0Ye+ma; spf=pass (imf23.hostedemail.com: domain of ptesarik@suse.com designates 209.85.128.42 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=1744019440; 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=7D0FqJ6RtAdU/pLFY5nrSh7PT3jYtwtVDrbIig9XoYY=; b=F4M0H90wSoW2jIi14yTjJ30nuFN5340OnVoOFxgTH7pKacFsKm1igp7h1Wz32Hi+ndMuPS /p5fau6/zRnTNvgIngymDH+NVbZwcQy8JkwtOh7rl8EKvyq2s/OKvbtGUW/KY34xzeRtzJ em3SB56O52BvqRolirW91JFYc9I57Ig= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744019440; a=rsa-sha256; cv=none; b=VtOzqdTfZt9U2YwTTtkJhP7paSHwUXJ9pRvc6QCkWaqPCx71Z7rN7rEJN80qcTESZB7Gpg 5LE79pAL6p0aacTaZSkLBLhhpZWksMAFrLx1nFV/nFxay6sKC3WYvPc+AwphGdZZuOh0hq AAGcEHlK+NZL5aDPNJ5akElLowPa5i0= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=aQ0Ye+ma; spf=pass (imf23.hostedemail.com: domain of ptesarik@suse.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=ptesarik@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-43ceeb85ab2so2858845e9.0 for ; Mon, 07 Apr 2025 02:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1744019439; x=1744624239; 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=7D0FqJ6RtAdU/pLFY5nrSh7PT3jYtwtVDrbIig9XoYY=; b=aQ0Ye+maFN9b2Ptbn8sBQCK5NXmdoPistRHHlniCfcXLDRQZULe5a6ecWksZyZOlEw KuL6uXFged8OfX1fMFBFUUm7iMv7PcR9dOStOGPF+vG74NrhsXGnNEZPCpm0sTGIBe+w AWbLq6Oof96jOaO9dNGv6frKCIeA8oZCQcQ5qjCxbk5z9P7wHehwk+y9tR7gL0NHkA91 M+o+er2eljpLkuNd3+Ena55J0PBJSK3WV8DyCqvHBcP3Xz9yWgGYXP0EjJdlq+1buOr8 RmectU+tnVsz63yzPST3tkfI5JOosso80t0IRgAv9rrio8IUMyjSEY7/PExc8Dx/WR+R 2kyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744019439; x=1744624239; 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=7D0FqJ6RtAdU/pLFY5nrSh7PT3jYtwtVDrbIig9XoYY=; b=juuYvJCahPBMM4zz/8If95HLKs33c6fQr6XTTYKDW55E1F+JVf3N643jTBvblg00V8 iuYdL2MUmROFZZdd6Pny1Yp1m5r8p231LIPW1MIXnpFVnFSOAW+PLqwLpHcxttyjOUM/ H59e7iT+f1BTfmer74MDyQC5Q75liy8v0wuI3iwTyf07JyQeRdTsgc16NnP2Da7GTFe1 r6sNQIF3dG13uex9419WkKN2CpfEHY2b6Fq9p+oev6//5J3lRwSCD6MjLU99tyHi/Ymv 4KbxM2lT7io25VrIWIsRBCJRqIALKSW9p5h5y7q2T+THmZvGlhq3g/4cF/3x4fJSEeZG 4VyQ== X-Forwarded-Encrypted: i=1; AJvYcCUfWpq0d5GXKYXOsTBfBUCFFhZbuxGFA+0iJjauhLq3mB3dvEiRwIIuf014yiHgXcWQzZQR6KhjRA==@kvack.org X-Gm-Message-State: AOJu0YzMPxeQDWHJNMn7cFBLgIUX3KacDi+BOa89vyWa2FGnWzhlsrqu sMA1jrkvlf7wRzRC19TNm5QiB74aQLgwR3OOX6zJ3iyc9O12ISY87Buql25bf88= X-Gm-Gg: ASbGncvnOIvgnPkBBMj4q2kq/MqXtdzrb9nx03axzMZZV2scTC7nITBlrr4jtzOJrij BPfMlfPu3ejmbOjh78BdmB+pnawpql/ebQpF/i2dxwPDpvZL+FBcMAAySf2c0sWrEqtHAmT51At FrTUFWv/AVW6IzXl+ZdPqafgIPCBWTbOnvl5d20VeUF/X5RlsjG1vhVMDuY9eFuAyPgVsJ1w42R 1wbdlnx8bg1ytkfPBYy3aU1jeAyf6Wo7p4CBfuFdK+2uHVlmdOvceRXQHgUrJuXxtEI0cX35+ea XueWPOxRUtwZUo0O0fx7n2XN0odskGxJ5rXISm1eFJidbad3OF3bkdEF/ZygGMc/WXcbRfyo58y 50bJQxpRxkbLBTTKByp8dR/jJe81Xsf4CMt/7FxhvseX0 X-Google-Smtp-Source: AGHT+IGuJGNojiARC5FXLQlb1oSKTw7KjWq5iHcByA3RWWOWgVySL4e9JMTOmZ42gL47oQkZyu65Ww== X-Received: by 2002:a05:600c:3592:b0:439:9ec5:dfa with SMTP id 5b1f17b1804b1-43ecfa18f83mr39663475e9.7.1744019439116; Mon, 07 Apr 2025 02:50:39 -0700 (PDT) Received: from mordecai (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-43ec364d036sm123484265e9.26.2025.04.07.02.50.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Apr 2025 02:50:38 -0700 (PDT) Date: Mon, 7 Apr 2025 11:50:36 +0200 From: Petr Tesarik To: Vlastimil Babka Cc: Feng Tang , Harry Yoo , Peng Fan , Hyeonggon Yoo <42.hyeyoo@gmail.com>, David Rientjes , Christoph Lameter , "linux-mm@kvack.org" , Catalin Marinas Subject: Re: slub - extended kmalloc redzone and dma alignment Message-ID: <20250407115036.7357105a@mordecai> In-Reply-To: <39657cf9-e24d-4b85-9773-45fe26dd16ae@suse.cz> References: <20250404131239.2a987e58@mordecai> <20250404155303.2e0cdd27@mordecai> <39657cf9-e24d-4b85-9773-45fe26dd16ae@suse.cz> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.48; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: b18ontuaojmu4uqn6gdsnj438hn6q1ct X-Rspam-User: X-Rspamd-Queue-Id: 88980140002 X-Rspamd-Server: rspam08 X-HE-Tag: 1744019440-556067 X-HE-Meta: U2FsdGVkX195NCXgsNOTs/aqNh8rJStubIt79snNW0Yw77ZUZvf2qfnmf6QnC1T8rnLS0lXr9rigYUqO/QEyClzgqFtY9aNe8Ci095y2aqL+rlwPH85bSGFRWrt/W0c3qWmHd6julHm21yeBtmk4VxujmfUFKRVJuZWHpsU9WaSzltqbr9BAH/HL38fGcuG3a8uO7zZxYtROJGHVmWLS18KmBcqZDFUH1Yzxc6Jpux6psP6xxDGAJ1QPqF4Z4RYRSkXjOWhzHKqUvIikfqKdHgiTI1AiCBozzTmyBnOoVkPQx+B+mghiLSW45VAuIUrUL+g6WRD2lwjIl2uhQY0zhbLwE3KHpHI4wa6a9BAlEP2DLkuWjBq9IY3nmysdpnGciJfPEqUyzXLj6Qcw8u5bYEOE9Tbavcfv4Dsw2ddo8E+VLm8JzlNkEppJezEiCI2pGOifDf61BMaCMwRV2zLtmgWs2mIFiyUgP7BQ0qTb8jJ2l7itBEDeZmnsjEMaMw0efdovzYrm6ljxCg39MVcM/1MF4rU6BK8roLbVxOdVvoUCjXKSpW3bfEqRt/ta1QotLO7J0WBKz+zXoAruf7J58weIuwlw2Cs/W+0/x7kj10VKlrihFKmBDKGEiiKoyZjjNsY7xqEQsoonvNeWMUU+X6RGO8ZJUUbDV/RXp9ukVXtAxKNZtlhlg0fg75N9TZNxBWZNauTlXbaDjFlc5uK91b6ZKt7k0nv/olqDAtE2ImVCgjh3jyrPFicCT/Qjz/37bG2V838qm8ZFlfnwCiS20ivJZb1bS9DrSCDuSCwxXGomsr484/PHP3zWaOoTayBPhml6M/GhdvgdwW+NVIySLL9N4Tg5K9jBioJwlm748zlc125Te7UaMAOz3ysBuDbWrgJx4hc1tld1fSJGhczbVSWALlB/GdS+Kzw1jXR11twdys6E8I4/ikuArFM8akQEn3PxedxOPXe098RhrN8 iAlG7Jho y+EDIzBb3ypAQY9QHz2wBblnMg+vYildn6PNaZ12P74FgUGusXuVuq1cNMdGm0AZfLjlTuQI8gSQiR+w5VhzazQegtlud/Wdy63n5jtA4ipaEvb5u5ZZ9EXRAudkI6gDMDl3cFdUNGbHvuZt+IgIYXrc3LrTohlcenLpPb6hpBlnhS7aXZ/87CLnfmd94sERgXjYaomYaCsYs4sZ0DJ3wFsgxrOknU0TTfe7TJU9PkXv08BFREdP9aq0CT7fbhVwtzI9FpNyc/VPHXTEInhZIpI48QJLGeAcWBrBSNIJwryNgHx1MDQZXcebuc3i6nv0ugf6AoOTVeQaa8Ja35HM7fZCKCObh+gwM14yy5TOb6/pm3WyNW6kySB628g== 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 Mon, 7 Apr 2025 09:54:41 +0200 Vlastimil Babka wrote: > On 4/7/25 09:21, Feng Tang wrote: > > On Sun, Apr 06, 2025 at 10:02:40PM +0800, Feng Tang wrote: > > [...] > >> > I can remember this series, as well as my confusion why 192-byte > >> > kmalloc caches were missing on arm64. > >> > > >> > Nevertheless, I believe ARCH_DMA_MINALIGN is required to avoid putting > >> > a DMA buffer on the same cache line as some other data that might be > >> > _written_ by the CPU while the corresponding main memory is modified by > >> > another bus-mastering device. > >> > > >> > Consider this layout: > >> > > >> > ... | DMA buffer | other data | ... > >> > ^ ^ > >> > +-------------------------+-- cache line boundaries > >> > > >> > When you prepare for DMA, you make sure that the DMA buffer is not > >> > cached by the CPU, so you flush the cache line (from all levels). Then > >> > you tell the device to write into the DMA buffer. However, before the > >> > device finishes the DMA transaction, the CPU accesses "other data", > >> > loading this cache line from main memory with partial results. Worse, > >> > if the CPU writes to "other data", it may write the cache line back > >> > into main memory, racing with the device writing to DMA buffer, and you > >> > end up with corrupted data in DMA buffer. > >> > > >> > But redzone poisoning should happen long before the DMA buffer cache > >> > line is flushed. The device will not overwrite it unless it was given > >> > wrong buffer length for the transaction, but then that would be a bug > >> > that I'd rather detect. > >> > >> I alaso tend to think it's better for slub to detect these kind of DMA > >> 'overflow'. We've added slub kunit test case for these in commmit > >> 6cd6d33ca41f ("mm/slub, kunit: Add a test case for kmalloc redzone check), > >> which was inspired by a similar DMA related bug as described in > >> commit 120ee599b5bf ("staging: octeon-usb: prevent memory corruption") > > OK so besides Petr's explanation that was about cache (in)coherency and is > AFAIK tied to ARCH_DMA_MINALIGN, there is possibility of DMA that will > really write garbage beyond the buffer that's not word aligned. Can we > assume that this was really a bug in the usage and ensuring word alignment > (not ARCH_DMA_MINALIGN alignment) is required from a different layer than > kmalloc() itself? In that case it would be best to keep the reporting as it is. > > > I'm not familiar with DMA stuff, but Vlastimil's idea does make it > > easier for driver developer to write a driver to be used on different > > ARCHs, which have different DMA alignment requirement. Say if the minimal > > safe size is 8 bytes, the driver can just request 8 bytes and > > ARCH_DMA_MINALIGN will automatically chose the right size for it, which > > can save memory for ARCHs with smaller alignment requirement. Meanwhile > > it does sacrifice part of the redzone check ability, so I don't have > > preference here :) > > Let's clarify first who's expected to ensure the word alignment for DMA, if > it's not kmalloc() then I'd rather resist moving it there :) I think it's clear. The granularity is mandated by the bus protocol. It's not like the wires can add padding bits to a transaction by means of magic. ;-) If a device becomes the bus master, a specific chip drives the bus, and this chip must know about word size. In fact, the hardware registers on that chip usually specify the transfer size in units of bus words, not in bytes. And these hardware registers are programmed by the corresponding device driver, so it must be the device driver's job to ensure proper alignment. Petr T