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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BF071D1D468 for ; Thu, 8 Jan 2026 14:46:03 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 239D010E758; Thu, 8 Jan 2026 14:46:03 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=collabora.com header.i=@collabora.com header.b="ftpQCXo4"; dkim-atps=neutral Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4B2A110E758 for ; Thu, 8 Jan 2026 14:46:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1767883560; bh=fdiNKjhyzhYfbAJ7xJSMVGv8b02ejKRcWDgiL0JyFrE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ftpQCXo4dQ86GAjkTl7PZtKfmjL5bCbJFDHf+9Y0xBGf3gcY+t+agzjSwqLDjLEop /VnOcaDKE9bCp+7yyBSWojM3uZFO/SguTlxe3nvQ6AmiMBJvEoAey+n04kno7bfoRM LI3dYvp1+A8X565R7F2i5MJpES8whRVgTaF6z2JM8k0WZLEcG3wqfj9edS0aBeTRyV g9rDpf7a8gjTxxGiKK4b+gjvJ0ASgfRW1DSGxkbdVKv5p29z/pqNoUJXaChLMFYL65 o6tw5Dfbm3gxTcua2eLk1w9/XNSPBPff3Rv/VWNy0J/DnFkDdRLXhmxVPjTPgenPQ0 hL+oUtOYotpGg== Received: from fedora (unknown [IPv6:2a01:e0a:2c:6930:d919:a6e:5ea1:8a9f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 71D4417E0020; Thu, 8 Jan 2026 15:46:00 +0100 (CET) Date: Thu, 8 Jan 2026 15:45:54 +0100 From: Boris Brezillon To: =?UTF-8?B?TG/Dr2M=?= Molinari Cc: dri-devel@lists.freedesktop.org, David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , kernel@collabora.com Subject: Re: [PATCH] drm/gem: Fix a GEM leak in drm_gem_get_unmapped_area() Message-ID: <20260108154554.66d22550@fedora> In-Reply-To: <1423e153-3b4b-4b8e-9614-955af95c6b08@collabora.com> References: <20260106164935.409765-1-boris.brezillon@collabora.com> <20260107121232.6e1efae5@fedora> <43836c92-d19e-43c9-8480-cb26c37bdfea@collabora.com> <20260108144344.33952ddf@fedora> <1423e153-3b4b-4b8e-9614-955af95c6b08@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, 8 Jan 2026 15:04:33 +0100 Lo=C3=AFc Molinari wrote: > On 08/01/2026 14:43, Boris Brezillon wrote: > > On Thu, 8 Jan 2026 14:25:01 +0100 > > Lo=C3=AFc Molinari wrote: > > =20 > >> On 07/01/2026 12:12, Boris Brezillon wrote: =20 > >>> On Tue, 6 Jan 2026 17:49:35 +0100 > >>> Boris Brezillon wrote: > >>> =20 > >>>> drm_gem_object_lookup_at_offset() can return a valid object with > >>>> filp or filp->f_op->get_unmapped_area set to NULL. Make sure we still > >>>> release the ref we acquired on such objects. > >>>> > >>>> Cc: Lo=C3=AFc Molinari > >>>> Fixes: 99bda20d6d4c ("drm/gem: Introduce drm_gem_get_unmapped_area()= fop") > >>>> Signed-off-by: Boris Brezillon > >>>> --- > >>>> drivers/gpu/drm/drm_gem.c | 10 ++++++---- > >>>> 1 file changed, 6 insertions(+), 4 deletions(-) > >>>> > >>>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > >>>> index 36c8af123877..f7cbf6e8d1e0 100644 > >>>> --- a/drivers/gpu/drm/drm_gem.c > >>>> +++ b/drivers/gpu/drm/drm_gem.c > >>>> @@ -1298,11 +1298,13 @@ unsigned long drm_gem_get_unmapped_area(stru= ct file *filp, unsigned long uaddr, > >>>> unsigned long ret; > >>>> =20 > >>>> obj =3D drm_gem_object_lookup_at_offset(filp, pgoff, len >> PAGE= _SHIFT); > >>>> - if (IS_ERR(obj) || !obj->filp || !obj->filp->f_op->get_unmapped_ar= ea) > >>>> - return mm_get_unmapped_area(filp, uaddr, len, 0, flags); > >>>> + if (IS_ERR(obj)) > >>>> + obj =3D NULL; > >>>> =20 > >>>> - ret =3D obj->filp->f_op->get_unmapped_area(obj->filp, uaddr, len, = 0, > >>>> - flags); > >>>> + if (!obj || !obj->filp || !obj->filp->f_op->get_unmapped_area) > >>>> + ret =3D mm_get_unmapped_area(filp, uaddr, len, 0, flags); =20 > >>> > >>> Also, I'm wondering if we shouldn't pass pgoff instead of zero here to > >>> have the exact same behavior that existed before > >>> drm_gem_get_unmapped_area() was introduced. > >>> =20 > >> > >> For mappings with a file (the DRM file in our case), if > >> filp->f_op->get_unmapped_area isn't set then generic_get_unmapped_area= () > >> is used and it ignores the pgoff argument. =20 > >=20 > > That's true for architectures that rely on the default implementation > > (Arm64 for instance), but other architectures might have their own > > implementation. > >=20 > > =20 > >> So it wasn't 0 before but was > >> ignored anyway. =20 > >=20 > > Didn't check all of them but the Arm implementation does take this > > pgoff into account if I read the code correctly [1]. The fact this > > argument is passed around makes me think other architectures might take > > this into account too. I know this pgoff is just a fake offset into the > > /dev/dri pseudo-file, but if we want to err on the safe side, we'd > > rather do exactly what was done before drm_gem_get_unmapped_area() was > > introduced for the ->filp=3D=3DNULL case. That's just my 2 cts, of cour= se. =20 >=20 > You're right, I focused on arm64 here and there's obviously other archs=20 > so we'd better pass pgoff for the fallback case. Do you want me to send a patch doing that, or should I take care of it?