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
