Inconsistent fence info between 6.1 and 5.15 kernel

Inconsistent fence info between 6.1 and 5.15 kernel

[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.                                                          
                                                                        
                                                                        
Best,                                                                   
Mengchi Cheng

-- 
2.40.1

Re: Inconsistent fence info between 6.1 and 5.15 kernel

[Christian König]

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
>