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 28BECC36010 for ; Fri, 4 Apr 2025 13:53:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 846946B0028; Fri, 4 Apr 2025 09:53:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EF146B0029; Fri, 4 Apr 2025 09:53:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 667906B002A; Fri, 4 Apr 2025 09:53:10 -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 404D36B0028 for ; Fri, 4 Apr 2025 09:53:10 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B9854A9D2B for ; Fri, 4 Apr 2025 13:53:09 +0000 (UTC) X-FDA: 83296502898.22.DAE1AD2 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf03.hostedemail.com (Postfix) with ESMTP id AF51220014 for ; Fri, 4 Apr 2025 13:53:07 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=QVh30V1o; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.hostedemail.com: domain of ptesarik@suse.com designates 209.85.128.66 as permitted sender) smtp.mailfrom=ptesarik@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743774787; a=rsa-sha256; cv=none; b=k/7BGfry5hTBRx2QpLZwT/dl/vc7voWVf/k0yP912D8oUjpwmoAwwle5uTZiMJMGW79oUd va6kOMTQrFrICmmqPwOHHXDLd+5Vk7fesjdMF/5g1xJq5UHtm3L8khLeFYGWa2wKsLa0y2 Hj+y3KMq59czSKbNtnP2f4Bx2k0pAWo= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=QVh30V1o; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.hostedemail.com: domain of ptesarik@suse.com designates 209.85.128.66 as permitted sender) smtp.mailfrom=ptesarik@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743774787; 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=s9afxtVdgS9vUHHQtF+8xIVdb7MB+TU6JgeFS7k1Dq0=; b=JvTOqnr93qJzh3Z4A99VfMS8s9auSgjhZoPFeG5YT4sVtNYfPymtXJeoqRUZRyHg4NBIkK cxiMKQYekbcCe7PQyaNLjqESDxba6/yWdRi+DBIgIUGXaYTn4H4JXUeWmfHpS2dtIG15tg XRBguKnIDBZT8ZaULUJvezW/OvQAWTk= Received: by mail-wm1-f66.google.com with SMTP id 5b1f17b1804b1-4394944f161so2319565e9.3 for ; Fri, 04 Apr 2025 06:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1743774786; x=1744379586; 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=s9afxtVdgS9vUHHQtF+8xIVdb7MB+TU6JgeFS7k1Dq0=; b=QVh30V1oiLHduDL8Pb+DauEm1gcYLZ05quCAk/OZDFa9eCDfsMmO48EqRtwC/tOpgl PNYaBCYqRVadQ3oQSG67ksQKIl1QGeyr+TX5WFfrO/s1to8jqs/c8EmyO7riASL2Oclc RJyZDWinsmTdg1GiEXUlWVlxmeehS0ctWNtf1HP6u7WqT6Giwy9CDJxMvg0NXfive5nL twV3UBOafzRxMfhf6KowePiIIxfit+9q3zrSLRRPQ9jkAhW3Z5p4X3Ta5+OAIavgtP+O 28okf57MJTBFyPYB1Wz6DM22tA9jDfkvIc7jQx7cvhJYIuMswArcAOX2RVUWHro7etdC PIWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743774786; x=1744379586; 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=s9afxtVdgS9vUHHQtF+8xIVdb7MB+TU6JgeFS7k1Dq0=; b=S0jfggbtMd8U+Oe7bxbyacsk6KYQtK5ds7HZsu7SmBy4MO0t0rY4luF1mLSOyb6asq Xy5+00LIwvzSHZUX8SKdVc32N/kEeHgKqp93fRBOM0YD1arJWhTVsdm9giU79FGQbiKn GTGmzo5ZjPB5nTU11o7t8wzI3RgBEGjMhr1ol+dYRO5oZZvDUR8exqQU0UcUdZjQqIqf x4RgYt7LPalQ4oLhlgJjdmjQnS3eiQFc4HXBI8JM8TJBuJVP/eoxTnf6TAC3CZmUiqsd fELAsDW9GuIqozXA7k+n0MnsNeDuKOT8xDyGemZVVGhJRGrmIEeXrXxHGX5GUMQO6joo qDRQ== X-Forwarded-Encrypted: i=1; AJvYcCVnkthFgAnNZBENUJigiHqd2eydlgb6owRo+AYRfOptffHd7tp2CfnBXOOzHN1Rr24HmO+jWHLobA==@kvack.org X-Gm-Message-State: AOJu0YwzkW2A7gG0P42RqHjvprNJlj1k4m3bIqceiGvCKPWpGdDh/wUR o8ML2y/eTsVslIH/FIMWu02M67DZwjUuQomy/4C89aHjuoIQwFm6rfmfSPmsjRY= X-Gm-Gg: ASbGncvEgl/5uu9RZoV2PpcNRQrbnC5Vdi/CVoppEqeYwbHF1ump0AA6kz3V3Cbfn7r r/rfjffpOR+g1uFzEgPmMQ65VZZGFdDPX5ZCRS3xh6x7SMHQ9v8St+ys33nU7+JGlhdyg+kJqIg XWPMb/Wbcv8TX4gO+dtCiuP2DZcW73C5mi39FM2uxz5ZJ0zRQJzQVF+vnKHrnQNt+rvxxMqKBUB rpyj1mWmxtQvXYP8u0da9+x/4LK51+rtYfeCE/6BXfkMSvg1QYzEfjZ3I78SK8Ct0ATgwlZcnrv K4xDC+9wLtQE/GYyfuHAn9iXYgqxCA4tb0gWpAmqalyaQmKL+KX95YwYdWORUX1UCCDBb4n302P VZEdXUortc5aV0SZYI8/IL2dkeoIVG54Eqr9n71k/ZSj3 X-Google-Smtp-Source: AGHT+IG92sIcFi/2rx7fHxHe2OSZM9VwtiflGXLC9LatmseS27xI4/SasPKY23KqgpLnQWwaVkX7dg== X-Received: by 2002:a05:600c:3509:b0:43d:fa5e:50e6 with SMTP id 5b1f17b1804b1-43ecfa4d720mr9751435e9.9.1743774786013; Fri, 04 Apr 2025 06:53:06 -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-43ec364d07csm46021525e9.28.2025.04.04.06.53.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Apr 2025 06:53:05 -0700 (PDT) Date: Fri, 4 Apr 2025 15:53:03 +0200 From: Petr Tesarik To: Vlastimil Babka Cc: Harry Yoo , Feng Tang , 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: <20250404155303.2e0cdd27@mordecai> In-Reply-To: References: <20250404131239.2a987e58@mordecai> 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-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: AF51220014 X-Stat-Signature: bmin9jgqhncyhhszzkqbn4npfdjybhe9 X-HE-Tag: 1743774787-640245 X-HE-Meta: U2FsdGVkX1+3Lf8l49uMxcjMT8YRDwmn3Q6RROaebPS7lhL3qj1lwasto4+BglMuz2IAiFfeg5OLtyPhZaIjAIKpvOAcpSe8HrS93iK1nJueKoxkjwi3K2rhFwnT8AUQGdVG5YjWhL89Jd3Hqkm8ik9y0H+KdX+9P0tDo/2Ffsuri4xXU96W9WGLGNo0tazaBjv/nJp8J+foyhghgoE+WnlcANu32ygwy+pZFSwRshdq4WytVfh5mRZholDOHI/ACVp/5PaGMvOt7PS2SrpDhjSZSzFGKQtPqn4MlZcHxzgD1/HSsu/hYltzQXB+0zk3kP4dKx+zlc6wlFPH37f2U/haa4vGPtiDTAPkbVXcnQR3WPvL1cHVPdAUkb6exhD6qbPuDanNQRuCYsALX0PUTiAj7+Khmi/Uq0ZLEpUx/8Y0WOYMGomEUWeBKO7CGX6y+aBsBUueP9X5Af6TWFu7BgGU2DN4tzVgyu30vOSEBmnlnuV7aWLQzr9qpLnu+vn9q2SrDozzqbeXLzlNo5SyPixZl8j8vMp3yBQ4xkmErzoE0EQyAkE+9+1yBAr3xIB3YCLYwkvxXMwuHx8wKjNzdUPCz6gZbBKwgGV6Zi4olaCyUkvhjhgjJ4T0ShpXx+3VqR40mwhqk0t4A78NogA+OS1E8/ilHQFPu9q0z4NbeBz6ZAM9nvdd0VDWRUwvRXoizfcNTzKkE6DzpWyLX9GNOxxtLAKHKmFZT8LoTn5V0konyB1Jp/DAtPzwHySBbThRzutiGnf2GHJ6iZl6qbnQwFwLIAkOFebbTU/bvG5ha/3m+Be42HLLkrj5IJL72v9w95VOXpneAUhZl5MRVHTJRJLTNXRp33nspMFnXWJUKDhGvZ8+LvO89NamVSPg3M6uAvhtI06IFYJ3JIH7qEz1Z31gf77te1WBtYh8v8mdOvfOWMBUjz6lfFO0YitQNnwgjL0IYl1rpN7EUkVlBQR +y/JGJmL Z9JsyXexCTeVEnbU1oev0LlNaa9f8uNXRKyVsBxzIHGy9UfaaTWtN88VB/+UH95+LEYIfAE5wPJqdf7xJCaLXloJ9xmBRN5OX0adaAdVY2Juteo26lAAncMfCjzeA0ILRDu7l6q93onTZU5Hch7tnCxDF1DK1yvqILOXQTMcwZJ93bNqOcUU3L3VjZOzdpLRZkK+yTPr8stmZrQFwMDgNd3EyZ+7o3lT6fV/Kv71zJ5DpIvHUz/DJZb9EnVLzpQahCRngJE30IjrCKCmxHk5WHyMS3xjfcNRIRv2EHmbt+pOXuWkJyIQgYxm+kwHCKiKSM6eDSxAJxOJKXVpVvfB2FNzmzOcl2a1vHL3pcJn5lbLoxK2tv9zv4e5h5siFia4uZvV9Ni1HTJG4ChFesUCvd258ycGau7ndP9onl9ulyBgg7zBwZpxyPKDfnhRgM1jmym3O//U4CzlM2rJTLc5yYUKA2lAIIzyozft2WjjndB6hiJrjrrCngruOqVizxNehmU7RhiSmk6lHY4XbyPbZakUZAEmmJ8DSS+ejijbRM8Z19PoheQ215/Jwqw== 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 Fri, 4 Apr 2025 14:45:14 +0200 Vlastimil Babka wrote: > On 4/4/25 13:12, Petr Tesarik wrote: > > On Fri, 4 Apr 2025 19:30:09 +0900 > > Harry Yoo wrote: > > > >> On Fri, Apr 04, 2025 at 11:30:49AM +0200, Vlastimil Babka wrote: > >> > Hi, > >> > > >> > due to some off-list inquiry I have realized that since 946fa0dbf2d8 > >> > ("mm/slub: extend redzone check to extra allocated kmalloc space than > >> > requested") > >> > we might be reporting false positives due to dma writing into the redzone. > >> > > >> > It wasn't confirmed (yet) during the conversation but AFAICS it can be > >> > happening. We have this ARCH_DMA_MINALIGN and kmalloc() will guarantee it, > >> > but the redzone check doesn't take it into account. > >> > >> Sounds valid to me. > > > > I'm not sure I understand your concerns. > > I'd be happy to be proven wrong and you're more familiar with DMA details > than me :) > > > Are you afraid that another device on the bus caches a copy of the > > redzone before it was poisoned, so it overwrites the redzone with stale > > data on a memory write operation? IMO that's buggy, because if a > > bus-mastering device implements such cache, it is the device driver's > > responsibility to flush it before starting a DMA transfer. FTR I'm not > > aware of any such devices, except GPUs, but there's a whole lot to do > > about CPU<->GPU coherency management, including device-specific ioctl's > > to expose some gory details all the way down to userspace. > > OK, guess not that. > > > Or are you concerned about bus data word size? I would again argue that > > allocating a DMA buffer with a size that is not a multiple of the > > transfer size is a bug. IOW the driver must make sure the buffer size > > is a multiple of 4 if it is used for 32-bit DMA transfers, or a > > multiple of 8 if it is used for 64-bit DMA transfers. > > Yeah I think it's that, and I thought drivers don't need to care themselves > because ARCH_DMA_MINALIGN means kmalloc() layer provides that guarantee > itself. I also remember this series (incidentally just recently the > discussion was revived). > > https://lore.kernel.org/all/20230612153201.554742-1-catalin.marinas@arm.com/ 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. @Catalin: I can see you're already in Cc. If I'm still missing something, please, correct me. Petr T