On Thu, Aug 28, 2025 at 01:59:48PM +0800, Zhangfei Gao wrote: > Hi, Greg > > On Fri, 22 Aug 2025 at 19:46, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Fri, Aug 22, 2025 at 06:39:03PM +0800, Chenghai Huang wrote: > > > From: Yang Shen <shenyang39@xxxxxxxxxx> > > > > > > The current uacce_vm_ops does not support the mremap operation of > > > vm_operations_struct. Implement .mremap to return -EPERM to remind > > > users > > > > Why is this needed? If mremap is not set, what is the value returned? > > Did some debug locally. > > By default, mremap is permitted. > > With mremap, the original vma is released, > The vma_close is called and free resources, including q->qfr. > > However, vma->vm_private_data (q) is copied to the new vma. > When the new vma is closed, vma_close will get q and q->qft=0. > > So disable mremap here looks safer. > > > > > And why is -EPERM the correct value to return here? That's not what the > > man pages say is valid :( > > if disable mremap, -1 is returned as MAP_FAILED. > The errno is decided by the return value, -EPERM (-1) or -EINVAL (-22). > man mremap only lists -EINVAL. > > However, here the driver wants to disable mremap, looks -EPERM is more suitable. Disabling mremap is not a permission issue, it's more of an invalid call? I don't know, what do other drivers do? thanks, greg k-h
