From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (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 DB4911E7C03 for ; Wed, 4 Mar 2026 10:35:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772620547; cv=none; b=n59d5ACx0eWmBTDLSad4YcCpEe8Hn2vpT+EzXTNPnpUaQn0LRA+mm+Ns7NNOuH8nCzYnDtU89xQ4CBCfYHxVSDBztnSiBAFpvbCidE9ee2fx5nOlkOTby59i+VFICJo8JdzR/gvBJVv45MnE5oal25Wv0/0k0+D/M3n825na9B8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772620547; c=relaxed/simple; bh=UgS6V996PdN8AqAnWlEVeUsDMALMiHHFTeLoamvKN2M=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fBOryt6v7Hm+h99kKk+mwAbM7bMlgqoJQfr+DOU7dSqpNKrwjLostEIlM3I4htDCO7WwiJD3IoDRxV8Cv9NnPeuroE1MyOHLgsNuxfbhhWD4OqPqOW286FmjmkvBAQIpeDktYNPvPWfYK6CNh5hsi8acOVIPadmZWK2rH+lzQXE= 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=JZROQfxH; arc=none smtp.client-ip=198.175.65.15 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="JZROQfxH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772620546; x=1804156546; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=UgS6V996PdN8AqAnWlEVeUsDMALMiHHFTeLoamvKN2M=; b=JZROQfxH5JsI6ujuUKOoxNmj8NLmCzGSNxV69OE0WKA0UT9c5wBk4L4s LQkYn6v2CsS37TAHpVGvd+qxQY6QT3yQ8k/ZpL3kQZhoOtptRSqdT49e5 sYib3qWXWmEVisHrYV8GvXe3hV4A6gJpmWta2jsdU0qd+JlIpjo3b+Y5K j/Y40PRgXXH8xOGorYoWwWSVQMBKdB1AkVR/F6rIS8JrNFHilxAw3aJcJ HNdEYmzKbzrIShoUbanafF1P+2pkwFN0jLGBzMDqS14n1z7smj09wX+wI x4UGlhSTtj5iO6fxpXNJ4DmZS46EnFrRAb2wVjBjmMAx6QTbHtXfNJcx1 g==; X-CSE-ConnectionGUID: ygvlcL9vQrm8aLPqLm2YVQ== X-CSE-MsgGUID: N99WRcDQT1uEdLOeYkAcAw== X-IronPort-AV: E=McAfee;i="6800,10657,11718"; a="77282554" X-IronPort-AV: E=Sophos;i="6.21,323,1763452800"; d="scan'208";a="77282554" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2026 02:35:45 -0800 X-CSE-ConnectionGUID: CSiu4bidQii+Dv4ovQ8l6g== X-CSE-MsgGUID: vXH3rHHYQnqHFa0ezsNgjQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,323,1763452800"; d="scan'208";a="217540737" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO [10.245.245.178]) ([10.245.245.178]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2026 02:35:43 -0800 Message-ID: <12090ced-c0fd-47db-9f36-9dbf3c4b3ca6@linux.intel.com> Date: Wed, 4 Mar 2026 11:35:40 +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: David Laight , Julian Orth Cc: =?UTF-8?Q?Michel_D=C3=A4nzer?= , =?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> <88726fec-3bbb-4ca8-b724-c281b5696324@linux.intel.com> <20260303195835.4c23be7a@pumpkin> Content-Language: en-US From: Maarten Lankhorst In-Reply-To: <20260303195835.4c23be7a@pumpkin> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hey, Den 2026-03-03 kl. 20:58, skrev David Laight: > On Tue, 3 Mar 2026 18:44:59 +0100 > Julian Orth wrote: > >> On Tue, Mar 3, 2026 at 6:41 PM Maarten Lankhorst >> wrote: >>> >>> 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. >> >> But it's not newly written. The example is, say, 5 year old code. The >> binary that was compiled 5 years ago works fine as you say. But if you >> take the same code and just run gcc again, the new binary will no >> longer work. >> > > Worse, the recompiled version may well work when you test it, and even > when deployed. > But you'll get non-obvious random failures - a support nightmare. I believe in a lot of cases the headers are simply copied to the project, so it will continue to work. I don't see a difference between moving to a new compiler. Compiling code from 5 years ago might also run into new compiler warnings that didn't exist on the older version of the compiler. > Probably best code is something like: > case OLD_IOCTL_CODE: > if (ioc->flag & NEW_FLAG) > return -EINVAL; > /* FALLTHROUGH *. > case NEW_IOCTL_CODE: > if (!(ioc->flag & NEW_FLAG)) > ioc->new_field = 0; > > David Yeah, that is what we do by explicitly checking the size parameter. Any undefined members are zero'd. If you define the new member in userspace, you're also taking on the responsibility for having it contained defined information, even if you only zero the struct. Kind regards, ~Maarten Lankhorst