From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (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 E06B33E51F5 for ; Tue, 3 Mar 2026 17:40:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772559660; cv=none; b=jIGmWGDRgkLQv90qiKBGAdr8xpKpePQwpzQzvAq9NdEufsMjKxwbvD0vjewJPM7eiHeyMdT9sLFQ5FHIL6SPNT44VdINQ+/Q86T54eZP9QQ8IiP7abJzG0JsEk7FYih1/x4ysB9oCS/y7Oeyr7VGMFiiiBlpOeixQhuBKjHhvE8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772559660; c=relaxed/simple; bh=KrS08w0c+cWlr7a6Ai+aVzpbCdyAH1bR2Srd/74O8cY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=IRYGx06WAzvfLOIDxCDVyCcLfj0N3/r2A5xRcEvaE7CJ9eXgd7V8g4U9h2Bl4Q6k071NwGvz9lFSCjIk1PGtZUDa/vRdTHkE4UPCcCQRJIFu8lmHJnSs9grnilA0mxHnNYjGnmG3N4E7v4FTf8NzY7MVwBmFzYK5onfVPAT+ltY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=NZfo9K/5; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="NZfo9K/5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772559659; x=1804095659; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=KrS08w0c+cWlr7a6Ai+aVzpbCdyAH1bR2Srd/74O8cY=; b=NZfo9K/5KHWRqkxnb8OE3b7WnaBFDTgcR3adXdK37E1xXZ8V8yyP7qM9 PnMnV7HiM9Qd1BUnrlMbMXhVdWswCheBSqTv8DEcIrDqM5o23Me9ovHTo 0RpeEG0lKItejmxdhApTbHu5UeM0e2/17qx3/Vn3VtYvBNQgmQoCSEYHB S3GWT36IN9llYhXeC9n/2nsWxknRCg6AQWDj4rHcHb/heq/aVWNn6xRns HTa9atr/MQvshOV4UXFmywqDkZVByAmoN/sY0j21l8npPqR67Owq0RVYp G3XHaHervoHw3an75vgpJBdIEFTs68X2Rs9BuR3gXW5ztVGFF5cSCRWaO w==; X-CSE-ConnectionGUID: pRgLnNyMScmjrQ6InSJAww== X-CSE-MsgGUID: IBh91j+7RuGbB0TwwyqKIw== X-IronPort-AV: E=McAfee;i="6800,10657,11718"; a="76208995" X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="76208995" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 09:40:58 -0800 X-CSE-ConnectionGUID: 3fSIjPObS/y/zsGv8lguAA== X-CSE-MsgGUID: epnrKxTXS7m1J9YoOpsO4g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="217237522" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO [10.245.245.106]) ([10.245.245.106]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 09:40:55 -0800 Message-ID: <88726fec-3bbb-4ca8-b724-c281b5696324@linux.intel.com> Date: Tue, 3 Mar 2026 18:40:52 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drm/syncobj: Fix handle <-> fd ioctls with dirty stack To: =?UTF-8?Q?Michel_D=C3=A4nzer?= , Julian Orth 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 Den 2026-03-03 kl. 18:18, skrev Michel Dänzer: > On 3/3/26 18:11, Julian Orth wrote: >> On Tue, Mar 3, 2026 at 6:04 PM Michel Dänzer wrote: >>> On 3/3/26 17:54, Julian Orth wrote: >>>> On Tue, Mar 3, 2026 at 5:40 PM Maarten Lankhorst >>>> wrote: >>>>> >>>>> There is precedence in the ioctl, the pad member is checked against zero for the same reason. >>>> >>>> I don't believe that this is comparable. Developers of code developed >>>> against an older kernel could look at the kernel and see that the pad >>>> field was checked against zero. They could not see the same for fields >>>> that didn't exist at the time. >>> >>> "Initialize only known fields" isn't a valid approach here. The full struct must be initialized to 0, including any fields added in the future. >> >> It worked from the introduction of the ioctl until the new field was >> added. How could anyone know about this requirement if it is not >> documented? Some people might not even know that ioctl numbers encode >> the size of the argument and therefore assume that the argument >> structure is fixed. I think this is quite different from syscalls such >> as clone3 which make the size argument explicit and where it can be >> expected that the developer knows that the struct might grow when the >> application is recompiled. >> >> The new flag was added so that userspace can detect older kernels that >> don't support the point field, such kernels return EINVAL when they >> see the new flag. >> Then why should the kernel not also use the absence of the flag to >> detect older userspace that might be unaware of the point field? > > 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. My point is that it works for old userspace without problems. It's only newly compiled userspace with new headers that will run into problems. The code as written would have continued to work, but if you update to the new header and don't initialise the new members then it's a userspace problem. It should not be worked around in the kernel, since it's newly written bad userspace code, not old bad userspace code that stopped working when the kernel changed.