From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 7125935B646 for ; Tue, 3 Mar 2026 17:44:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772559884; cv=none; b=GIoQKYMd9JmEvb21M7KCj0UxCAGmKXB0F4bAxcSG+j2KWKcMKIH6CD9SqdHwbsfaV5FDIDenP9kfjU0pDu02DrrPr56vKmlCfZsC4gkZub3lnE+ppnOD4uMZmx9RJCLcqIFkZI7DPAm3kAMlPqC51qqTH2iYQMzOLuXL/LBO+Fc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772559884; c=relaxed/simple; bh=98FUA6H7ttmlGD97XmHJINPTsJFqNg1jYfAloT7TIEQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=smpNy1V977mzg3+hiaIFALsh9ImMOr9CYcQ6Ja9ztoHYF8lp6d3okebP4D1jmANMcHjrd6tzk6UqMXx6hqV52X7llYfah8O2IHrIzzXQk0YrNRxW5diXxER6dWjEis/r2BC434HpROFG48OGxXnRB5axFL8x9nKVXgIN4Hq0JlY= 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=BerYenVE; arc=none smtp.client-ip=192.198.163.9 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="BerYenVE" 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: ajPrI4ELTxyHeFCHZVuaIQ== X-CSE-MsgGUID: GLtwXRwNQByesCIcX6jaFQ== X-IronPort-AV: E=McAfee;i="6800,10657,11718"; a="84317257" X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="84317257" 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 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: 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 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