From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5A00C433E0 for ; Tue, 26 Jan 2021 20:33:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6775222255 for ; Tue, 26 Jan 2021 20:33:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729095AbhAZFMi (ORCPT ); Tue, 26 Jan 2021 00:12:38 -0500 Received: from mail.kernel.org ([198.145.29.99]:41126 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726919AbhAYJja (ORCPT ); Mon, 25 Jan 2021 04:39:30 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id CEFAC22472; Mon, 25 Jan 2021 09:28:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1611566940; bh=wF0JYx7C+UwAIZY8ksPAuFgLqtbCeO/VruEju37N6uo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UVmpbLLUS17+Ue9duoUlgwPZAao35PSkhItEGsD+FSck0iLnOluYZsuOCgXE0g4wP hnC+b2Znk45U2PhKkTOSc/4ceGhIqgsz6tRKk3YKakkpX4LC3bDpYNsNZEW3EsXbZA pwRl84JwfoH8fc2R3mBJb8Zj75Gsf4+nt7Qi4xSQ= Date: Mon, 25 Jan 2021 10:28:57 +0100 From: Greg Kroah-Hartman To: Zhou Wang Cc: Arnd Bergmann , Zhangfei Gao , linux-accelerators@lists.ozlabs.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, linux-mm@kvack.org, song.bao.hua@hisilicon.com, liguozhu@hisilicon.com, Sihang Chen Subject: Re: [RFC PATCH v2] uacce: Add uacce_ctrl misc device Message-ID: References: <1611563696-235269-1-git-send-email-wangzhou1@hisilicon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1611563696-235269-1-git-send-email-wangzhou1@hisilicon.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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