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 A6675C369A2 for ; Thu, 10 Apr 2025 01:54:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF2FC2800BE; Wed, 9 Apr 2025 21:54:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA0372800BA; Wed, 9 Apr 2025 21:54:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6A232800BE; Wed, 9 Apr 2025 21:54:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 96D922800BA for ; Wed, 9 Apr 2025 21:54:32 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 39080AFC24 for ; Thu, 10 Apr 2025 01:54:32 +0000 (UTC) X-FDA: 83316464784.22.FBE865F Received: from out30-98.freemail.mail.aliyun.com (out30-98.freemail.mail.aliyun.com [115.124.30.98]) by imf25.hostedemail.com (Postfix) with ESMTP id 677B5A0002 for ; Thu, 10 Apr 2025 01:54:28 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=yVRBB7WB; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf25.hostedemail.com: domain of feng.tang@linux.alibaba.com designates 115.124.30.98 as permitted sender) smtp.mailfrom=feng.tang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744250070; a=rsa-sha256; cv=none; b=5c/mKzw/i2H0Biwa75n7gtw/Q5i2zVmpq8V6G2WedNvLuKT8VYjMryzk/pZJYG6JeE3pVf TXDH8tNSt0L/T6+SZ/tpoMtKJ05TmfQa2Ud+5UpBfrTo8AcJlrnayEh6Hzg8m1DVHJnSJJ ySQt5JLfNa+1qv9TGqGw9w0GGlDyiuw= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=yVRBB7WB; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf25.hostedemail.com: domain of feng.tang@linux.alibaba.com designates 115.124.30.98 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=1744250070; 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=Dl1QQaitcZrt5sBbMRb0KdWaxEAbOUkXVH4wuQ7fkLo=; b=MszqNBc0Q3P6u6veZ56XMORZN4cSyBKWcdhMPCQUariCZYwLEb03gLQdsxEeZAV7Uabker /vJg7ACBl9gn1bleWowQitu3ewx3gCqeZ4UV4IlvnWAtmgWZxCbLPvERpmfjhraiXajz91 SvpoOxeKgB2W+QGpY+ZmqSUEd1EiZvs= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1744250061; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=Dl1QQaitcZrt5sBbMRb0KdWaxEAbOUkXVH4wuQ7fkLo=; b=yVRBB7WB7ZHZANAMrY78xufAPur3JPwveaY5seXu9BmTF7u4NupGlY9dFeBFUKygux8Kompi/Drq+pSoJNl3o6YBvBP8f9zfBubiTxD2PF3h+RAxxO1A6aEjWjol3NWrcdP+Z3gRT1Oxys9v14qqsonY5UdxalhvocAvAqs6Buo= Received: from localhost(mailfrom:feng.tang@linux.alibaba.com fp:SMTPD_---0WWMCQ8O_1744250059 cluster:ay36) by smtp.aliyun-inc.com; Thu, 10 Apr 2025 09:54:20 +0800 Date: Thu, 10 Apr 2025 09:54:19 +0800 From: Feng Tang To: Catalin Marinas Cc: Vlastimil Babka , Petr Tesarik , Harry Yoo , Peng Fan , Hyeonggon Yoo <42.hyeyoo@gmail.com>, David Rientjes , Christoph Lameter , "linux-mm@kvack.org" , Kees Cook Subject: Re: slub - extended kmalloc redzone and dma alignment Message-ID: References: <39657cf9-e24d-4b85-9773-45fe26dd16ae@suse.cz> <20250408072732.32db7809@mordecai> <42cb9ae4-e479-4f52-8e4c-f4bc3cb54971@suse.cz> <53cc9e92-8a57-4989-af4e-26ced40de91c@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 677B5A0002 X-Stat-Signature: kk3ip61isosoc853xzqiemueedyow4r7 X-Rspam-User: X-HE-Tag: 1744250068-188053 X-HE-Meta: U2FsdGVkX1+i3Qnz0KqG1ICa6YWTkDJKPOrTIFHWDF4xhZC9HAUfUgVNLsyqkxA8xY2dhLaJf9kL16aaMGC76YJ2VBryRBKJyh7/choUQENC7+nXa60ryQZBrXfHJ10OCVGfnJ+WsB21fla/sfMs4xG1bNKfYdWbgG9XmLyASc7PhnEuC+36OC+h0a3f5F5TrQLPBnoEb7q033ZdfiTojbPdcQdjAr1lK8kY6FIN1L76T4wNjDTfpgEBBcyvGmA3ZISygvB54h1ICQXWGnYbVoqjgNUKYJlWhhq+5s6UOUbcRJlM+LrAydldH4Q1NqCzAKjgJrv4SRrBNZqeLVGwuq2Rk8AVp4qYiWOupzdaGgxakjUPRH/16FriTvgYtdE8Wd/ipPb6/98UhG2fYokKmNH6uwBZy9Z5E9BF00pv4ObaeIQCX0C7FjsImI7V+h0UPZzDdfsq6ugOShJqXaf0e51DPP2HQM4LtL4KIea7QoBS3tHHW05xK+PjmMSDsiMVmNI5xhhd1MtVq/+VsacilxybMcPIGtukK6G5L5lJzvHKZIWhGoxop/LaID/NDkRUeFSIK2VqTgDWMQgrmJFNXTt5ujvL0uFDHXnBF7R/hSZJ2In86pLU7WBZw0j8pHfbqvRK2D/cBlpop7iNOvQP8jjezk38gcJfpHBxG0zDhyyw267EqvjXTYiuzYynLaYgXaEsF0WS1gQ1+YmHWOiEouH2c3uaroDMPLB6NSqt5N3m6sUtIp1GNGZVfPn9Ok3aIu9WnwnYs7BACKbPLezPFXNA5+zpempMg/R9t0AW98rxE4fxI1EL675eOZdIk+XIwBZOnyymOyyaH1stGW0BHEuA/L5c73QJNdZ33Ik4OK6VapVL7ZdP24QlYKuUGn6WWpSBcbaicyosDiMGwXiFB/fKzAqnY/DkPq/u6CEpUNJuZFTQDFJOEhQ4zvX7L/hEOeVnrRzYb724JSQzVBo pj5ecjcj WlJet8xNSUyho/PnGze6GpyN9IZ4qYAu9VM3WvLSJYfspjUiJfN4KDN7fziUnEuXkEsGmxPfIwC+5S/HxK2C+RPjCERp6k3HP19RnD+GcfDy5DI6YPQMXQWMRQfpvei5G0q/5Y8jI4VbqlKjeSMdqfsFBb25n/SQW++irCC0LmOu0P/tBqElzsb6ad1sNj5aBQwwFExNooALD9pViQHHiiTdSUGz5JTZgHWCv3SdrHS4Z/XF/FzkMvJcn+J7iatlgqMpEknBZQ8RNitRozZ7cGf01pKoAptMPc95/6h8obSb1dStHPGdxzFFFMIvxwa308EH7N82r3jVlyNdoT4DQsj303Y2f/7xd1GLvjB/wUiTryVVrYHHd4bThF+DoC33C3ZQltgFFNY9H8MAQo2i49bZDpQ== 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, Apr 09, 2025 at 03:30:16PM +0100, Catalin Marinas wrote: > On Wed, Apr 09, 2025 at 02:22:10PM +0200, Vlastimil Babka wrote: > > On 4/9/25 1:11 PM, Catalin Marinas wrote: > > > On Wed, Apr 09, 2025 at 10:51:43AM +0200, Vlastimil Babka wrote: > > >> On 4/8/25 5:07 PM, Catalin Marinas wrote: > > >>> Assuming I got kmalloc redzoning right, I think there's still a > > >>> potential issue. Let's say we have a system with 128-byte DMA alignment > > >>> required (the largest cache line size). We do a kmalloc(104) and > > >>> kmalloc_size_roundup() returns 128, so all seems good to the DMA code. > > >>> However, kmalloc() redzones from 104 to 128 as it tracks the original > > >>> size. The DMA bouncing doesn't spot it since the > > >>> kmalloc_size_roundup(104) is aligned to 128. > > >> > > >> Note that kmalloc_size_roundup() is supposed to be used *before* > > >> kmalloc(), such as dma_resv_list_alloc() does. Then there's no issue as > > >> no redzoning would not be done between 104 and 128, there would be only > > >> the additional redzone at 128+. > > > > > > Yes, if people use it this way. devm_kmalloc() via alloc_dr() also seems > > > to be handling this. However, given the original report, I assume there > > > > We can probably ignore my original private discussion as motivation as > > it wasn't confirmed (and I'm not sure it will) that it was really a case > > involving DMA alignment. It was just something I thought might be > > possible explanation and wanted to doublecheck with people more > > knowledgeable. > > > > Unless you mean original report as 120ee599b5bf ("staging: octeon-usb: > > prevent memory corruption") that Feng mentioned. > > I was referring to your private discussion. IIUC the one Feng mentioned > was about the SLOB allocator which I recall did not guarantee natural > alignment for power-of-two allocations. > > > > are drivers that have a problem with redzoning at the end of the buffer. > > > > So I'm not aware of any issues reported due to the extended redzoning. Me either. > Thanks for confirming. I guess we can ignore this potential issue then > as long as drivers take care of the alignment or use devm_kmalloc(). Yes, I agree it's better to let driver take care of the alignment part. IMHO, touching the memory beyond its original requested size is kind of abusing, no matter it's software intentional or 'unexpected' hardware behavior. kmalloc_size_roundup() patchset was initially introduced to help reducing potential similar issues: https://lore.kernel.org/lkml/20220922031013.2150682-1-keescook@chromium.org/t/#u Thanks, Feng > > > > I did a quick test with kmem_cache_create() of 104 bytes with > > > SLAB_HWCACHE_ALIGN (64 bytes) and it has a similar problem with the > > > redzone from byte 104 onwards. Here we don't have the equivalent of > > > kmalloc_size_roundup() that a driver can use. > > > > AFAIK SLAB_HWCACHE_ALIGN exists for performance reasons, not to provide > > dma guarantees as kmalloc(). So I'd say users of kmem_cache_create() > > would have to do their own rounding - you mentioned > > dma_get_cache_alignment()? And there's an align parameter too when > > creating caches. > > I just checked and the align parameter only ensures the start of the > buffer, the redzone start is not aligned. > > Anyway, as in the other subthread with Petr, I think most architectures > would benefit from an update to the DMA cache maintenance to avoid > corrupting the redzone. > > -- > Catalin