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 D27B8C36002 for ; Wed, 9 Apr 2025 12:22:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1AEB928007C; Wed, 9 Apr 2025 08:22:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15E1628007A; Wed, 9 Apr 2025 08:22:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0249028007C; Wed, 9 Apr 2025 08:22:08 -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 D539928007A for ; Wed, 9 Apr 2025 08:22:08 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D8AAC1A08B0 for ; Wed, 9 Apr 2025 12:22:09 +0000 (UTC) X-FDA: 83314417578.12.7CF628B Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf05.hostedemail.com (Postfix) with ESMTP id 9AB15100014 for ; Wed, 9 Apr 2025 12:22:07 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=wKHlbZh8; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=HBdEnJi2; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=wKHlbZh8; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=HBdEnJi2; spf=pass (imf05.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744201327; 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=IHFVbtv5Y0owikv2RXV8N33bnjeqzNDAIQFZ7qr6w1Q=; b=yizc1N9bhp6oKeSLzuMtRaEOfkxgxliY7UqvnpfwWPtWsCH5P3ET2L6/e9TibDs+BSHfQK R3Go9xQkFCjgAlFY/BIMRfl2e50o/KuxdY22n/CPXcMpWflY55GT3Bv3L3YZAj62HcNAQ1 V9r2CIS1lvBiWPX54pTyTxRYyLeuCHs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744201327; a=rsa-sha256; cv=none; b=SDTc2bnHjy5ZvWKhUaG8l5tOxsEb+OdT/P8wpI0KxR0u4uePDxzsvIF0VvtmTmATziO1B6 Kb86A27zDwGJAz5nzsAN63lDMhKcHtl1jkbaB+/krknAGwjrXrMCCRWRTnfkOES9wSgTbY 7g4n40KgEmnWPi1R7ncBMFDOHKwz/dU= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=wKHlbZh8; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=HBdEnJi2; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=wKHlbZh8; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=HBdEnJi2; spf=pass (imf05.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 025461F38A; Wed, 9 Apr 2025 12:22:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1744201326; h=from:from:reply-to: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; bh=IHFVbtv5Y0owikv2RXV8N33bnjeqzNDAIQFZ7qr6w1Q=; b=wKHlbZh8hRhS2ZWCsvekOoW2lSX0mp9BQ1ebXhjEn6sY2sY/Mk3l920AOkejxVoI4ZryNa BZXDfCkYVHIpPUsuWwRhtteYskZE8DziaH8NtXf9rJVsS+0j+dRJgXCn43oCpCXl5igq9t zoej1RxlWujwJLvr9CI3dHYzP9hKOKU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1744201326; h=from:from:reply-to: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; bh=IHFVbtv5Y0owikv2RXV8N33bnjeqzNDAIQFZ7qr6w1Q=; b=HBdEnJi2UyC/J8A+qdfZ/gmGROSzsXwtVR3frTA0sIjXWJdqXefT0lIBa+rLOcZI3fFG79 YUe0EWVvDd15VnBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1744201326; h=from:from:reply-to: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; bh=IHFVbtv5Y0owikv2RXV8N33bnjeqzNDAIQFZ7qr6w1Q=; b=wKHlbZh8hRhS2ZWCsvekOoW2lSX0mp9BQ1ebXhjEn6sY2sY/Mk3l920AOkejxVoI4ZryNa BZXDfCkYVHIpPUsuWwRhtteYskZE8DziaH8NtXf9rJVsS+0j+dRJgXCn43oCpCXl5igq9t zoej1RxlWujwJLvr9CI3dHYzP9hKOKU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1744201326; h=from:from:reply-to: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; bh=IHFVbtv5Y0owikv2RXV8N33bnjeqzNDAIQFZ7qr6w1Q=; b=HBdEnJi2UyC/J8A+qdfZ/gmGROSzsXwtVR3frTA0sIjXWJdqXefT0lIBa+rLOcZI3fFG79 YUe0EWVvDd15VnBw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D6B7E137AC; Wed, 9 Apr 2025 12:22:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id KRgxNG1m9mf1KQAAD6G6ig (envelope-from ); Wed, 09 Apr 2025 12:22:05 +0000 Message-ID: <53cc9e92-8a57-4989-af4e-26ced40de91c@suse.cz> Date: Wed, 9 Apr 2025 14:22:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: slub - extended kmalloc redzone and dma alignment To: Catalin Marinas Cc: Petr Tesarik , Feng Tang , Harry Yoo , Peng Fan , Hyeonggon Yoo <42.hyeyoo@gmail.com>, David Rientjes , Christoph Lameter , "linux-mm@kvack.org" References: <20250404131239.2a987e58@mordecai> <20250404155303.2e0cdd27@mordecai> <39657cf9-e24d-4b85-9773-45fe26dd16ae@suse.cz> <20250408072732.32db7809@mordecai> <42cb9ae4-e479-4f52-8e4c-f4bc3cb54971@suse.cz> Content-Language: en-US From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: 6o39df7eg9eq1rz5gs96hw6fc1taxqkg X-Rspam-User: X-Rspamd-Queue-Id: 9AB15100014 X-Rspamd-Server: rspam08 X-HE-Tag: 1744201327-888537 X-HE-Meta: U2FsdGVkX182vCZD1Pfcb5ZVc6tgKW8Ux/KnocYPbnKFF9vswqmUr7vgx6KRFMACLSoP/qrXhwYgLk0ed2rUAw1XgrOT8Q33hPOM/JW2vfYo896rKd0EdQEQjZnXmv2/0NuYa/RSw3mgForx1GozdWL3+At/eoLDQOJuUpjHjzb5K20Ikr/b1+J4HnKRs/QLmwCWs7LYkFQ6LvtgcLHbgFytUIP+9taHnEeHw8RRSIbS12NQ5bUFP9b1NUV9ZJVRwCctlugeHwwHEFOoioSWnQw1UBm4f/CghmrJMtFayVjJsAi/Dz1SsQfZ9e67tqAGWTjr9QpmZGNI9iKtiH2DQIjvUtZaRg13sRe0u+JgnyhU2M0Xx/nLbv6KuOqXz+QtYfdsnh2qyn2H2S1+5Az2VzG04NhmcdoZ4ya/EgfZ/Wjc1U1buQj5EVyyN5pihCpsh9KTWbdbUqmxbQFpZ6FSGl92lsP0dh6X/d3A/P5lD2Mbt7oXtM3YpqO/5tCln2eCz5/cdvOMFY4uxA3U4rJyEHomJySe7rwAwHFl+y+VF6116jTW9avlwCTI9Cl5jwX0GSx8rZd+X7XY6sQlr2MEKhqE1lLgmmyLuywkZ1rCvrYibSbI+Dqzc5v+D7IhpU68+5vzcoKzUQO/Jo+sfIdJah1f0IB9uhZNZV3/bosEZTyxZOjGpA4HssF05geasliyq0zWKqcDcUK2VJ1Pj3EhsAqyhX6OeURvhGJM24xr++FWBMWw6/SqvE2s/CqYr2ZwEeRuXVDwCA9Tk/QhOj6z4yIHC1fpMn0NWeb38lvONFjRQUwUn3nMoICKqMvtfb2lnIeaifV/O1ZgG26Gs3QWkd6Y8HiErFgmK3qfL8HMR0aH1Fp8HlpwpxaxHaWkeNKetvRpemA1zdStJd/4q1eKDyh01JHDMnxrRC/QOG9dGIpMgf0HdKfdWgRfxfSQvSEFKItnhDDG7I3qnGOFBCw r2ULuej1 CvPBZQ7jK/k/wMtWQQ8/S/aCUf2R7Jbg6rF8qUzVaIw7PQla1pG/41hHRbu3d7BAnbTg77Ttf3V3krr2SlMUZAJKYeF/9zKRL1S6kfDYl/Xv8yNsWFHKVO18AqNc0PbKhi4V6/HztGUaodA+FiwPtidYs93X1M8ObcTNF7SDZVVKlZ1cK6i6U4CXGn0oFeKYpbhGm8zkVcdVErl/1ReLQH2dcvekj25h1hhApyPjEWfWGmcacCmlIR1RLnoVrrnhzo3FYhdkPLn3wWNvsKmJRhnj2jo8kNO08Z1cPaPVZsHETGqlwaawtt7aI2qbEupieG5RKC3lDo/a9VxOkgUH9TaDzK+ScZ7phfysIpKtI9wrsng40BNJL4mKjndiyG51laVq/WhdybiEWPcE= 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 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. > 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. > 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.