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 449A9EC145F for ; Tue, 3 Mar 2026 14:53:32 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 866C010E826; Tue, 3 Mar 2026 14:53:26 +0000 (UTC) Received: from mgamail.intel.com (unknown [192.198.163.8]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4A63110E826 for ; Tue, 3 Mar 2026 14:53:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772549600; x=1804085600; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=1nlvIYv5euBJa0bVyCRXrzDZb9Y+ArrL9TcHZkINM2Q=; b=dJYKl80nedQ0U5xqHR/HYIaNgN7OIrU3PaTogYrl7rb4vov0YEx7ofRi 1y+TQoyC/ISy0I1dOXvcDFr6zLh69ebUia/72QKp2HgHYC2tvzNneizOt O46rFzW6Dq7LIgzzgRA+Y1eKWLKp9NLI54d0ezkM6BIaBQMWlwSiJ5G96 wzLwFZn+SlyX5d3VjoNqi/JDm55pNYaR653eYOicd2rs+3y52K+PfsTY8 PQdOI4ZSFtG2wAEbd/Xj/n8it0UzlHjR9cV07S8EfIixDau3FH9xWMCtp 4kF3Bm67ANb9wHqa5WFTn2eHeW0ywFo9O1TLcSqhFKPTxcjdrBZ9pPVU+ A==; X-CSE-ConnectionGUID: LFK/vCbsSNKIcIBqNMUw5g== X-CSE-MsgGUID: 9ontS/rrR2a7I5N1fQBJrA== X-IronPort-AV: E=McAfee;i="6800,10657,11718"; a="91159154" X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="91159154" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 06:53:10 -0800 X-CSE-ConnectionGUID: /lkztj10RNer0pf/lSSpkQ== X-CSE-MsgGUID: 5yHmc7wZQu684QHMtFrPyQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="241031263" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO [10.245.245.25]) ([10.245.245.25]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 06:53:07 -0800 Message-ID: Date: Tue, 3 Mar 2026 15:53:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drm/syncobj: Fix handle <-> fd ioctls with dirty stack To: Julian Orth , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , =?UTF-8?Q?Christian_K=C3=B6nig?= , Dmitry Osipenko , Rob Clark Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20260301-point-v1-1-21fc5fd98614@gmail.com> Content-Language: en-US From: Maarten Lankhorst In-Reply-To: <20260301-point-v1-1-21fc5fd98614@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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" Hey, Den 2026-03-01 kl. 13:34, skrev Julian Orth: > Consider the following application: > > #include > #include > #include > #include > > int main(void) { > int fd = open("/dev/dri/renderD128", O_RDWR); > struct drm_syncobj_create arg1; > ioctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, &arg1); > struct drm_syncobj_handle arg2; > memset(&arg2, 1, sizeof(arg2)); // simulate dirty stack > arg2.handle = arg1.handle; > arg2.flags = 0; > arg2.fd = 0; > arg2.pad = 0; > // arg2.point = 0; // userspace is required to set point to 0 > ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &arg2); > } > > The last ioctl returns EINVAL because args->point is not 0. However, > userspace developed against older kernel versions is not aware of the > new point field and might therefore not initialize it. > > The correct check would be > > if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_TIMELINE) > return -EINVAL; > > However, there might already be userspace that relies on this not > returning an error as long as point == 0. Therefore use the more lenient > check. > > Fixes: c2d3a7300695 ("drm/syncobj: Extend EXPORT_SYNC_FILE for timeline syncobjs") > Signed-off-by: Julian Orth I'm not convinced this is the correct fix. Userspace built before the change had the old size for drm_syncobj_create, the size is encoded into the ioctl, and zero extended as needed. See drivers/gpu/drm/drm_ioctl.c: out_size = in_size = _IOC_SIZE(cmd); ... if (ksize > in_size) memset(kdata + in_size, 0, ksize - in_size); This is a bug in a newly built app, and should be handled by explicitly zeroing the entire struct or using named initializers, and only setting specific members as required. In particular, apps built before the change will never encounter this bug. Kind regards, ~Maarten Lankhorst