[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABQgh9GEZSasZq5bDthQrTZnJ_Uo8G-swDsrM_gWCecWbtTKgA@mail.gmail.com>
Date: Thu, 28 Aug 2025 13:59:48 +0800
From: Zhangfei Gao <zhangfei.gao@...aro.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Chenghai Huang <huangchenghai2@...wei.com>, wangzhou1@...ilicon.com,
linux-kernel@...r.kernel.org, linuxarm@...wei.com,
linux-crypto@...r.kernel.org, fanghao11@...wei.com, shenyang39@...wei.com,
qianweili@...wei.com, linwenkai6@...ilicon.com, liulongfang@...wei.com
Subject: Re: [PATCH 3/4] uacce: implement mremap in uacce_vm_ops to return -EPERM
Hi, Greg
On Fri, 22 Aug 2025 at 19:46, Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Fri, Aug 22, 2025 at 06:39:03PM +0800, Chenghai Huang wrote:
> > From: Yang Shen <shenyang39@...wei.com>
> >
> > 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.
What's your suggestion?
Thanks
Powered by blists - more mailing lists