From nobody Sun Feb 8 05:08:58 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B467326B098 for ; Tue, 30 Dec 2025 10:16:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767089770; cv=none; b=fG4jO3hlI+DEVnlPPL/4foxEFo4SJw8b44CNWeJ4b4ZFr4CKRLzxZppR2g3k1tIsB6f4ETm1bCwTYTjuu9Zg+sxzvV2F2xHxlMlOcRUfqSM7tYEMScfw6H27woboOnqoGel10cBYYtssuEj5KrjoFvUmD/pbJXpGGyZrgOLkxRI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767089770; c=relaxed/simple; bh=LXvIBwQKlwN2aW+nel9nihwfIG/BNCGtqaNljMXS3c4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XC2DnrZKhhsnuZD8Ym4ncuHg9ZerbAGWeyopxhAQ0fc5yiJw7IAyZDkqULQCprekaVF7lFx1+F7r23IQbNiTxx1DoB4A6ArtVYg36y2FYDkIBne0UJDgqoMp3xO0CANJfpg1hx58xE8gaDPE4FWouvRJSOhLPXuftaGVvvTiHt0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=LOKjPzdg; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Bt254Tfa; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LOKjPzdg"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Bt254Tfa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767089767; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CbbLRn5SB4hmqpKO67RyzNkOjJr20Ge6MiEXlRieQIA=; b=LOKjPzdgycYAIvYyyXPsIrvVOknjLMICMttxdth0C8Zn3C9j204DjOIqMea7cwFazXYhGX cfKoaS5gpGyd0/5RH4xKa7y/7uSnt4xPJKr/yQb9dpDFLeVUVYoEnvgOLDAb3ivxGxyzJr oekd1u7Xa9y7RbdghjKbcrWXR6pc6rw= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-376-SsLykMjdMum4OcT001Wwtw-1; Tue, 30 Dec 2025 05:16:05 -0500 X-MC-Unique: SsLykMjdMum4OcT001Wwtw-1 X-Mimecast-MFC-AGG-ID: SsLykMjdMum4OcT001Wwtw_1767089764 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-430fd96b2f5so8253113f8f.3 for ; Tue, 30 Dec 2025 02:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1767089764; x=1767694564; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=CbbLRn5SB4hmqpKO67RyzNkOjJr20Ge6MiEXlRieQIA=; b=Bt254TfaH40bxBLxxz/5PJL5tMkim9plomSHRIKOLweJ0ULeIwYjMOOodWhM3WK//P UymTDcx5T/76e6zQA5wl6k6H93lMN9mTTgBmA5esGeKjeD1Mhg8ocnWjdfxPB9BBFgQF j3fdS68fB7LUzhD9scOZuWhrXFMLFMJDw/Yu3dQNCsu5cZRj7sVy1+rzWBHeB7BpvBFc wLynWNnvzZtHrWQVI8zQxRsCRzHZIIcWpvNGF2l+95QVNBecdrjYemcNz1AR1GJqfHNj ZXTLKRq/pX6OrNPTEiM8u/fjDpJWmP9UZgXfRWZqPtLtcBKSBJf8RrGd6bNB289+Fq2l m7sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767089764; x=1767694564; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CbbLRn5SB4hmqpKO67RyzNkOjJr20Ge6MiEXlRieQIA=; b=LTXlpGttQ5i8z6XoO40vJ0uOH92omXS9IcZ11s/C4FckgGXZuoA1OLdvkBB9KLcMHy qB7/ry8rp2KrVeAr3YyWhGjEA9OKXISeKJzhumj9C/8qLRYt4XHrBw7Ufnf95mffR04e QLMH2KBLrI/WBRAJRWSNI286xoUesbfjl77TagD5rQQHcuUWJYsRyYJuPodFXIF0ru3y XrfUP6DW7XaUT2fDvAzR3v0D34eyZ37Fdy3g0Ybaf4PIt13euQVlXpH3AdjBJ+svUY1u tyVJ291D2ocJ5appksjdyXHwcaTkhNy7LhdvLe5Oni2BhKfwl3zr5A6XbLdvVjcw88rE XVow== X-Gm-Message-State: AOJu0YwYtUaocg1scF3JcTcvNdmHu9h3aAHaV3t2Ec8MwYSuOhLI9Lb3 hSzF8o69y1nUP8vbw5GSPVwW3y7susmAt9Lj5MKkqJ4DONgw6DNNusG+rh8fFXLtftK1f1atkXU 4JMHkBIPqRVU/5B091N4OMAe9xAsibLlswgxao1LgpoZfEb8fWNqSBJtT/0Pa/tS30OoP40EGe/ 9DNfqombVOjruNhDN+pFYxVZOQSbIoFLZ9lO227ioVjMo= X-Gm-Gg: AY/fxX5FTlVh3n/ki6Uin7mO9ZhVhoTjHQ6WcPaRoNSu+HxIoEGAz5NerAp14MfGNWZ mFwZQs8hG8FryWf4OX7KID2OWUvSWgiUHuyBsg9Wuvg8pFKCcvpv0GT2vUk6srN8C1kxLBy15Hd iuIP8HAr/UuzQQ3SH5xCvstd7U8eVHuGSzIvgYJ2JyY36KFNIPPDnqBx7KGsINtlucSWv5HPQow 5loSsd9IKW336/fkfM9O71oMNPdN5dgWMB+d9fleX1+xsMs/PmehfRdQd/zTsVU/lCN6zygtb1j CwdH7cn4QoDWPLVff72eauYX8qxL1yH50frKvitkj3/5IKnE7BFSAHu43RRYsgPdC1ddMULhHKW UCvn9jSpiuurjEBPcDULuHeSDoGyLcL/OEA== X-Received: by 2002:a05:6000:200e:b0:430:fcf5:4937 with SMTP id ffacd0b85a97d-4324e4c3e1emr38658334f8f.7.1767089764094; Tue, 30 Dec 2025 02:16:04 -0800 (PST) X-Google-Smtp-Source: AGHT+IHK1atjAKrkdoWQy4jxFj2rw+qTn5U0Lh0sTEHql45jv1yC6jgv8gOxch8xQ2S/3gi1ay54uA== X-Received: by 2002:a05:6000:200e:b0:430:fcf5:4937 with SMTP id ffacd0b85a97d-4324e4c3e1emr38658276f8f.7.1767089763428; Tue, 30 Dec 2025 02:16:03 -0800 (PST) Received: from redhat.com (IGLD-80-230-31-118.inter.net.il. [80.230.31.118]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4324ea1b1bdsm66936468f8f.8.2025.12.30.02.16.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Dec 2025 02:16:03 -0800 (PST) Date: Tue, 30 Dec 2025 05:16:00 -0500 From: "Michael S. Tsirkin" To: linux-kernel@vger.kernel.org Cc: Cong Wang , Jonathan Corbet , Olivia Mackall , Herbert Xu , Jason Wang , Paolo Bonzini , Stefan Hajnoczi , Eugenio =?utf-8?B?UMOpcmV6?= , "James E.J. Bottomley" , "Martin K. Petersen" , Gerd Hoffmann , Xuan Zhuo , Marek Szyprowski , Robin Murphy , Stefano Garzarella , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Petr Tesarik , Leon Romanovsky , Jason Gunthorpe , linux-doc@vger.kernel.org, linux-crypto@vger.kernel.org, virtualization@lists.linux.dev, linux-scsi@vger.kernel.org, iommu@lists.linux.dev, kvm@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCH RFC 05/13] dma-debug: track cache clean flag in entries Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Mailer: git-send-email 2.27.0.106.g8ac3dc51b1 X-Mutt-Fcc: =sent Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" If a driver is bugy and has 2 overlapping mappings but only sets cache clean flag on the 1st one of them, we warn. But if it only does it for the 2nd one, we don't. Fix by tracking cache clean flag in the entry. Shrink map_err_type to u8 to avoid bloating up the struct. Signed-off-by: Michael S. Tsirkin --- kernel/dma/debug.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c index 7e66d863d573..9bd14fd4c51b 100644 --- a/kernel/dma/debug.c +++ b/kernel/dma/debug.c @@ -63,6 +63,7 @@ enum map_err_types { * @sg_mapped_ents: 'mapped_ents' from dma_map_sg * @paddr: physical start address of the mapping * @map_err_type: track whether dma_mapping_error() was checked + * @is_cache_clean: driver promises not to write to buffer while mapped * @stack_len: number of backtrace entries in @stack_entries * @stack_entries: stack of backtrace history */ @@ -76,7 +77,8 @@ struct dma_debug_entry { int sg_call_ents; int sg_mapped_ents; phys_addr_t paddr; - enum map_err_types map_err_type; + u8 map_err_type; + bool is_cache_clean; #ifdef CONFIG_STACKTRACE unsigned int stack_len; unsigned long stack_entries[DMA_DEBUG_STACKTRACE_ENTRIES]; @@ -472,12 +474,15 @@ static int active_cacheline_dec_overlap(phys_addr_t c= ln) return active_cacheline_set_overlap(cln, --overlap); } =20 -static int active_cacheline_insert(struct dma_debug_entry *entry) +static int active_cacheline_insert(struct dma_debug_entry *entry, + bool *overlap_cache_clean) { phys_addr_t cln =3D to_cacheline_number(entry); unsigned long flags; int rc; =20 + *overlap_cache_clean =3D false; + /* If the device is not writing memory then we don't have any * concerns about the cpu consuming stale data. This mitigates * legitimate usages of overlapping mappings. @@ -487,8 +492,14 @@ static int active_cacheline_insert(struct dma_debug_en= try *entry) =20 spin_lock_irqsave(&radix_lock, flags); rc =3D radix_tree_insert(&dma_active_cacheline, cln, entry); - if (rc =3D=3D -EEXIST) + if (rc =3D=3D -EEXIST) { + struct dma_debug_entry *existing; + active_cacheline_inc_overlap(cln); + existing =3D radix_tree_lookup(&dma_active_cacheline, cln); + if (existing) + *overlap_cache_clean =3D existing->is_cache_clean; + } spin_unlock_irqrestore(&radix_lock, flags); =20 return rc; @@ -583,20 +594,24 @@ DEFINE_SHOW_ATTRIBUTE(dump); */ static void add_dma_entry(struct dma_debug_entry *entry, unsigned long att= rs) { + bool overlap_cache_clean; struct hash_bucket *bucket; unsigned long flags; int rc; =20 + entry->is_cache_clean =3D !!(attrs & DMA_ATTR_CPU_CACHE_CLEAN); + bucket =3D get_hash_bucket(entry, &flags); hash_bucket_add(bucket, entry); put_hash_bucket(bucket, flags); =20 - rc =3D active_cacheline_insert(entry); + rc =3D active_cacheline_insert(entry, &overlap_cache_clean); if (rc =3D=3D -ENOMEM) { pr_err_once("cacheline tracking ENOMEM, dma-debug disabled\n"); global_disable =3D true; } else if (rc =3D=3D -EEXIST && - !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_CPU_CACHE_CLEAN)) && + !(attrs & DMA_ATTR_SKIP_CPU_SYNC) && + !(entry->is_cache_clean && overlap_cache_clean) && !(IS_ENABLED(CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC) && is_swiotlb_active(entry->dev))) { err_printk(entry->dev, entry, --=20 MST