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 06B72C36002 for ; Wed, 9 Apr 2025 13:41:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C00CD280053; Wed, 9 Apr 2025 09:41:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B875A6B01A0; Wed, 9 Apr 2025 09:41:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A01B8280053; Wed, 9 Apr 2025 09:41:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7F45A6B019F for ; Wed, 9 Apr 2025 09:41:27 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 63AADC0B19 for ; Wed, 9 Apr 2025 13:41:27 +0000 (UTC) X-FDA: 83314617414.09.C112B39 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf22.hostedemail.com (Postfix) with ESMTP id 5BC0DC000D for ; Wed, 9 Apr 2025 13:41:25 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=HAgR4TkY; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf22.hostedemail.com: domain of ptesarik@suse.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=ptesarik@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744206085; a=rsa-sha256; cv=none; b=Ti9tfDdwE08u4ZvZ20AsNGJLF/4JnPwjQsxLxVxjNGSlYmKA/vB27T6Vsz9ehiCOGzptmo TN9LvFowk9/sr7zVmSLAMc9onVopFTckmuYkmjPeLzSmor7wryu8Voq9sCszxGqChI2+ZT FxONczn0N6szB5nYC3kSEv5xSHCoeiM= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=HAgR4TkY; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf22.hostedemail.com: domain of ptesarik@suse.com designates 209.85.128.47 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=1744206085; 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=h92ppK/OIAL9P2R40VZm1ovaln7RGxYSPeQrnsxBeW4=; b=YwipFhU6UqXb0+PlVaQeyK2Y4imuZ+10hA1q7KZATOR885D9JGAazIKyrV7mIcroaJwt5J bU99x9fOCfheRfq8CUYow/CVbjcI34QG5fBul8YygYVtZE6RCk4ZelvqEAcOW+s9/yNOX9 L9inO0oJlOZRFT7AY0QjdaFH4/qfraw= Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-43d0953d3e1so4142695e9.2 for ; Wed, 09 Apr 2025 06:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1744206084; x=1744810884; 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=h92ppK/OIAL9P2R40VZm1ovaln7RGxYSPeQrnsxBeW4=; b=HAgR4TkYs2yZTbEp9mwdA9bAAB9YQivuHRT1JGRoyZsmtN1XDfAkhrmQrQm3ztJm9W bhw7JIqVyCPS/qJmSgqLcUrfbyrepDs9aPW2yp+GVrLifRIkoYKOrTLSqz3PtK2AsIlu G6z2W0v92gbvcoHB2RgVj9Snn8Nb5UGV92ENbXYTuMKO7da136R4jIyMljOu0Jx0Hdhp sdpXPCfgpRnGqGWkPUITyu9LsjEaerFw5LSibKKNyUWmh7x+saHZ4BtRUhB+MBckRVSc 2Yaws8HHBhuPgQ0zO5fqSpVxdd49eSS8EncmfxwSflrZbxzkLHGrgVW4+ELvMcS5shDA DYmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744206084; x=1744810884; 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=h92ppK/OIAL9P2R40VZm1ovaln7RGxYSPeQrnsxBeW4=; b=OvAxgiMmZ6mcEv+sjPjSH+/hpmdGyr/9SsiFj3lzPKX0jl/ZX+cSBPUjXw31REdoml T1dVoj+1lVtpxqFl7I2RQT2iix2ZRaY7i20eBdkDQQlK7dI0DxEKnTyfm9tdLxXzDPsJ ZbQ1TkYIxq8UWWFVk8xIJ/QOHNKJk2yvQfUAEwY9UexNkL8q5RsFgVnSEd1Fu4IRLV94 Ff2BsSXXPAJtoyhUMbAYzNGbEUOhkdkGwL8rFZLPbF5+w7c74kMc50/e+hqTdrXSqxF3 ROv1kAQvOEJrKwTymJQgcMwGL8TswuqeEzpHnteOzplUFF/MXgJOLOKPqF1zIeHcOviu qqYQ== X-Forwarded-Encrypted: i=1; AJvYcCUdU9yneC63GDJKZm66yn9AakoW25664Qv7221GHeMaTLb6xeLDKTy4x/HnOZK0M5uijuFq6vyV2g==@kvack.org X-Gm-Message-State: AOJu0YyNtHyzKrQiRo6OGcqDUgsl8T8WMHIerWMoa4y3wct5OODQKpj0 8Xe+nVW/Idu4Di/HD80MZ8hC+YXiPXrOumk0OUUexnISjSlXjJ7ifciIQSFE+tA= X-Gm-Gg: ASbGncum/NaWwib5wsw0hxoGqcpdu7cHccl9Yp1PYy6/ydIoijTgAewcGF5CpusF3eQ X2/EXqbCQDIjm3F6nIDrwOUzyr4Y2Hj3VrY+ChfpbXhpuGN44RJfCdgQ2aw8vPO19A+79e29Ekc d9fP8pwC7KW8qdgiMTNqKaga448vnQYIEmSZhj2V1cdGdfh19eNGkh/u0mZzHUDsg6LAcNnEIxK /64yJOKjgZR5uKHvilzt/Yi65lslMp1F2VMIoVKEJILXfEZzMNfeAr93oSqO+GMap+K8Hj90oOg /WgXRS43iCbuQKJw2+tfuUyoHzidqdDrywXSizdySZ12IQB4OfskxY1OTHpQB/6RWXcnYrrcCEN h/F/c4I5WE3NlV9JDs+cYG6jK/LWE3Q== X-Google-Smtp-Source: AGHT+IF7P0V20p61tY7UIELl24ta7Om+lUxB3dF9Q/2WXgHCJIIQw0X7Pz2Y0KqLkpjETYapiOpI7w== X-Received: by 2002:a05:600c:4e08:b0:43b:c0fa:f9c4 with SMTP id 5b1f17b1804b1-43f1ed4c8f8mr11052835e9.4.1744206083741; Wed, 09 Apr 2025 06:41:23 -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 ffacd0b85a97d-39d893fdf6dsm1710568f8f.90.2025.04.09.06.41.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Apr 2025 06:41:23 -0700 (PDT) Date: Wed, 9 Apr 2025 15:41:20 +0200 From: Petr Tesarik To: Catalin Marinas Cc: Vlastimil Babka , Feng Tang , Harry Yoo , Peng Fan , Hyeonggon Yoo <42.hyeyoo@gmail.com>, David Rientjes , Christoph Lameter , "linux-mm@kvack.org" , Robin Murphy , Sean Christopherson , Halil Pasic Subject: Re: slub - extended kmalloc redzone and dma alignment Message-ID: <20250409154120.2cda65cd@mordecai> In-Reply-To: References: <39657cf9-e24d-4b85-9773-45fe26dd16ae@suse.cz> <20250408072732.32db7809@mordecai> <20250409103904.54a19faa@mordecai> <20250409110529.3ad65b3c@mordecai> <20250409141816.1046889f@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-Rspamd-Queue-Id: 5BC0DC000D X-Stat-Signature: t3qiz79yif9pb6fowfs4hdrnukrsj48e X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1744206085-786800 X-HE-Meta: U2FsdGVkX1+IF6FX7ovmbSbv/+aRWFBpDycfJs0+dbdG34bAm0LfarREIry38Hq5bd5UVU9Q2sPZOmDmhpwdtN2Jf5iMh3r6h719AERl+RJ7/dllpuEDHifXze0nGCkXTqid4QSUoBdYA/0VHdm+/K4e6y0HqCFfOKgV1aQN0+c+i9VavTglI3bWzxjp8z9uQRBpw6eSw8cCaO0BN8BaYWfiPRpI83NxuWkKUGPUFCg5bJF1BugOeeF5llAp0g65ABi0ZJgzi6zPKf0tqd1yOEs9PFvMZ5vQuw2/X41Gk8Vpesz5ta+1tw07MCuQYetEYIabXfjsR6pIgWek0b9yt6ApRujODGC1LWQRBnk2N7WmRIBC1NQC0Y7SsDIOhuKVIm/+sFXzdh0GzmmRsLfFxDdGbmYy8aoIhtccUyvkaXLXxZK0wTTVps4SDAep6MUPKDwvPQGc7Th21Xz9c6Iq2eao8swwePQoqKCPZwSVxr12a2hzbxB5Gn83wDn8EZZWjhZ5ffMR/tztES0g7NX2dBHKnaf8z/vSNg151texYPON8tWl1Rsf82JJxA2jUjgKaZDpGcy9JpCLfwYSuWSVf5h0MUGUJJNXgmwPOcCKMBE7dRsmL1hmGTCfMy9brdn8QzhJuqfPub4z90yFzXdc0as86gPZAJ+bZ+U9MmOHM8T6ZQaIMdRKwGbFE8ATljNcAhKLKH9QtV9aPCdXY3JiZSVUMgxzrf8NcDgBvobEDuouAsj+htv4FpmCspblSqyja6G2fHpeeBDvWpS7WUBuo7QrqYf4lqg9ayumU6Icec2VG161TNdStfOnnsuJWMdiiriClp+Z3Hu/OV+EeiEAPQIftLPLAcdR3S6vVplhqOf1BaTKOvl2zSxbm0O0zwvVkSWtYIjm410lyodH7EvJZPFJOKyuP3nxT3AMC+7VSoWoWUimpRhLohpOZWnRC2i13WXFPA4xLItqVAPKBl3 nQoGtLMN CYIvhM5fW0qYfd20ny8eI6HixsfnT3T3CHMMPbpflrUQVbU9q4QkHoRMI3ZSR9O+p4TNIhP1vn8AWGvWcEwfOP8qRGnjBD/s/Nz6W5KyKYFIUio+RFUc9p+Xif1JRttfhTlXN2UsfApM2ogpA7LUyHrLkQTVVvhDnQK7rWTYi/Xf9kn5rD6rsQ2HTnMrjM1Ec4oglY+VDKXwER90exOPXLS4fwZMnRFLSau4JuEyvMwPWlxkH65t5hqTF3Q+fJtadG+CNHFFgV/ImKSpcRJIqxUZbf274Mbn47oWXdN1cs43UClJK4QGTgTNScz9jUEA7OLqnIuVSQx7Kz7QwPTTGqfl1AwZhty1QAABdymDXfaw3OmhQimpPAQgNIAa4AHLE5OseWPT9DaAb2d8o6DS/T+iNieuuyA2sIeMrTc0ENe8ZiZ0aXTyxoVez32MTo4g0m0j4XCujGUicZLK4ISEo69YmSkLED0A6MYBxKeIl2anmrkE= 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, 9 Apr 2025 13:49:48 +0100 Catalin Marinas wrote: > On Wed, Apr 09, 2025 at 02:18:16PM +0200, Petr Tesarik wrote: > > On Wed, 9 Apr 2025 10:47:36 +0100 > > Catalin Marinas wrote: > > > On Wed, Apr 09, 2025 at 11:05:29AM +0200, Petr Tesarik wrote: > > > > On Wed, 9 Apr 2025 10:39:04 +0200 > > > > Petr Tesarik wrote: > > > > > I believe there is potential for a nasty race condition, and maybe even > > > > > info leak. Consider this: > > > > > > > > > > 1. DMA buffer is allocated by kmalloc(). The memory area previously > > > > > contained sensitive information, which had been written to main > > > > > memory. > > > > > 2. The DMA buffer is initialized with zeroes, but this new content > > > > > stays in a CPU cache (because this is kernel memory with a write > > > > > behind cache policy). > > > > > 3. DMA is set up, but nothing is written to main memory by the > > > > > bus-mastering device. > > > > > 4. The CPU cache line is now discarded in arch_sync_dma_for_cpu(). > > > > > > > > > > IIUC the zeroes were never written to main memory, and previous content > > > > > can now be read by the CPU through the DMA buffer. > > > > > > > > > > I haven't checked if any architecture is affected, but I strongly > > > > > believe that the CPU cache MUST be flushed both before and after the > > > > > DMA transfer. Any architecture which does not do it that way should be > > > > > fixed. > > > > > > > > > > Or did I miss a crucial detail (again)? > > > > > > > > Just after sending this, I realized I did. :( > > > > > > > > There is a step between 2 and 3: > > > > > > > > 2a. arch_sync_dma_for_device() invalidates the CPU cache line. > > > > Architectures which do not write previous content to main memory > > > > effectively undo the zeroing here. > > > > > > Good point, that's a problem on those architectures that invalidate the > > > caches in arch_sync_dma_for_device(). We fixed it for arm64 in 5.19 - > > > c50f11c6196f ("arm64: mm: Don't invalidate FROM_DEVICE buffers at start > > > of DMA transfer") - for the same reasons, information leak. > > > > > > So we could ignore all those architectures. If they people complain > > > about redzone failures, we can ask them to fix. Well, crude attempt > > > below at fixing those. I skipped powerpc and for arch/arm I only > > > addressed cache-v7. Completely untested. > > > > > > But I wonder whether it's easier to fix the callers of > > > arch_sync_dma_for_device and always pass DMA_BIDIRECTIONAL for security > > > reasons: > > > > Then we could remove this parameter as useless. ;-) > > Yes, I just took the lazy approach of not changing the arch code. > > > Now, arch_sync_for_device() must always do the same thing, regardless > > of the transfer direction: Write back any cached DMA buffer data to > > main memory. Except, if an architectures can do this with or without > > invalidating the cache line _and_ it never loads cache content > > speculatively (does not even have a prefetch instruction), it might > > optimize like this: > > > > - DMA_FROM_DEVICE: > > - arch_sync_for_device(): writeback and invalidate > > - arch_sync_for_cpu(): nothing > > > > - anythig else: > > - arch_sync_for_device(): writeback only > > - arch_sync_for_cpu(): invalidate unless DMA_TO_DEVICE > > > > I don't know if there's any such non-prefetching architecture, much > > less if this optimization would make sense there. It's just the only > > scenario I can imagine where the direction parameter makes any > > difference for arch_sync_for_device(). > > We have at least some old arm cores (pre ARMv6) that have a no-op for > the arch_sync_dma_for_cpu() case. They rely on the for_device code to > invalidate the caches. That's why I suggested DMA_BIDIRECTIONAL as a > cover-all option. However, such default may affect the performance of > CPUs that would benefit from a writeback without invalidate. Er, like ARM9 chips? Well, if even _you_ cannot test on those, they're probably not worth the effort. But yes, there might be another niche architecture, maybe not even supported by Linux as of today, which would benefit from the optimization. Let's keep the parameter. > Basically what we need is something like: > > if (dir == DMA_TO_DEVICE) > dir = DMA_BIDIRECTIONAL; > > We could hide this in the core DMA code (behind some macro/function) or > update the arch code to do this. I don't have the setup to test all of > them (I can test arm64, maybe modern arm32 but that's about it). This sounds like a good plan. I've just grepped and there's exactly nine callers of arch_sync_dma_for_device() in arch-independent code, plus 4 under arch/mips. Let's make the above an inline function. As for naming, I'm delighted to say that sync_dma_for_device() is not yet used for anything. :-) Petr T