Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3555537pxb; Mon, 25 Jan 2021 21:14:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJxxSdt/Ed3pKj5T6toHcFllUxayxEwbGVtVd9LhV3RoEPqmA0ir8zvrCN3mhL2w/0QPn0s7 X-Received: by 2002:a17:906:d62:: with SMTP id s2mr2440939ejh.61.1611638065436; Mon, 25 Jan 2021 21:14:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611638065; cv=none; d=google.com; s=arc-20160816; b=UAwTRxirnOXt5rvuGsMPshhB6iPgyaKMVHIG/6f2RXP2VUpI6TG+vIJRrV3MkgcJzn jCDUM/KH755JJ0jjKYoDxX2ByQSfaCih+r/w4YSFDxyGRQFnCP4+hFJ1QJS/urkmyg6i JqzU1i+OS0xS2mhgG2B3DNMMpkeUIWBbJ5jjP30TJPDVYHsnMEt6T0n2ZCSe1ayT1sWC HWk+g3ABk3mD4OTmxF0XIW5asqL6+T+ltOK71AM2Y2ra+hY8ywgLMVT2Ha7a+AZOHnUX Zajy7etYqJ1utxaiILMmTSd1vpsljkroCGhrS/H0vZ/T0NU/7ue4jPI0szNVwm3uOyiO zHfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=C/AFMPpqS0dzyCVEHJ4j6EnLdumZy9LpijT7/6hXr/Y=; b=w+XA7tU5fF+oWabJQbMCFdL+z9ul8dL4rtk8UlhMhhSk74fPb/ZR/zXOgSswooQAgg eTDBpk3eG2A/I6H4zKk6/iPwqJQMsbpapL0Wu+EcoM9O4pOPjwqS8c9L1f+Oa6QCsHwK f5WETbDHM42LkmsmIwGJmeyXdtejWIBq/MJTmLnMkaWrzI48uPgUWxaJ3puHFC66pf+6 JE765s8dCP/1O3LXevmkFz15HHxT9kje6Us+v9nxrEwC2rsFLGu4doCSozsjWcULIIqY 5qLD9gX09N9GvKHScUO31vSpwrcdIM9nkzCpXgXv2mfWyxie3iH/8HfZgMrckbX1Znwg USOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UVmpbLLU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ka12si2825796ejc.323.2021.01.25.21.14.01; Mon, 25 Jan 2021 21:14:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UVmpbLLU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728953AbhAZFM0 (ORCPT + 99 others); Tue, 26 Jan 2021 00:12:26 -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