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 4B815C36002 for ; Sun, 6 Apr 2025 14:02:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1EF7E6B0007; Sun, 6 Apr 2025 10:02:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 19BA66B0008; Sun, 6 Apr 2025 10:02:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B23B6B000A; Sun, 6 Apr 2025 10:02:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E257C6B0007 for ; Sun, 6 Apr 2025 10:02:51 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6E2351620BB for ; Sun, 6 Apr 2025 14:02:52 +0000 (UTC) X-FDA: 83303784984.09.D5C8E07 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) by imf01.hostedemail.com (Postfix) with ESMTP id 7B32C40014 for ; Sun, 6 Apr 2025 14:02:48 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=b9FBSqsH; spf=pass (imf01.hostedemail.com: domain of feng.tang@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=feng.tang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743948170; 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=g4oTIscPMw0agpNifJTUKbokYUJ0mviKpjyszGxNc4k=; b=5vtcbfodUziDI5yCWyEf+UKWo9LF4KLH9YTILjAiaz+UKWlJmnR6PW6wjkhAqyxzGK3vYN dj30d5AW11k59oGc37E9PJaaW85UxDAsA0j2h7/BAPBPr5f4arozJAwBeuwpYUIehyjfk7 2/oHYwLY3rTcjzls92LSAEv3b30NNV4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743948170; a=rsa-sha256; cv=none; b=t0dBMf3Vbwvcs0RM7qGqMWwiIG1BV0noxTEuLcAW/OaE3TSc+adrIHvbUwOn4BkuP4UuA5 J+Fc0MMxaTJ6jIaTIA+/ZIRyB8bqmCjhG/JqBfRWEebkr8yrZYCfHUIiqTXmsSSTaZ6/CE uIIbMQOimfp7/BJfW9WMxuZGYgVbMTY= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=b9FBSqsH; spf=pass (imf01.hostedemail.com: domain of feng.tang@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=feng.tang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1743948164; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=g4oTIscPMw0agpNifJTUKbokYUJ0mviKpjyszGxNc4k=; b=b9FBSqsH1avI1ostkA9+owjFjdx1pZDkYiVic03qQS3/Dxvt0eN3cBNNk9Is76SRng66SuEgk9ttws+Ym70iJYxMZSC+/tXjERN8w11yjgqDygt3au9mJuXdtZ1Qb7mcW1mM7sjdH89Cot/o4gaGRMBdBSCHp6Iy3niYSfxNLIA= Received: from localhost(mailfrom:feng.tang@linux.alibaba.com fp:SMTPD_---0WVa8m-q_1743948161 cluster:ay36) by smtp.aliyun-inc.com; Sun, 06 Apr 2025 22:02:41 +0800 Date: Sun, 6 Apr 2025 22:02:40 +0800 From: Feng Tang To: Petr Tesarik Cc: Vlastimil Babka , Harry Yoo , 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: References: <20250404131239.2a987e58@mordecai> <20250404155303.2e0cdd27@mordecai> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20250404155303.2e0cdd27@mordecai> X-Stat-Signature: qkgrk8w4myrgbimsixrtcei86y4qtmwm X-Rspam-User: X-Rspamd-Queue-Id: 7B32C40014 X-Rspamd-Server: rspam08 X-HE-Tag: 1743948168-440352 X-HE-Meta: U2FsdGVkX18sJWQPfT1RmrVGvK24WkBpIhWe7iwHrqCkBwPFsr4r4+jicZDPPjdYOBn+IOOQ1d5lwJemxfX1/FL5GgHG2q2JIfWGF77dxHYLMZnwfiAYoPq9CNTz7e4tFq4SuKQFxkdvov64k0Nw89z8EuJ4BZNy2GqwCM3JdE646lXfID1QztWyxWqE9MdCLCWDy8c/mJ3bIvsyUgb+ru5LqgZW12CVlTJFiUVRfzQ/fYLuMg/Ul2zxuDiUlaai6M9edfhFdiNBljhb3KciD3jK7I+/jC71dQJvaxjFkIonOZmR+JkC7QifKqHpxL/++QB+qN5o9Dhvrm4mV21E0KVxdztBC/sLQuKoTixvswXtK2t65kzIk/DDwQK3cMgcl+SCCwReqkVlH4fQBt7VBEr+7cuEZukTclOnXnFkEqkdc4PLywcxhWVnqGTwSw6T8lGZakVlENKdt0W2/7MODnAxKWN0Cu8RCXJy07IqsIy/JTzkP3M53dudIsnUvFhKf9rt1RuuynTkBKCOCJ89KZHYhWddvAuTTQGyjM3vuC5w3A0MXSdAGuv5BwDtVQa6lXCxTxO7KTrlgzxl+jXg14y34C3uOdQOVywwHWLujMI/z+a1nTxs6kkbXNBYAPrSeuHttvCvKNMGOJR/jPiT5UiLuLgAwwhtQKk++mh2WswaAi6zTTbHkpIjQqbDlvvLsIbzTuHGvWQlfdgE4k3XBC4WY0/eHajTvlpZJay0pTi/7da9GGOuTJ/YYWO8+j9XvsU1i38w797cw36p8TJ8flc+fnYWVpkfkKIxSz012yNn/rJ8HqogGOGlzxokA8ES5u5tRgLp19CYa66uzx+PV8FvHD50+lAbfK5iDQv65urjHF8a9Ml2PrmxMxUxTMjiXqspIGM+Cz6mOsHvYyVIRH+6R9vJNwQqMuX/Rwldp/DwCj/dGZvo6didhPd65oIAxP0cAZrvb4j6I6SIoQm 5uetsIh6 /PjHB6TsAZbH9jo6RjXh9qHgSxT99o5IZW7AqmlNgpBITeiUlDMhTHjlf5IOULAcYUiqLpMzsbnaZyU0V9/YVjxM9Vc19TUNHY+WFCN4f5d/ICH/rwgcePUtS+DyS/YVJiiOPaJ4dAX3wcKKARprJZnpUvjb2yN4Jwf9oW6uZlGMv/v9Ao6dpWKW/lpe8WtelbMSQKg2e126I0L3qJntJSEjm1DysQ1SrCT16iVlslBk4UCoHvp20iLFpb03G0Fa9ztKko0GJ6eghLwYH0QYQ/kxfKnHO2cNH1XzsSeYPNj5xu8GVFtmTH0ZHg+rmS/NUHZxv7J9tCkriK7s2ZEOBYF097o5iwRw5uei3ZQbC397XZ6v6ZXrL/X4kFiIsA6UKof6vJqK9WfFQGL2eKzBQFYpjYSRHin0CG8p1+wgKskxhHzQOB+2bbNxB+tv9evOTNyV9r+Da2ShgWT8z2JzQgdsceQ== 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, Apr 04, 2025 at 03:53:03PM +0200, Petr Tesarik wrote: > 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. I alaso tend to think it's better for slub to detect these kind of DMA 'overflow'. We've added slub kunit test case for these in commmit 6cd6d33ca41f ("mm/slub, kunit: Add a test case for kmalloc redzone check), which was inspired by a similar DMA related bug as described in commit 120ee599b5bf ("staging: octeon-usb: prevent memory corruption") Thanks, Feng > > @Catalin: I can see you're already in Cc. If I'm still missing > something, please, correct me. > > Petr T