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 EB95AC36010 for ; Mon, 7 Apr 2025 07:21:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5770C6B0005; Mon, 7 Apr 2025 03:21:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 522BE6B0007; Mon, 7 Apr 2025 03:21:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 438016B0008; Mon, 7 Apr 2025 03:21:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 259C66B0005 for ; Mon, 7 Apr 2025 03:21:15 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 031DE140E5A for ; Mon, 7 Apr 2025 07:21:15 +0000 (UTC) X-FDA: 83306401752.20.E3CDBCD Received: from out30-100.freemail.mail.aliyun.com (out30-100.freemail.mail.aliyun.com [115.124.30.100]) by imf02.hostedemail.com (Postfix) with ESMTP id BEDF180004 for ; Mon, 7 Apr 2025 07:21:12 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=WzN09u0u; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf02.hostedemail.com: domain of feng.tang@linux.alibaba.com designates 115.124.30.100 as permitted sender) smtp.mailfrom=feng.tang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744010474; 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=AkJcSsd49aYM6RUd2csYfTHt5Ry8P2HDylaiTV4QJTM=; b=S4JAqNA9VwAo0zyUab879HQ7VF5MPo0izvKfg1VYkamxgH3c0fQnA1nbaFac4TXB0XfWF/ 9z1wjR5eegAB8LAOBk9Fb57yExqxcJ5H5iMuSjVFQuP8fAECgqXXEqQcRJPIVn4bggR2eH BQUwJgEeCwIgze3zS6ulPZDsepoXLSU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=WzN09u0u; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf02.hostedemail.com: domain of feng.tang@linux.alibaba.com designates 115.124.30.100 as permitted sender) smtp.mailfrom=feng.tang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744010474; a=rsa-sha256; cv=none; b=jhi8Rpx4CS6nD4dLokfxbRNNE/wx7VDyE5oXWukwhwQvo6YPhud61BQn+al+/uvkOfL7yv ni+JDFAmHCggU9HzXrYWwTRkqp2tpqda5EuLwAIBesENZIvNRXZu7lFRj4WsUqI5DD06VG g91dwqXK0hXQOQC25YefsGomD/VAePE= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1744010469; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=AkJcSsd49aYM6RUd2csYfTHt5Ry8P2HDylaiTV4QJTM=; b=WzN09u0u0s5+rGuAkv2ZLRgN8wq/skwk8EtNCINM7of677ZVBLp5IjW74x1qMsCFS/Jb7rbyh2uVTEFR8up2qf5tF/S6wEmu5DhZ++QE30ZpCOvt1mvO4MEeRziKYGC8dTsEJGC0lGXfnNAEJM8daE7VUvhXko6qsKt8mca1Roo= Received: from localhost(mailfrom:feng.tang@linux.alibaba.com fp:SMTPD_---0WVprsu5_1744010467 cluster:ay36) by smtp.aliyun-inc.com; Mon, 07 Apr 2025 15:21:08 +0800 Date: Mon, 7 Apr 2025 15:21:06 +0800 From: Feng Tang To: Petr Tesarik Cc: Vlastimil Babka , 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: References: <20250404131239.2a987e58@mordecai> <20250404155303.2e0cdd27@mordecai> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: BEDF180004 X-Stat-Signature: csae8699d9cnicqe4mom61dhm9mjia4f X-Rspam-User: X-HE-Tag: 1744010472-734791 X-HE-Meta: U2FsdGVkX1+QrndaSyEm6cBAnFfCgV+Ger5Oo9PcgpUB9iNNfOH+9zgaG06XJdeCaQS/TCuD8aC3GKEEQBo3dck6nCXeriDgGqZiQw4IHUNVXYlK45DjXtWyHM4R6Bza1t8rO6YVc8eu0IxyQPfQCXxFqmWxwxXISiIgYcn28BPFzzeF9uQkzd68Ihh6edK3DYMkVWHdUBwh+WHumNS9OKOCrq+GfUC4t1/bmco4YndZx4aQ68Tau2sHTXPgSYf+PS2eKUWo56zcBiUSJJGgTiZVa3VfN154EITKLkMMo2BNggic/WwcpJrzxOETQHJ10WGVtDnF0ozDKBRrAW5SSlYnlOGMMyYdCzmbLVgMskOIAd7kk3ILQ3FxMKEApbhyNai2LoK98ElJKOqBbVlP47wcuoa10Wk2XYkoQ44vWqSJjMtshCE+hCkb3lgRqA8u9SKfC7/NPra86Y8gGSG4NTwlTk5215EFi6UbLTqIEWqND6xwzlT8SYdg1EDjMWW3CGmZOkH9+uf81Y3+R0CbolY6GSGLBh+xMOWoeIu/zeVYoG74Ss9eGQuSBHKBGd/RY09ELrAad4xMI+Kn81gfudeHKx3C+uB7tiUba96JcLr9vUobuK3UkgV/wSedmZdHFHAZ2D9iqfsoJntigRX46eGkDJZOWUssnmZBM3gr9nH+QW7UyRDKu7CsBfvL9HR+UspQP/7y8sK2jigSLkg9Bqm6nQfHTa4iwgZ37u+Il/1M2pn/nM2CYH/c0aGUSXVo6aFQFLXNEdL8Zo3qkyPoPLFdHrV0AeLUjyEbkHWzjAQhDYPxIMBcmihSGwVf4cgl0Z+jgjT/vUeJaLAw/KffDP1+lZliNbJ4WAksfy1sS/cM+owci6cM9frtBV4YrzuzZl9RQ8+bl04c4YyGp0bvaOYLitax7Uc9KhJ3FOVpb+hgrwtmlpySGIokGF3Q0j+rC59F3RN8utF1B5h3rWR wMEf2nT9 Duzrl60pzKD9Zsu4LaVss/ljKsjMpL1GmpCfEoO2jezimIrC+sAJsfIdPsiphQjxnW/rL2zTIR62KwG8NOKsqADjuYdz+v2dzEKxpLQhvQhLnhYr+Wls6E+7KFQMNHSRfl28oAY/tbul5jOxMXDCb4bg+w8PKuBUgFW+AcwgHFJvngY+ebTj2haGe39gPoI6mqWXWgimB18b3rFotN0sRD87lmmjzEx2GutN+CNYmsSUEvjXbiENZcZ/IIEBDR7ZnNadNFEI2tRV2tJsa4EDRFijj74vmGZGmMtETvk2CFINm9FNSx8q88ywuXyQApGEIBCdymRcLShhh+ukmudgyY8fIrDKwxsoOUhKJ57CtyZ8MGu4= 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 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") 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 :) Thanks, Feng