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 7A40BC369A1 for ; Wed, 9 Apr 2025 11:11:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B27E6280070; Wed, 9 Apr 2025 07:11:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD831280068; Wed, 9 Apr 2025 07:11:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 97929280070; Wed, 9 Apr 2025 07:11:27 -0400 (EDT) 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 78A9A280068 for ; Wed, 9 Apr 2025 07:11:27 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 735AB140585 for ; Wed, 9 Apr 2025 11:11:28 +0000 (UTC) X-FDA: 83314239456.25.4650444 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf07.hostedemail.com (Postfix) with ESMTP id C17D340005 for ; Wed, 9 Apr 2025 11:11:26 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of cmarinas@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744197086; 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; bh=MVvkzcC7DoPQojrUqpnlfMzXirCjRc9DpVUNM2Ke7AQ=; b=yAaPVdRvkBiKYmcOna4E2MyTaoVqWDtxdBC1j9IEAov6q9u71KhNhqahkpjz7It3qfvLu2 EN5bbO8HRpkyrsZ5Ffto9LeXgLik7JMhXk+xtFJ9SXS6Jrl/CJNjVHh7APAkac1x0MM8Hm INfwUTiVDwCvhFk2khmK84TPjQaUVY8= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of cmarinas@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744197086; a=rsa-sha256; cv=none; b=4nR2ad4DquiTVTJOiPSU83SsXrhVzdrq4h8YG82T7YnPReoDL8605nEU0w3DOXQrJRoaNF avLi9YMT2ZVOJ5SdMNAaqTSJtbXU5naD1V86f23reeskeXypuD9OflpIrNy7VfTZpKmdeW loEVNG66R72EROdaGuSjHDsVXjy+cIE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id B2B62442E9; Wed, 9 Apr 2025 11:11:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 949E2C4CEE3; Wed, 9 Apr 2025 11:11:23 +0000 (UTC) Date: Wed, 9 Apr 2025 12:11:21 +0100 From: Catalin Marinas To: Vlastimil Babka Cc: Petr Tesarik , Feng Tang , Harry Yoo , Peng Fan , Hyeonggon Yoo <42.hyeyoo@gmail.com>, David Rientjes , Christoph Lameter , "linux-mm@kvack.org" Subject: Re: slub - extended kmalloc redzone and dma alignment Message-ID: References: <20250404131239.2a987e58@mordecai> <20250404155303.2e0cdd27@mordecai> <39657cf9-e24d-4b85-9773-45fe26dd16ae@suse.cz> <20250408072732.32db7809@mordecai> <42cb9ae4-e479-4f52-8e4c-f4bc3cb54971@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42cb9ae4-e479-4f52-8e4c-f4bc3cb54971@suse.cz> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: C17D340005 X-Stat-Signature: 8is8jcns9xdfcg49zkasox577qh4ydjc X-Rspam-User: X-HE-Tag: 1744197086-644264 X-HE-Meta: U2FsdGVkX1+fUqWhy23GhZSwYKidMB3HFadb3juDBzvly7J7Kr5E3AROoxHsnSdia93t6ho7YLZez3mKqtsFhLeDpbEjmEAH1S5dvpMkZgqHygLaD0KpJ1EzE89L5tql87X7zqz6U11m+WQHpblIquXNjjL8mWtyqxcff+MuURWaA4im9oivM3IbOwJYP82z1Wxr4mYtqkpGJC1A5hPwWsRZBOVuIGL6dnKrCCpPTn+SeXq9n/G42fiaucNJSq5CjviAXYmeMyBhL9Xuktu7SrK79UxuxPlMIRsAX+eR4/UolTD92Ncnx470/Nde4jSZcHWzlWkEEtYOaJztMrZgCtzv/CKfPbGpspEU2mk/6gPkeYQ3piWtelc/lWtNudaD/7Y8wJuMAO3zYzAzuotBc9ZbfbjH0TSygnww+/1XvvQLSCAupaQ4vPaB/I91K+u9fLqezBUlPSBpZQ7RxCd3cz+dP75lAte3nqW3qXxq6ZqhOddHggy6WM9nqBl5Hb9qUdULWu7N7zDbRfLHgU1atKNLTMAJxQy4BGiD4hQFd54U+lAJ+xe5yQbPPDV8NEpiC6Bhe7tFgpBWZ1TX5Yy1wpLRwUe5THRwswcdjv+8/3+veH0RnHg8xLvdwKpkQl/M5BgtzW5Sx6gxCl7shEPRR57bNs3T2INsbckj8RoBumpkjd83tpMR5R3KaXYZLVcABDpc+tDtayNGKUEKmeVtU/N+EiP8eBxznsC/sEhbnG6Z8fszTSeH5ygSVTamknNyaA73OgOr3RnjLqgOm7DMgzSORT1yWdPC+cqpgPzJ+eNSZr9dInpr1bwI3A1sQoFFcSPHIrtxi78pefK4atB6AEOJ/SiYLDXw01R2KH2my7e/5LgX2Mrptgl4nGbXM9Y5gm/zrhyRmi2B6Ui5XZ50FWkht0+xRdy80tmVa5zwQCj4cBz5L/SIPZxa8zQPI8nJPB5EqKu+3OE/t7wKnLp t4aVwoon FvMWfAfE/HhK5Zdf1e4P2GCOtl8mM95qD3brWnLOtjrsGmtM51DrOARvgKKiXlL12wSrVFchUzyQoOJSE+TpRvM1ILgdNpt2M7NAfF0/2DDHJqIw1Js5q7ODgvS0G0kbp2FlXTyEz8HXATLLg2XZZ/YstPLeFEhO7Mz6HiaSO8cogtIUzv0AQuf8G7YHDjFTUDyoM/Yx92rYfGNm7CjOYSHWgC83lz+CgWdXwOn0zrPkUgZ1lcSPYI2EXorUjeKC/4e8PruTUKpv6LMI/gEWxzMPkxdi7q2p67CzrblRTQS6ask4vMbsLaAfWTZH2/SIhWi5Ht0eULZRNd7ztob78DtiWivuZB+ZUaj8yT9CaqnkmlStEtaWXAmjbFxyqoZsJsjpZ2TBXKm4y1c5KJ689nVpjdJ0TJrM/U4rbydfGC0nYFFj5SofPazWRUme9ZrMMcA/RZ5UU4OOHmgM= 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 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 are drivers that have a problem with redzoning at the end of the buffer. 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. -- Catalin