Re: Inconsistent fence info between 6.1 and 5.15 kernel

["Christian König" <christian.koenig@amd.com>]

Am 21.11.23 um 01:50 schrieb Mengchi Cheng:
> Hello,
>                                                                          
> We are upleveling kernel from 5.15.32 to 6.1.62 for our system. The
> kernels we use are all vanila kernel from upstream without any extra
> patches. But we see our graphics application crashed in the 6.1.
>                                                                          
> And later we found that 6.1 has DMA_BUF_IOCTL_EXPORT_SYNC_FILE option
> added into dma_buf_ioctl. It initialized dma_fence_stub and returned
> with a sync_file. So then our app called sync_file_ioctl_fence_info to
> inquire fence info, it returns info of dma_fence_stub, which was not
> expected. As the result, the app aborted because of it.
>                                                                          
> Meanwhile, with the 5.15 kernel, our app somehow also called
> DMA_BUF_IOCTL_EXPORT_SYNC_FILE. Since it returned -ENOTTY, the app did
> not further ask for fence info.
>                                                                          
> I am not a graphics engineer. I do not know if userspace is handling
> dma_fence_stub correctly. But since the addition of
> DMA_BUF_IOCTL_EXPORT_SYNC_FILE is causing differnet behavior, I am
> wondering if there is a way to keep things consistent in the kernel.
> For example, add a macro to provide a choice disabling it? There is
> probably a better solution to it. Look forward to your reply.

At least of hand that simply sounds like incorrect behavior of the 
application.

You can't blame the kernel if the application tried to call an IOCTL 
which didn't existed on older kernels and get some undefined behavior on 
newer kernels.

Question is why exactly is the application not happy with the results of 
the sync_file? We had some fixing around the reported timestamps after a 
sync_file merge.

Regards,
Christian.

>                                                                          
>                                                                          
> Best,
> Mengchi Cheng
>