[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YA6PWSs8dxsHEpY+@kroah.com>
Date: Mon, 25 Jan 2021 10:28:57 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Zhou Wang <wangzhou1@...ilicon.com>
Cc: Arnd Bergmann <arnd@...db.de>,
Zhangfei Gao <zhangfei.gao@...aro.org>,
linux-accelerators@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
iommu@...ts.linux-foundation.org, linux-mm@...ck.org,
song.bao.hua@...ilicon.com, liguozhu@...ilicon.com,
Sihang Chen <chensihang1@...ilicon.com>
Subject: Re: [RFC PATCH v2] uacce: Add uacce_ctrl misc device
On Mon, Jan 25, 2021 at 04:34:56PM +0800, Zhou Wang wrote:
> +static int uacce_pin_page(struct uacce_pin_container *priv,
> + struct uacce_pin_address *addr)
> +{
> + unsigned int flags = FOLL_FORCE | FOLL_WRITE;
> + unsigned long first, last, nr_pages;
> + struct page **pages;
> + struct pin_pages *p;
> + int ret;
> +
> + first = (addr->addr & PAGE_MASK) >> PAGE_SHIFT;
> + last = ((addr->addr + addr->size - 1) & PAGE_MASK) >> PAGE_SHIFT;
> + nr_pages = last - first + 1;
> +
> + pages = vmalloc(nr_pages * sizeof(struct page *));
> + if (!pages)
> + return -ENOMEM;
> +
> + p = kzalloc(sizeof(*p), GFP_KERNEL);
> + if (!p) {
> + ret = -ENOMEM;
> + goto free;
> + }
> +
> + ret = pin_user_pages_fast(addr->addr & PAGE_MASK, nr_pages,
> + flags | FOLL_LONGTERM, pages);
> + if (ret != nr_pages) {
> + pr_err("uacce: Failed to pin page\n");
> + goto free_p;
> + }
> + p->first = first;
> + p->nr_pages = nr_pages;
> + p->pages = pages;
> +
> + ret = xa_err(xa_store(&priv->array, p->first, p, GFP_KERNEL));
> + if (ret)
> + goto unpin_pages;
> +
> + return 0;
> +
> +unpin_pages:
> + unpin_user_pages(pages, nr_pages);
> +free_p:
> + kfree(p);
> +free:
> + vfree(pages);
> + return ret;
> +}
No error checking on the memory locations or size of memory to be
'pinned', what could ever go wrong?
Note, this opens a huge hole in the kernel that needs to be documented
really really really well somewhere, as it can cause very strange
results if you do not know exactly what you are doing, which is why I am
going to require that the mm developers sign off on this type of thing.
And to give more context, I really don't think this is needed, but if it
is, it should be a new syscall, not buried in an ioctl for a random
misc driver, but the author seems to want it tied to this specific
driver...
thanks,
greg k-h
Powered by blists - more mailing lists