From: Xu Zaibo <xuzaibo@huawei.com> To: zhangfei <zhangfei.gao@linaro.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Arnd Bergmann <arnd@arndb.de>, Herbert Xu <herbert@gondor.apana.org.au>, <jonathan.cameron@huawei.com>, <dave.jiang@intel.com>, <grant.likely@arm.com>, jean-philippe <jean-philippe@linaro.org>, Jerome Glisse <jglisse@redhat.com>, <ilias.apalodimas@linaro.org>, <francois.ozog@linaro.org>, <kenneth-lee-2012@foxmail.com>, Wangzhou <wangzhou1@hisilicon.com>, "haojian . zhuang" <haojian.zhuang@linaro.org>, <guodong.xu@linaro.org> Cc: <iommu@lists.linux-foundation.org>, <linux-kernel@vger.kernel.org>, <linux-accelerators@lists.ozlabs.org>, <linux-crypto@vger.kernel.org> Subject: Re: [PATCH] uacce: unmap remaining mmapping from user space Date: Tue, 25 Feb 2020 17:13:19 +0800 [thread overview] Message-ID: <844f8fc1-1c6c-0102-5412-df799cd327c5@huawei.com> (raw) In-Reply-To: <cf1f7ec2-7181-63fd-598d-b74d5a3efa15@linaro.org> Hi, On 2020/2/25 16:33, zhangfei wrote: > Hi, Zaibo > > On 2020/2/24 下午3:17, Xu Zaibo wrote: >>> @@ -585,6 +595,13 @@ void uacce_remove(struct uacce_device *uacce) >>> cdev_device_del(uacce->cdev, &uacce->dev); >>> xa_erase(&uacce_xa, uacce->dev_id); >>> put_device(&uacce->dev); >>> + >>> + /* >>> + * unmap remainning mapping from user space, preventing user still >>> + * access the mmaped area while parent device is already removed >>> + */ >>> + if (uacce->inode) >>> + unmap_mapping_range(uacce->inode->i_mapping, 0, 0, 1); >> Should we unmap them at the first of 'uacce_remove', and before >> 'uacce_put_queue'? >> > We can do this, > Though it does not matter, since user space can not interrupt kernel > function uacce_remove. > I think it matters :) Image that the process holds the uacce queue is running(read and write the queue), then you do 'uacce_remove'. The process is running(read and write the queue) well in the time between 'uacce_put_queue' and 'unmap_mapping_range', however, the queue with its DMA memory may be gotten and used by other guys in this time, since you have released them in kernel. As a result, the running process will be a disaster. cheers, Zaibo . > Thanks > . >
WARNING: multiple messages have this Message-ID (diff)
From: Xu Zaibo <xuzaibo@huawei.com> To: zhangfei <zhangfei.gao@linaro.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Arnd Bergmann <arnd@arndb.de>, Herbert Xu <herbert@gondor.apana.org.au>, <jonathan.cameron@huawei.com>, <dave.jiang@intel.com>, <grant.likely@arm.com>, jean-philippe <jean-philippe@linaro.org>, Jerome Glisse <jglisse@redhat.com>, <ilias.apalodimas@linaro.org>, <francois.ozog@linaro.org>, <kenneth-lee-2012@foxmail.com>, Wangzhou <wangzhou1@hisilicon.com>, "haojian . zhuang" <haojian.zhuang@linaro.org>, <guodong.xu@linaro.org> Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-accelerators@lists.ozlabs.org, linux-crypto@vger.kernel.org Subject: Re: [PATCH] uacce: unmap remaining mmapping from user space Date: Tue, 25 Feb 2020 17:13:19 +0800 [thread overview] Message-ID: <844f8fc1-1c6c-0102-5412-df799cd327c5@huawei.com> (raw) In-Reply-To: <cf1f7ec2-7181-63fd-598d-b74d5a3efa15@linaro.org> Hi, On 2020/2/25 16:33, zhangfei wrote: > Hi, Zaibo > > On 2020/2/24 下午3:17, Xu Zaibo wrote: >>> @@ -585,6 +595,13 @@ void uacce_remove(struct uacce_device *uacce) >>> cdev_device_del(uacce->cdev, &uacce->dev); >>> xa_erase(&uacce_xa, uacce->dev_id); >>> put_device(&uacce->dev); >>> + >>> + /* >>> + * unmap remainning mapping from user space, preventing user still >>> + * access the mmaped area while parent device is already removed >>> + */ >>> + if (uacce->inode) >>> + unmap_mapping_range(uacce->inode->i_mapping, 0, 0, 1); >> Should we unmap them at the first of 'uacce_remove', and before >> 'uacce_put_queue'? >> > We can do this, > Though it does not matter, since user space can not interrupt kernel > function uacce_remove. > I think it matters :) Image that the process holds the uacce queue is running(read and write the queue), then you do 'uacce_remove'. The process is running(read and write the queue) well in the time between 'uacce_put_queue' and 'unmap_mapping_range', however, the queue with its DMA memory may be gotten and used by other guys in this time, since you have released them in kernel. As a result, the running process will be a disaster. cheers, Zaibo . > Thanks > . > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-02-25 9:13 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-24 7:06 [PATCH] uacce: unmap remaining mmapping from user space Zhangfei Gao 2020-02-24 7:06 ` Zhangfei Gao 2020-02-24 7:17 ` Xu Zaibo 2020-02-24 7:17 ` Xu Zaibo 2020-02-25 8:33 ` zhangfei 2020-02-25 8:33 ` zhangfei 2020-02-25 9:13 ` Xu Zaibo [this message] 2020-02-25 9:13 ` Xu Zaibo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=844f8fc1-1c6c-0102-5412-df799cd327c5@huawei.com \ --to=xuzaibo@huawei.com \ --cc=arnd@arndb.de \ --cc=dave.jiang@intel.com \ --cc=francois.ozog@linaro.org \ --cc=grant.likely@arm.com \ --cc=gregkh@linuxfoundation.org \ --cc=guodong.xu@linaro.org \ --cc=haojian.zhuang@linaro.org \ --cc=herbert@gondor.apana.org.au \ --cc=ilias.apalodimas@linaro.org \ --cc=iommu@lists.linux-foundation.org \ --cc=jean-philippe@linaro.org \ --cc=jglisse@redhat.com \ --cc=jonathan.cameron@huawei.com \ --cc=kenneth-lee-2012@foxmail.com \ --cc=linux-accelerators@lists.ozlabs.org \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=wangzhou1@hisilicon.com \ --cc=zhangfei.gao@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.