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 03425EDA6BE for ; Tue, 3 Mar 2026 17:44:44 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 53F9B89622; Tue, 3 Mar 2026 17:44:44 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="BerYenVE"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1BD7E89622 for ; Tue, 3 Mar 2026 17:44:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772559883; x=1804095883; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=98FUA6H7ttmlGD97XmHJINPTsJFqNg1jYfAloT7TIEQ=; b=BerYenVEqTkyYHiH71XTKFkafnunuwi8aRzVIDvWHmu7D2T88LA93JfP CAz92pFGT3p7Ieyw0SnamupN8xLWsyf/sZmdafmNilOeSVXdxKFrhue7K kczsdmxFG983d4fkFfgWphsPdVHyFCsoSOTd08aBzFXY5r+X1xgC5nLkb prPoEIqGyxb6hIe/1fiCfjQ0rBJzHND5YuAi0vi5n6XV9rDww3cs/6gjT 2QaErvEen6TByyMPow0zxlEHch3q4Mxm9KPgE5OItb2FlthRJHPfuMBrR 8Q080AyCupV/1Dcd8EDnNV5CrW7DEZBImw8YwXYDvpUVuI25fLDepxEsn g==; X-CSE-ConnectionGUID: 4NZUHkAmSVWCu0JEjHRWQg== X-CSE-MsgGUID: 1k9ec4TsQj+d1poOcnmKMQ== X-IronPort-AV: E=McAfee;i="6800,10657,11718"; a="84317264" X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="84317264" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 09:44:42 -0800 X-CSE-ConnectionGUID: QwGXLoIHRTORBGlG5hRpzQ== X-CSE-MsgGUID: UmM7EwK9R3iZ6Jqkp34lZQ== X-ExtLoop1: 1 Received: from ijarvine-mobl1.ger.corp.intel.com (HELO [10.245.245.108]) ([10.245.245.108]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 09:44:40 -0800 Message-ID: Date: Tue, 3 Mar 2026 18:44:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drm/syncobj: Fix handle <-> fd ioctls with dirty stack To: Julian Orth , =?UTF-8?Q?Michel_D=C3=A4nzer?= Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Dmitry Osipenko , Rob Clark , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20260301-point-v1-1-21fc5fd98614@gmail.com> <3c969254-ed38-4b13-84b3-5afa365b04cb@amd.com> <2b75199f-b78a-4915-8e75-5d186f63f7c5@mailbox.org> Content-Language: en-US From: Maarten Lankhorst In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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-03 kl. 18:30, skrev Julian Orth: > On Tue, Mar 3, 2026 at 6:18 PM Michel Dänzer wrote: >> >> I wrote in my first post in this thread that I don't object to your patch, so you can relax and stop trying to convince me not to object to it. :) >> >> I'm just pointing out that this is working around broken user-space code, and that there are other similar cases where that kind of broken users-space code couldn't be worked around in the kernel, so it's better to also fix the user-space code anyway. > > At this point I think we're arguing about "how can ioctls be extended" > and "does userspace have to use memset" in general, not just about > this particular ioctl. You've made the argument that ioctls are not > extensible in general unless userspace uses memset. However, I'm not > yet convinced of this. As you've also said above, drm_ioctl happily > truncates or zero-extends ioctl arguments without returning an error > due to size mismatch. Therefore, the only way for userspace to detect > if the kernel supports the "extended" ioctl is to add a flag so that > the kernel can return an error if it doesn't know the flag. And then > that flag could also be used by the kernel to detect which fields of > the argument are potentially uninitialized. > > That is why I asked above if you knew of any other examples where an > ioctl was extended and where memset(0) became effectively required due > to the extension. You don't even need to use memset, this would work too: struct drm_syncobj_handle args = { .flags = 0 }; Or simply struct drm_syncobj_handle args = { }; Kind regards, ~Maarten Lankhorst