Received-SPF: pass (google.com: domain of linux-kernel+bounces-172869-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <e1a2d134-83a4-4833-939b-a53fe31553a4@amd.com>
Date: Wed, 8 May 2024 09:59:26 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about
 file lifetimes
To: =?UTF-8?Q?Michel_D=C3=A4nzer?= <michel.daenzer@mailbox.org>,
 =?UTF-8?Q?Christian_K=C3=B6nig?= <ckoenig.leichtzumerken@gmail.com>,
 Linus Torvalds <torvalds@linux-foundation.org>,
 Christian Brauner <brauner@kernel.org>, Al Viro <viro@zeniv.linux.org.uk>,
 keescook@chromium.org, axboe@kernel.dk, dri-devel@lists.freedesktop.org,
 io-uring@vger.kernel.org, jack@suse.cz, laura@labbott.name,
 linaro-mm-sig@lists.linaro.org, linux-fsdevel@vger.kernel.org,
 linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
 minhquangbui99@gmail.com, sumit.semwal@linaro.org,
 syzbot+045b454ab35fd82a35fb@syzkaller.appspotmail.com,
 syzkaller-bugs@googlegroups.com
References: <202405031110.6F47982593@keescook>
 <20240503211129.679762-2-torvalds@linux-foundation.org>
 <20240503212428.GY2118490@ZenIV>
 <CAHk-=wjpsTEkHgo1uev3xGJ2bQXYShaRf3GPEqDWNgUuKx0JFw@mail.gmail.com>
 <20240504-wohngebiet-restwert-6c3c94fddbdd@brauner>
 <CAHk-=wj_Fu1FkMFrjivQ=MGkwkKXZBuh0f4BEhcZHD5WCvHesw@mail.gmail.com>
 <CAHk-=wj6XL9MGCd_nUzRj6SaKeN0TsyTTZDFpGdW34R+zMZaSg@mail.gmail.com>
 <b1728d20-047c-4e28-8458-bf3206a1c97c@gmail.com>
 <ZjoKX4nmrRdevyxm@phenom.ffwll.local>
 <CAHk-=wgh5S-7sCCqXBxGcXHZDhe4U8cuaXpVTjtXLej2si2f3g@mail.gmail.com>
 <d68417df-1493-421a-8558-879abe36d6fa@gmail.com>
 <36169520-56e4-4a01-a467-051a94c7f810@mailbox.org>
Content-Language: en-US
From: =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>
In-Reply-To: <36169520-56e4-4a01-a467-051a94c7f810@mailbox.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VWpKS21QOUExMXZ4RmtDcW9QZkx4MHRMRmlKTmNGRU5hRWdRSkJjVEpoRVBF?=
 =?utf-8?B?Q25PWDFwR256ZmZrK3h4ZjV5R2cwbE5lS0xHSnBlNDI0L1FGbGxXeHYxR05T?=
 =?utf-8?B?TGY4SFBsQmJYVXBNR1lIZFgvQzRZQmpIUzJucXdhWjkyRi8ydVQ3TE1CSDVE?=
 =?utf-8?B?Mk1yNE1MRlBXRmtSN0NNVVNlMmpzc052OWk1ZDhhVnlIYjBDNHQybE5mZkg5?=
 =?utf-8?B?anY2ZE9qT2pRR0JhWFc5Z2x0QUpYc2NvdkhQUDJ3dHlNcDdqZzNpV3JGM09u?=
 =?utf-8?B?ZkUxWkZQLzNybWRRN0hWb05jYW1Rd2hYVU1VRDhxSS95dnBweUxMWFRjTmM1?=
 =?utf-8?B?UDZ5WlRGNVlUSkRWa2FTSzRGZGdlbjhKZVQ5dTRWdU03Z01yK25hQzc3VXVu?=
 =?utf-8?B?dVJCcklScjVZUHpwMEFaVVhTVjBmdlVGVlVaTDJUbVpwb1VnL2VaVlg2N3cv?=
 =?utf-8?B?Y3UyTWFZbDhlUzhUSS90VURNSHNBZmlHVVpZMVlYS3JHWVROc0tLNHBOSWor?=
 =?utf-8?B?aCtKYnFZVjB0c2FOSXd5dkE1akh0NHZzRVovMkVWc2dqQmNDODRYbnB2REJJ?=
 =?utf-8?B?ZUtmMTFKdVk1QjVQK1Bsdk1YMVlCdEtaMXNnamNMWW5LR3R3cDFOTmsxcWZN?=
 =?utf-8?B?SUs1VWhiU0ZCS255T01WTDUyMUU5OVVBR1RqcTFXbEw3YzBhdjlZK1lpUDJZ?=
 =?utf-8?B?eFFlY0EvOEtXT1RJT0QvTFdweGxnVXVYQWwxQ21PN2Zhb2J0a1oyZnlXL0NG?=
 =?utf-8?B?RXdKdXFsSkRvQWhQZWt0ckpZbVFJYWRnTk1rb1FnUUtRZWhncy8vMEFxN1Rq?=
 =?utf-8?B?YlRQVWIrZzRENUpjS3l5aWwxQlAyaE1HNkE2VUk3bVEyY2IybDFWYXF6aC84?=
 =?utf-8?B?K1pHQkw2TUlnWThjVThLRTgvdnpadXdvUlA2cmxEb241R0JWZjlTR2FKSHhs?=
 =?utf-8?B?bHFidTM3SUljQXprTnlSZ0I4SmhaUmYzcDgwMDVobkZqd0JGVHpRN1dWRTND?=
 =?utf-8?B?UUxtcFFtRUVGQ3RyMUtPZnVJaUdyR2ZGT0czTTJMeFIrMHRWMjlYajBwcUgr?=
 =?utf-8?B?SjlNQUlMOC90aER2YldYeFo2M0U0ZFQra1hnekE3aVYrZjU4ZjRaUFJaZVF5?=
 =?utf-8?B?UkRKT21XbWd5dllXNkdaZXVVMjhOTm1pTnJ4R1hnd1k4KzFrTGIrUi9INUc2?=
 =?utf-8?B?dk0xVG82YTNhKzdseHFCU3FLWWVCZGZOWmEwSEJmbTl1L0FFVUhacTFqMllL?=
 =?utf-8?B?elFNeTFSVjlORWRwcXBOYW40QTQzYTQ0M1ZuNW5NOHNKRGxhUjlGanpJR1Bj?=
 =?utf-8?B?MUdOeHlLWXdvbXdjZlNjRjkvVUh0SmRHbGxMdUZWT2pQeVhGTncwSXhWcGVH?=
 =?utf-8?B?aytqanBFY200UWdMcmR3dFY3aUdWb0w2Nk0rUXlNcGhqUExXSG5KVlJPSmdM?=
 =?utf-8?B?ZzFSK3RPRlB6M0JpQjBzK1pHQ2k4aS9mSWZETEFjL2Q5UFhWM05lSmlwcHhx?=
 =?utf-8?B?dkJ2Uk9hNjNmKzdHYk8vcGRoNFVtUnBMZXc3NSsraVZONWRpRE1aWkxCcnYy?=
 =?utf-8?B?OVdtN296U1Q3VWdJdjQxY0FHN3ZkbnQ1Z1J1YTdxamQ0dndpT2d2UDM5Wk5N?=
 =?utf-8?B?eEpCc2I0YThhV3dCNzFLdGg0SzZwSnJPWi8vZ1lrc1piMVdQM1FuWElEV0pS?=
 =?utf-8?B?WStTb2RLZ3pGV3F0VDRTRTRQOWhmNGFxRlNOdlhYU2tsc01OYkJoNkRNR3V3?=
 =?utf-8?B?TUhzaWM1dUdVUW53WG96eVRhbFBzWktxd1REYnJHYlpVenMrLzJLT3pvNEh3?=
 =?utf-8?B?ZVlpRk01bnprT2ZkdE5sMzhVb2kzMSt2S0VXK24zcmV4VWFoNjhxSUtLcTQ5?=
 =?utf-8?B?cjhiV2ZYYzhDcjJ2QVBYY1BLRDY4RUpxN1dQOFpLZW0xTklhaTlNRFRXMnkz?=
 =?utf-8?B?YlFEMFAvVS9WNzZnVVFHTUsyQXVENlVpbkhKMzFoT3haVk1jOSsvbnBaUlhE?=
 =?utf-8?B?RUN2NitjMCtZVkFKTjJORndFakNkZDRyTEc1UXhnVkYyMUpHcDNNUnoyMkxs?=
 =?utf-8?B?cWpJQlY4VE53cW4vZUR3WUVPd2VYQVlxYTlkZGdwbmZaY3lQYWxOTkFjNllZ?=
 =?utf-8?Q?tTIfINL8Vh0FFiHTeED4YpY/9?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b9a89be3-7906-4ab7-e658-08dc6f34cd03
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5685.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2024 07:59:34.9351
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: a2gA26jfFrKEbRnELoY7OU3eW49vSLlb3fas4WRrOLNK8kdDeTbXPAzZyuaDLH8t
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7246

Am 08.05.24 um 09:51 schrieb Michel Dänzer:
> On 2024-05-07 19:45, Christian König wrote:
>> Am 07.05.24 um 18:46 schrieb Linus Torvalds:
>>> Just what are the requirements for the GPU stack? Is one of the file
>>> descriptors "trusted", IOW, you know what kind it is?
>>>
>>> Because dammit, it's *so* easy to do. You could just add a core DRM
>>> ioctl for it. Literally just
>>>
>>>           struct fd f1 = fdget(fd1);
>>>           struct fd f2 = fdget(fd2);
>>>           int same;
>>>
>>>           same = f1.file && f1.file == f2.file;
>>>           fdput(fd1);
>>>           fdput(fd2);
>>>           return same;
>>>
>>> where the only question is if you also woudl want to deal with O_PATH
>>> fd's, in which case the "fdget()" would be "fdget_raw()".
>>>
>>> Honestly, adding some DRM ioctl for this sounds hacky, but it sounds
>>> less hacky than relying on EPOLL or KCMP.
>>>
>>> I'd be perfectly ok with adding a generic "FISAME" VFS level ioctl
>>> too, if this is possibly a more common thing. and not just DRM wants
>>> it.
>>>
>>> Would something like that work for you?
>> Well the generic approach yes, the DRM specific one maybe. IIRC we need to be able to compare both DRM as well as DMA-buf file descriptors.
>>
>> The basic problem userspace tries to solve is that drivers might get the same fd through two different code paths.
>>
>> For example application using OpenGL/Vulkan for rendering and VA-API for video decoding/encoding at the same time.
>>
>> Both APIs get a fd which identifies the device to use. It can be the same, but it doesn't have to.
>>
>> If it's the same device driver connection (or in kernel speak underlying struct file) then you can optimize away importing and exporting of buffers for example.
> It's not just about optimization. Mesa needs to know this for correct tracking of GEM handles. If it guesses incorrectly, there can be misbehaviour.

Oh, yeah good point as well.

I think we can say in general that if two userspace driver libraries 
would mess with the state of an fd at the same time without knowing of 
each other bad things would happen.

Regards,
Christian.