Add a new ioctl called TEE_IOC_SHM_REGISTER_FD to register a
shared memory from a dmabuf file descriptor.
This new ioctl will allow the Linux Kernel to register a buffer
to be used by the Secure Data Path OPTEE OS feature.
Please find more information here:
https://static.linaro.org/connect/san19/presentations/san19-107.pdf
Patch tested on Hikey 6220.
Etienne Carriere (1):
tee: new ioctl to a register tee_shm from a dmabuf file descriptor
drivers/tee/tee_core.c | 38 +++++++++++++++
drivers/tee/tee_shm.c | 99 +++++++++++++++++++++++++++++++++++++++-
include/linux/tee_drv.h | 11 +++++
include/uapi/linux/tee.h | 29 ++++++++++++
4 files changed, 175 insertions(+), 2 deletions(-)
--
2.25.0
Sorry to re-send this patch again.
I forgot to attach description.
When running make htmldocs, I found that drm_accel_node
does not exist. The documents do not have any links to
acceleration nodes, so I removed them.
This patch is an extra credit for documentation task
in the Linux kernel Bug Fixing Spring unpaid 2023.
Best,
Taichi
Signed-off-by: Taichi Nishimura <awkrail01(a)gmail.com>
---
include/drm/drm_file.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0d1f853092ab..cffccf6b94de 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -407,8 +407,6 @@ static inline bool drm_is_render_client(const struct drm_file *file_priv)
*
* Returns true if this is an open file of the compute acceleration node, i.e.
* &drm_file.minor of @file_priv is a accel minor.
- *
- * See also the :ref:`section on accel nodes <drm_accel_node>`.
*/
static inline bool drm_is_accel_client(const struct drm_file *file_priv)
{
--
2.25.1
Based on discussions at LPC, this series adds a memory.stat counter for
exported dmabufs. This counter allows us to continue tracking
system-wide total exported buffer sizes which there is no longer any
way to get without DMABUF_SYSFS_STATS, and adds a new capability to
track per-cgroup exported buffer sizes. The total (root counter) is
helpful for accounting in-kernel dmabuf use (by comparing with the sum
of child nodes or with the sum of sizes of mapped buffers or FD
references in procfs) in addition to helping identify driver memory
leaks when in-kernel use continually increases over time. With
per-application cgroups, the per-cgroup counter allows us to quickly
see how much dma-buf memory an application has caused to be allocated.
This avoids the need to read through all of procfs which can be a
lengthy process, and causes the charge to "stick" to the allocating
process/cgroup as long as the buffer is alive, regardless of how the
buffer is shared (unless the charge is transferred).
The first patch adds the counter to memcg. The next two patches allow
the charge for a buffer to be transferred across cgroups which is
necessary because of the way most dmabufs are allocated from a central
process on Android. The fourth patch adds the binder object flags to
the existing selinux_binder_transfer_file LSM hook and a SELinux
permission for charge transfers.
[1] https://lore.kernel.org/all/20220617085702.4298-1-christian.koenig@amd.com/
v2:
Actually charge memcg vs just mutate the stat counter per Shakeel Butt
and Michal Hocko. Shakeel pointed me at the skmem functions which
turned out to be very similar to how I was thinking the dmabuf tracking
should work. So I've added a pair of dmabuf functions that do
essentially the same thing, except conditionally implemented behind
CONFIG_MEMCG alongside the other charge/uncharge functions.
Drop security_binder_transfer_charge per Casey Schaufler and Paul Moore
Drop BINDER_FDA_FLAG_XFER_CHARGE (and fix commit message) per Carlos
Llamas
Don't expose is_dma_buf_file for use by binder per Hillf Danton
Call dma_buf_stats_teardown in dma_buf_export error handling
Rebase onto v6.2-rc5
Hridya Valsaraju (1):
binder: Add flags to relinquish ownership of fds
T.J. Mercier (3):
memcg: Track exported dma-buffers
dmabuf: Add cgroup charge transfer function
security: binder: Add binder object flags to
selinux_binder_transfer_file
Documentation/admin-guide/cgroup-v2.rst | 5 ++
drivers/android/binder.c | 27 ++++++++--
drivers/dma-buf/dma-buf.c | 69 +++++++++++++++++++++++++
include/linux/dma-buf.h | 4 ++
include/linux/lsm_hook_defs.h | 2 +-
include/linux/lsm_hooks.h | 5 +-
include/linux/memcontrol.h | 43 +++++++++++++++
include/linux/security.h | 6 ++-
include/uapi/linux/android/binder.h | 19 +++++--
mm/memcontrol.c | 19 +++++++
security/security.c | 4 +-
security/selinux/hooks.c | 13 ++++-
security/selinux/include/classmap.h | 2 +-
13 files changed, 201 insertions(+), 17 deletions(-)
base-commit: 2241ab53cbb5cdb08a6b2d4688feb13971058f65
--
2.39.0.246.g2a6d74b583-goog
To make it easier to find the dma-buf documentation when looking through
tables-of-contents etc., put the name "dma-buf" in the title.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer(a)gmx.net>
---
Documentation/driver-api/dma-buf.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst
index 622b8156d2127..61b6f42ed0f18 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -1,5 +1,5 @@
-Buffer Sharing and Synchronization
-==================================
+Buffer Sharing and Synchronization (dma-buf)
+============================================
The dma-buf subsystem provides the framework for sharing buffers for
hardware (DMA) access across multiple device drivers and subsystems, and
--
2.39.0
Hi guys,
this is just an RFC! The last time we discussed the DMA-buf coherency
problem [1] we concluded that DMA-heap first needs a better way to
communicate to userspace which heap to use for a certain device.
As far as I know userspace currently just hard codes that information
which is certainly not desirable considering that we should have this
inside the kernel as well.
So what those two patches here do is to first add some
dma_heap_create_device_link() and dma_heap_remove_device_link()
function and then demonstrating the functionality with uvcvideo
driver.
The preferred DMA-heap is represented with a symlink in sysfs between
the device and the virtual DMA-heap device node.
What's still missing is certainly matching userspace for this since I
wanted to discuss the initial kernel approach first.
Please take a look and comment.
Thanks,
Christian.
[1] https://lore.kernel.org/all/11a6f97c-e45f-f24b-8a73-48d5a388a2cc@gmail.com/…
Based on discussions at LPC, this series adds a memory.stat counter for
exported dmabufs. This counter allows us to continue tracking
system-wide total exported buffer sizes which there is no longer any
way to get without DMABUF_SYSFS_STATS, and adds a new capability to
track per-cgroup exported buffer sizes. The total (root counter) is
helpful for accounting in-kernel dmabuf use (by comparing with the sum
of child nodes or with the sum of sizes of mapped buffers or FD
references in procfs) in addition to helping identify driver memory
leaks when in-kernel use continually increases over time. With
per-application cgroups, the per-cgroup counter allows us to quickly
see how much dma-buf memory an application has caused to be allocated.
This avoids the need to read through all of procfs which can be a
lengthy process, and causes the charge to "stick" to the allocating
process/cgroup as long as the buffer is alive, regardless of how the
buffer is shared (unless the charge is transferred).
The first patch adds the counter to memcg. The next two patches allow
the charge for a buffer to be transferred across cgroups which is
necessary because of the way most dmabufs are allocated from a central
process on Android. The fourth patch adds a SELinux hook to binder in
order to control who is allowed to transfer buffer charges.
[1] https://lore.kernel.org/all/20220617085702.4298-1-christian.koenig@amd.com/
Hridya Valsaraju (1):
binder: Add flags to relinquish ownership of fds
T.J. Mercier (3):
memcg: Track exported dma-buffers
dmabuf: Add cgroup charge transfer function
security: binder: Add transfer_charge SElinux hook
Documentation/admin-guide/cgroup-v2.rst | 5 +++
drivers/android/binder.c | 36 +++++++++++++++--
drivers/dma-buf/dma-buf.c | 54 +++++++++++++++++++++++--
include/linux/dma-buf.h | 5 +++
include/linux/lsm_hook_defs.h | 2 +
include/linux/lsm_hooks.h | 6 +++
include/linux/memcontrol.h | 7 ++++
include/linux/security.h | 2 +
include/uapi/linux/android/binder.h | 23 +++++++++--
mm/memcontrol.c | 4 ++
security/security.c | 6 +++
security/selinux/hooks.c | 9 +++++
security/selinux/include/classmap.h | 2 +-
13 files changed, 149 insertions(+), 12 deletions(-)
base-commit: b7bfaa761d760e72a969d116517eaa12e404c262
--
2.39.0.314.g84b9a713c41-goog
Hi guys,
after finding that we essentially have two separate worlds for coherent sharing
of buffer through DMA-buf I thought I will tackle that problem a bit and at
least allow the framework to reject attachments which won't work.
So those patches here add a new dma_coherent flag to each DMA-buf object
telling the framework that dev_is_dma_coherent() needs to return true for an
importing device to be able to attach. Since we should always have a fallback
path this should give userspace the chance to still keep the use case working,
either by doing a CPU copy instead or reversing the roles of exporter and
importer.
For DRM and most V4L2 devices I then fill in the dma_coherent flag based on the
return value of dev_is_dma_coherent(). Exporting drivers are allowed to clear
the flag for their buffers if special handling like the USWC flag in amdgpu or
the uncached allocations for radeon/nouveau are in use.
Additional to that importers can also check the flag if they have some
non-snooping operations like the special scanout case for amdgpu for example.
The patches are only smoke tested and the solution isn't ideal, but as far as
I can see should at least keep things working.
Please review and/or comment,
Christian.
On Fri, Dec 23, 2022 at 10:54:37PM +0800, Greg KH wrote:
>> diff --git a/drivers/usb/gadget/udc/aspeed_udc.c b/drivers/usb/gadget/udc/aspeed_udc.c
>> index 01968e2167f9..7dc2457c7460 100644
>> --- a/drivers/usb/gadget/udc/aspeed_udc.c
>> +++ b/drivers/usb/gadget/udc/aspeed_udc.c
>> @@ -1516,6 +1516,10 @@ static int ast_udc_probe(struct platform_device *pdev)
>> AST_UDC_EP_DMA_SIZE *
>> AST_UDC_NUM_ENDPOINTS,
>> &udc->ep0_buf_dma, GFP_KERNEL);
>> + if (!udc->ep0_buf) {
>> + rc = -ENOMEM;
>> + goto err;
>> + }
>>
>> udc->gadget.speed = USB_SPEED_UNKNOWN;
>> udc->gadget.max_speed = USB_SPEED_HIGH;
>> --
>> 2.25.1
>>
>
> Why is this just a duplicate of the patch previously submitted here:
> https://lore.kernel.org/r/20221125092833.74822-1-yuancan@huawei.com
>
> confused,
>
> greg k-h
Yes, it is the same as mine.
As the previous patch had not been merged into the Linux kernel,
my tool found the same error and report it.
And both of us chose the most concise way to fix the error.
That is why the patches are the same.
Thanks,
Jiang
Yes, it is the same as mine.
As the previous patch had not been merged into the Linux kernel,
my tool found the same error and report it.
And both of us chose the most concise way to fix the error.
That is why the patches are the same.
Thanks,
Jiang
Add the check for the return value of dma_alloc_coherent in order to
avoid NULL pointer dereference.
This flaw was found using an experimental static analysis tool we are
developing, APP-Miner, which has not been disclosed.
The allyesconfig build using GCC 9.3.0 shows no new warning. As we
don't have a UDC device to test with, no runtime testing was able to
be performed.
Signed-off-by: Jiasheng Jiang <jiasheng(a)iscas.ac.cn>
---
Changelog:
v2 -> v3:
1. Add information of finding tool and tests to commit message.
v1 -> v2:
1. Add "goto err;" when allocation fails.
---
drivers/usb/gadget/udc/aspeed_udc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/gadget/udc/aspeed_udc.c b/drivers/usb/gadget/udc/aspeed_udc.c
index 01968e2167f9..7dc2457c7460 100644
--- a/drivers/usb/gadget/udc/aspeed_udc.c
+++ b/drivers/usb/gadget/udc/aspeed_udc.c
@@ -1516,6 +1516,10 @@ static int ast_udc_probe(struct platform_device *pdev)
AST_UDC_EP_DMA_SIZE *
AST_UDC_NUM_ENDPOINTS,
&udc->ep0_buf_dma, GFP_KERNEL);
+ if (!udc->ep0_buf) {
+ rc = -ENOMEM;
+ goto err;
+ }
udc->gadget.speed = USB_SPEED_UNKNOWN;
udc->gadget.max_speed = USB_SPEED_HIGH;
--
2.25.1
Add the check for the return value of dma_alloc_coherent in order to
avoid NULL pointer dereference.
This flaw was found using an experimental static analysis tool we are
developing, APP-Miner, which has not been disclosed.
The allyesconfig build using GCC 9.3.0 shows no new warning. As we
don't have a UDC device to test with, no runtime testing was able to
be performed.
Signed-off-by: Jiasheng Jiang <jiasheng(a)iscas.ac.cn>
---
Changelog:
v1 -> v2:
1. Add "goto err;" when allocation fails.
---
drivers/usb/gadget/udc/aspeed_udc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/gadget/udc/aspeed_udc.c b/drivers/usb/gadget/udc/aspeed_udc.c
index 01968e2167f9..7dc2457c7460 100644
--- a/drivers/usb/gadget/udc/aspeed_udc.c
+++ b/drivers/usb/gadget/udc/aspeed_udc.c
@@ -1516,6 +1516,10 @@ static int ast_udc_probe(struct platform_device *pdev)
AST_UDC_EP_DMA_SIZE *
AST_UDC_NUM_ENDPOINTS,
&udc->ep0_buf_dma, GFP_KERNEL);
+ if (!udc->ep0_buf) {
+ rc = -ENOMEM;
+ goto err;
+ }
udc->gadget.speed = USB_SPEED_UNKNOWN;
udc->gadget.max_speed = USB_SPEED_HIGH;
--
2.25.1
Thanks, I found my mistake and I will submit a v2.
> And how did you find this potential problem? What tool did you use and
> why did you not follow the documentation for properly describing the
> tool?
I used a tool I wrote myself to find it, which is unpublished.
Therefore, I think it is okay to submit patches without description of the
tools.
Thanks,
Jiang