From mboxrd@z Thu Jan 1 00:00:00 1970 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 4FC29388E69 for ; Tue, 11 Aug 2026 21:14:26 +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=1786482867; cv=none; b=HDmdBo7xDuROkOeOEBqlc0PbeRFxDYSiPFklcMehOW73acp595BGEXwQPJ7l2UWwrq3FV5HpXEKHtIcApSHYqtGqUtugTTTn/ZRpUIbOMQhmCPU6cxKaa+NPv0Kevcpk6npm7kxWr5t2sXUydQqC9/y6ZJLuHcr5M6XOvNzmMX8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786482867; c=relaxed/simple; bh=DJlsgckZYzlASAM7E8A4/qDxmyOIaLaapT8XZAcOt5I=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=CxwkxrO6cmhPoYDmMVOhl9JjDA1ZIS/+9hAMa9ZyqBYsdPhCQsGtzOvFLfV/ukKmFWM3In0JtiTqRb20wK2nu/zJ7DQ6QQh+UxhSXxj41CLbWl8IpboNsOJggAubYmoJRYsSyAmFzL4s5/skMF6bQEkz+jkGN0N3qZWj/mhM9VQ= 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=gBuhaORv; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Vrpp/G/v; 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="gBuhaORv"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Vrpp/G/v" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786482865; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ouhsGoLziLRHCm+hWwEcaYZBRlXQpJLyEgr0LCF275A=; b=gBuhaORvgo+qRjZKqrpGpTRLdSPr2jimaxFkrCa4u/Tnr9DehswVktjrMGwVUdK9ytfWx5 sboryWMasOfnTksFzH9SJEC/UqvxeQHdrOY0J0P5Sxpws4pkXFZz/9NOikDlK2ljXyeGY+ O1IwAWhSYdaYc1rrBDuVGEkNzGhqyKQ= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-76-AYRtsEMnMoCoFAmmipyigA-1; Tue, 11 Aug 2026 17:14:24 -0400 X-MC-Unique: AYRtsEMnMoCoFAmmipyigA-1 X-Mimecast-MFC-AGG-ID: AYRtsEMnMoCoFAmmipyigA_1786482863 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-9349c5af52bso69148985a.0 for ; Tue, 11 Aug 2026 14:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1786482863; x=1787087663; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to:content-type; bh=ouhsGoLziLRHCm+hWwEcaYZBRlXQpJLyEgr0LCF275A=; b=Vrpp/G/viuD/jQ0i2Ipl6vqE+4VN6ZTbrK1zzgGRhSzn2IB03Fuit0D8BrJwkQOpVq MKYYMJhPmWC9F+ou4ndwxy2Kmjm4Ky9tQ+TuxDr0jrJBr7L7L+pUUeifnc1w/qDsaSZz BDvc55wNVcIWNzd4CeNdA8m/bqLOgtN1pyT1eCGfUQMNqdlhVahVZ2yQg6KVbNtNauPy WPs3MhLezYbXXSxYFGdbJGirNnc8eusCixnNG2tTJ20ileuUu7c7segNB8FnHhwldAaf F7drTIwsx5aVW3Ox9jqtrZCxI8vZkzv9p+B3vAsGfk/cqcTz5WKESFdmd2jJBeN8ucMK s8lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786482863; x=1787087663; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ouhsGoLziLRHCm+hWwEcaYZBRlXQpJLyEgr0LCF275A=; b=rduhTBf8wm3saQzykmURRmcXf1IFRlLxuy3+rcEa+MBscKXUvfS+SLAj19vuGyCriv 5oWgoO3p1H0WvSig0PSkiIwlA3k6+RMIewyUUI2RR11yOns6bEStjSWc9UuQszl6j2E3 sXewD6LIMmMEumv3BsL1oNJdOLuIgMdBuh5FcGeHlke+I3qe3HBUyKxvDCpT6obg9tmh Y6IxPRUOiDW1nt4raLAAnuM7rEskGEORt/VH+r3bSevouMnvV/1rW8A1jmKXbmpqqC88 BLHQ46wExoog3Jma9MGkkG5DytNScKMHPlK2ymBSpwnSWlLVTliqnpN0Km7bFMCNZKgl Y5Aw== X-Forwarded-Encrypted: i=1; AHgh+RpqpBDygsqEinGmfvW/bTXx0Gn8+lJPzv0t6rmLe9dvMRox7WXWqEb4mm9yYH32MP/p3aNddTbeamGfjyY=@vger.kernel.org X-Gm-Message-State: AOJu0Yw+9F8waifeAaz3gEN9Jlnrd78B0eLwF68UHai+C2Zx1dSDSd2m GUffbuiR/ltx2D9laLZLSjBZtMftzjh5hxvm9e5PtvWkgC53hK+M9a0Ahgq7sUkZdPGczeyGVpI y+TIvbNEJzVQKgc573gqXnSoBSilX6XOtZw7K1UmF2fWg9i1+L6uR+D0LstHz13RmOA== X-Gm-Gg: AR+sD10EMJtNKKreUMQJavghI60B2RZDdxgpPfo31tQ3grH7dU5Edpy5/8q5yOx4imf XV8RVvZ8TlVYhJksqE0z/MJ5kMf6AFbrNc6vMzrjL5GyYam9APqtjYjvOZvmmmVmr/f1E/ruDDh WpxtEHVU/RV21tfWt/S1p+VWXgJ/ABXuZZCNI+CbRFGjHAAH0V1jDx9Omh+4PxXnhEN0LxYD+6x +AkVnJfhQfFfqQ3spbh0rxD3MhcGrhHL5gGLsacP9bAPUCSzfT30/hbF7FkypHZ0qhsnkXt27Kg zo72kNRpv7mFRVVbnjYez6WS0BjvaAfVeQCT9dogpt23H2eUDekQhOz/djgpSocN24Y+Wb7E X-Received: by 2002:a05:620a:25cf:b0:930:a718:bafb with SMTP id af79cd13be357-936b3a4201dmr39431585a.10.1786482863540; Tue, 11 Aug 2026 14:14:23 -0700 (PDT) X-Received: by 2002:a05:620a:25cf:b0:930:a718:bafb with SMTP id af79cd13be357-936b3a4201dmr39428185a.10.1786482863056; Tue, 11 Aug 2026 14:14:23 -0700 (PDT) Received: from [192.168.8.4] ([100.0.180.93]) by smtp.gmail.com with ESMTPSA id af79cd13be357-936a848e7ecsm196988185a.11.2026.08.11.14.14.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 14:14:22 -0700 (PDT) Message-ID: Subject: Re: [PATCH 2/2] drm/nouveau/dmem: fix callocated underflow on large folio split From: lyude@redhat.com To: Zhenhao Wan , Danilo Krummrich , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Andrew Morton , Balbir Singh Cc: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, Yuhao Jiang , stable@vger.kernel.org Date: Tue, 11 Aug 2026 17:14:21 -0400 In-Reply-To: <20260811-b4-nouveau-dmem-thp-fixes-v1-2-2cdf9860af2a@gmail.com> References: <20260811-b4-nouveau-dmem-thp-fixes-v1-0-2cdf9860af2a@gmail.com> <20260811-b4-nouveau-dmem-thp-fixes-v1-2-2cdf9860af2a@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 This patch looks suspiciously human written (or at the very least, the commit message sure does). FWIW: if the code wasn't itself generated by an LLM, it's fine by me to avoid adding the tag. Most of us are concerned about generated LLM code that gets submitted, not human written code written to fix a legitimate issue that an LLM managed to help find. If we were concerned about the latter, I think anything sashiko touched would end up having an assisted-by tag on it :). Either way, this whole patch series is: Reviewed-by: Lyude Paul Issue looks quite legitimate, fix seems fine to me. On Tue, 2026-08-11 at 22:28 +0800, Zhenhao Wan wrote: > nouveau_dmem_folio_free() drops chunk->callocated once per freed > folio, > while a large (compound) device-private folio is only counted once > when > it is allocated.=C2=A0 When such a folio is split, the mm core invokes > ->folio_split() (nouveau_dmem_folio_split()) once for each new > sub-folio, but the hook only fixes up the sub-folio metadata and > leaves > chunk->callocated unchanged. >=20 > Each resulting sub-folio is later freed separately, so after a split > the single allocation (+1) is met by N frees (-N), leaving > chunk->callocated short by N-1.=C2=A0 On the first split/free cycle it > underflows: WARN_ON(!chunk->callocated) fires, the unsigned counter > wraps and never returns to zero, so the chunk can no longer be > reclaimed (nouveau_dmem_fini() also warns on the leaked count). >=20 > Account for the new sub-folio in the split hook, under the same lock > as > nouveau_dmem_folio_free(), so the count stays balanced. >=20 > Fixes: c32287471077 ("gpu/drm/nouveau: enable THP support for GPU > memory migration") > Reported-by: Yuhao Jiang > Assisted-by: Claude:claude-opus-5 > Cc: stable@vger.kernel.org > Signed-off-by: Zhenhao Wan > --- > =C2=A0drivers/gpu/drm/nouveau/nouveau_dmem.c | 14 ++++++++++++++ > =C2=A01 file changed, 14 insertions(+) >=20 > diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c > b/drivers/gpu/drm/nouveau/nouveau_dmem.c > index d2abee3efb9a..ad4570c50be7 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c > +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c > @@ -279,11 +279,25 @@ static vm_fault_t > nouveau_dmem_migrate_to_ram(struct vm_fault *vmf) > =C2=A0 > =C2=A0static void nouveau_dmem_folio_split(struct folio *head, struct > folio *tail) > =C2=A0{ > + struct nouveau_dmem_chunk *chunk; > + struct nouveau_dmem *dmem; > + > =C2=A0 if (tail =3D=3D NULL) > =C2=A0 return; > =C2=A0 tail->pgmap =3D head->pgmap; > =C2=A0 tail->mapping =3D head->mapping; > =C2=A0 folio_set_zone_device_data(tail, > folio_zone_device_data(head)); > + > + /* > + * The split hands out a new independently-freeable folio > that will > + * later be released via nouveau_dmem_folio_free(); account > for it so > + * chunk->callocated stays balanced. > + */ > + chunk =3D nouveau_page_to_chunk(&head->page); > + dmem =3D chunk->drm->dmem; > + spin_lock(&dmem->lock); > + chunk->callocated++; > + spin_unlock(&dmem->lock); > =C2=A0} > =C2=A0 > =C2=A0static const struct dev_pagemap_ops nouveau_dmem_pagemap_ops =3D {