From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (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 E164F175A93 for ; Tue, 3 Mar 2026 15:15:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772550956; cv=none; b=YxIhwuKNLgkPaRRY9g6qDB7VE2EUb8ZY66D6ZW9OFsbAHqOOcJsJH4GAzYPF5qfrfNYx8PWqlgr6YLr/FXC4V3HDaIs4S01/Tdxn9VbmYyMOndA0HPDTb4+GtbY2jiN4oMR04x4J+ieTOYfC0aSk9Bm/SSixlrOwpGBzaVTChao= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772550956; c=relaxed/simple; bh=iN14tmk/LeqeMLATUqWDvPQDeVABVHnUxh5ifvTVHIg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nPBe9r29dlquu27o74HrxyX4rc/8dbdTQjrd6FGX7RRNSzHdveRpd2gMC+2Cs56eEyCOKqTfzv74GtDRnYDjkJakCK3lAcEXq+9OAKT6CXCUDFsLjQI8pFtbSGBbuH5ubdMm7BpiWjRl6F8zPmnq9OBlPoN0vMesFt8z9hShBhg= 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=iDEK9u9T; arc=none smtp.client-ip=192.198.163.18 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="iDEK9u9T" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772550953; x=1804086953; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=iN14tmk/LeqeMLATUqWDvPQDeVABVHnUxh5ifvTVHIg=; b=iDEK9u9T2QLEqpo+DcvkD/m2hM9rtoDwngKRwu+WPobJlMQZ+bX76O5X hx4TJ7PMmQq97A2MhKPZhF3b/dHE0bjhpUjtn7lCpsbdTU846lgtYCENQ C5Qz2P7gV3J66yTiHUrkpnWuKMsiumWv1sFRuG104S5W+tVLTo3+z5m/G dMk6tDv4Xp9SeoO3PydYmqxzZyBYSHtlyCHD4/xoFyXGh2cDXGNPgOHYN /FRERMiCRiLdZAhg4TyX8twrxEdlcknINB0PwZZV2tI/VVGB64F2dLDpa cyLCyue3CjpFbSMWD7HHQHMk/mxV+IKSLeUPeJX9vG/d+XeU9jsmpWrDS Q==; X-CSE-ConnectionGUID: yMBZ3JJBTm6l/9wgoGYRyQ== X-CSE-MsgGUID: ZA/5qsU+QzShlJRVQmbVDw== X-IronPort-AV: E=McAfee;i="6800,10657,11718"; a="72791969" X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="72791969" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 07:15:51 -0800 X-CSE-ConnectionGUID: HWFJ/aNXS2G4wsURjA49pQ== X-CSE-MsgGUID: RFX4PN3oROaNTXai2Qyf+A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="218002524" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO [10.245.245.25]) ([10.245.245.25]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 07:15:49 -0800 Message-ID: <5a816b1b-fae3-42d9-95eb-b1706a91d138@linux.intel.com> Date: Tue, 3 Mar 2026 16:15:41 +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?Christian_K=C3=B6nig?= , Julian Orth , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Dmitry Osipenko , Rob Clark Cc: 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> Content-Language: en-US From: Maarten Lankhorst In-Reply-To: <3c969254-ed38-4b13-84b3-5afa365b04cb@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hey, Den 2026-03-03 kl. 15:59, skrev Christian König: > On 3/3/26 15:53, Maarten Lankhorst wrote: >> 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. > > Yeah, I've realized that after pushing the patch as well. > > But I still think this patch is the right thing to do, because without requesting the functionality by setting the flag the point should clearly not have any effect at all. > > And when an application would have only explicitly assigned the fields known previously and then later been compiled with the new points field it would have failed. > > It is good practice to memset() structures given to the kernel so that all bytes are zero initialized, but it is not documented as mandatory as far as I know. I know that in case of xe, even padding members are tested for being zero. For new code it's explicitly recommended to test to prevent running into undefined behavior. In some cases data may look valid, even if it's just random garbage from the stack. Is it too late to revert? Kind regards, Maarten Lankhorst