On Mon, Dec 27, 2021 at 1:52 AM <guangming.cao(a)mediatek.com> wrote:
>
> From: Guangming <Guangming.Cao(a)mediatek.com>
>
Thanks for submitting this!
> Add a size check for allcation since the allocation size is
nit: "allocation" above.
> always less than the total DRAM size.
In general, it might be good to add more context to the commit message
to better answer *why* this change is needed rather than what the
change is doing. ie: What negative thing happens without this change?
And so how does this change avoid or improve things?
> Signed-off-by: Guangming <Guangming.Cao(a)mediatek.com>
> Signed-off-by: jianjiao zeng <jianjiao.zeng(a)mediatek.com>
> ---
> v2: 1. update size limitation as total_dram page size.
> 2. update commit message
> ---
> drivers/dma-buf/dma-heap.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index 56bf5ad01ad5..e39d2be98d69 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
> struct dma_buf *dmabuf;
> int fd;
>
> + if (len / PAGE_SIZE > totalram_pages())
> + return -EINVAL;
This seems sane. I know ION used to have some 1/2 of memory cap to
avoid unnecessary memory pressure on crazy allocations.
Could you send again with an improved commit message?
thanks
-john
This patch series revisits the proposal for a GPU cgroup controller to
track and limit memory allocations by various device/allocator
subsystems. The patch series also contains a simple prototype to
illustrate how Android intends to implement DMA-BUF allocator
attribution using the GPU cgroup controller. The prototype does not
include resource limit enforcements.
History of the GPU cgroup controller
====================================
The GPU/DRM cgroup controller came into being when a consensus[1]
was reached that the resources it tracked were unsuitable to be integrated
into memcg. Originally, the proposed controller was specific to the DRM
subsystem and was intended to track GEM buffers and GPU-specific resources[2].
In order to help establish a unified memory accounting model for all GPU and
all related subsystems, Daniel Vetter put forth a suggestion to move it out of
the DRM subsystem so that it can be used by other DMA-BUF exporters as well[3].
This RFC proposes an interface that does the same.
[1]: https://patchwork.kernel.org/project/dri-devel/cover/20190501140438.9506-1-…
[2]: https://lore.kernel.org/amd-gfx/20210126214626.16260-1-brian.welty@intel.co…
[3]: https://lore.kernel.org/amd-gfx/YCVOl8%2F87bqRSQei@phenom.ffwll.local/
Hridya Valsaraju (6):
gpu: rfc: Proposal for a GPU cgroup controller
cgroup: gpu: Add a cgroup controller for allocator attribution of GPU
memory
dmabuf: heaps: Use the GPU cgroup charge/uncharge APIs
dma-buf: Add DMA-BUF exporter op to charge a DMA-BUF to a cgroup.
dmabuf: system_heap: implement dma-buf op for GPU cgroup charge
transfer
android: binder: Add a buffer flag to relinquish ownership of fds
Documentation/gpu/rfc/gpu-cgroup.rst | 192 +++++++++++++++++
Documentation/gpu/rfc/index.rst | 4 +
drivers/android/binder.c | 32 +++
drivers/dma-buf/dma-heap.c | 27 +++
drivers/dma-buf/heaps/system_heap.c | 68 ++++++
include/linux/cgroup_gpu.h | 120 +++++++++++
include/linux/cgroup_subsys.h | 4 +
include/linux/dma-buf.h | 18 ++
include/linux/dma-heap.h | 11 +
include/uapi/linux/android/binder.h | 1 +
init/Kconfig | 7 +
kernel/cgroup/Makefile | 1 +
kernel/cgroup/gpu.c | 305 +++++++++++++++++++++++++++
13 files changed, 790 insertions(+)
create mode 100644 Documentation/gpu/rfc/gpu-cgroup.rst
create mode 100644 include/linux/cgroup_gpu.h
create mode 100644 kernel/cgroup/gpu.c
--
2.34.1.703.g22d0c6ccf7-goog
Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The
problem was in ubuf->pages == ZERO_PTR.
ubuf->pagecount is calculated from arguments passed from user-space. If
user creates udmabuf with list.size == 0 then ubuf->pagecount will be
also equal to zero; it causes kmalloc_array() to return ZERO_PTR.
Fix it by validating ubuf->pagecount before passing it to
kmalloc_array().
Fixes: fbb0de795078 ("Add udmabuf misc device")
Reported-and-tested-by: syzbot+2c56b725ec547fa9cb29(a)syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin(a)gmail.com>
---
Happy New Year and Merry Christmas! :)
With regards,
Pavel Skripkin
---
drivers/dma-buf/udmabuf.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index c57a609db75b..e7330684d3b8 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -190,6 +190,10 @@ static long udmabuf_create(struct miscdevice *device,
if (ubuf->pagecount > pglimit)
goto err;
}
+
+ if (!ubuf->pagecount)
+ goto err;
+
ubuf->pages = kmalloc_array(ubuf->pagecount, sizeof(*ubuf->pages),
GFP_KERNEL);
if (!ubuf->pages) {
--
2.34.1
This short serie contains the maintainer status update sent recently by
Benjamin Gaignard (see [1] for details) and add new maintainers for
various stm & sti files.
[1] https://lore.kernel.org/lkml/20210706163033.795805-1-benjamin.gaignard@coll…
Benjamin Gaignard (1):
MAINTAINERS: Update Benjamin Gaignard maintainer status
Philippe Cornu (1):
MAINTAINERS: update drm/stm drm/sti and cec/sti maintainers
MAINTAINERS | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.17.1
On Tue, Dec 28, 2021 at 11:09 PM Weizhao Ouyang <o451686892(a)gmail.com> wrote:
>
> Fix cma_heap_buffer mutex lock area to protect vmap_cnt and vaddr. And
> move struct dma_heap_attachment to dma-heap.h so that vendor dma heaps
> can use it, the same behaviour as struct dma_buf_attachment.
>
Hey!
Thanks for submitting this patch! Apologies for the slow reply (was
out for the holidays).
This patch is combining two changes in one patch, so they need to be
split up. The locking change looks sane, but moving the
dma_heap_attachment may need some extra justification as changing
upstream code just to support out of tree code isn't usually done (if
there was some benefit to the in-tree code, that would be fine
though).
I'd also be eager to try to get the vendor heap to be merged, assuming
we can also merge an upstream user for it.
thanks
-john
Hi Xianting,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.16-rc6 next-20211217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Xianting-Tian/udmabuf-put-dmabuf-i…
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git a7904a538933c525096ca2ccde1e60d0ee62c08e
config: x86_64-randconfig-r024-20211220 (https://download.01.org/0day-ci/archive/20211220/202112202114.4rnU3YZF-lkp@…)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 555eacf75f21cd1dfc6363d73ad187b730349543)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/322781a4da9de4a3057afd933108d23ca7f…
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Xianting-Tian/udmabuf-put-dmabuf-in-case-of-get-fd-failed/20211220-134433
git checkout 322781a4da9de4a3057afd933108d23ca7f5282e
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/dma-buf/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp(a)intel.com>
All warnings (new ones prefixed by >>):
drivers/dma-buf/udmabuf.c:293:1: error: function definition is not allowed here
{
^
drivers/dma-buf/udmabuf.c:312:1: error: function definition is not allowed here
{
^
drivers/dma-buf/udmabuf.c:334:1: error: function definition is not allowed here
{
^
drivers/dma-buf/udmabuf.c:353:20: error: use of undeclared identifier 'udmabuf_ioctl'
.unlocked_ioctl = udmabuf_ioctl,
^
drivers/dma-buf/udmabuf.c:355:20: error: use of undeclared identifier 'udmabuf_ioctl'
.compat_ioctl = udmabuf_ioctl,
^
drivers/dma-buf/udmabuf.c:366:1: error: function definition is not allowed here
{
^
drivers/dma-buf/udmabuf.c:371:1: error: function definition is not allowed here
{
^
drivers/dma-buf/udmabuf.c:375:13: error: use of undeclared identifier 'udmabuf_dev_init'
module_init(udmabuf_dev_init)
^
drivers/dma-buf/udmabuf.c:375:13: error: use of undeclared identifier 'udmabuf_dev_init'
drivers/dma-buf/udmabuf.c:376:13: error: use of undeclared identifier 'udmabuf_dev_exit'
module_exit(udmabuf_dev_exit)
^
drivers/dma-buf/udmabuf.c:379:26: error: expected '}'
MODULE_LICENSE("GPL v2");
^
drivers/dma-buf/udmabuf.c:166:1: note: to match this '{'
{
^
>> drivers/dma-buf/udmabuf.c:351:37: warning: ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement]
static const struct file_operations udmabuf_fops = {
^
1 warning and 11 errors generated.
vim +351 drivers/dma-buf/udmabuf.c
fbb0de79507819 Gerd Hoffmann 2018-08-27 350
fbb0de79507819 Gerd Hoffmann 2018-08-27 @351 static const struct file_operations udmabuf_fops = {
fbb0de79507819 Gerd Hoffmann 2018-08-27 352 .owner = THIS_MODULE,
fbb0de79507819 Gerd Hoffmann 2018-08-27 353 .unlocked_ioctl = udmabuf_ioctl,
d4a197f4047e01 Kristian H. Kristensen 2020-09-03 354 #ifdef CONFIG_COMPAT
d4a197f4047e01 Kristian H. Kristensen 2020-09-03 355 .compat_ioctl = udmabuf_ioctl,
d4a197f4047e01 Kristian H. Kristensen 2020-09-03 356 #endif
fbb0de79507819 Gerd Hoffmann 2018-08-27 357 };
fbb0de79507819 Gerd Hoffmann 2018-08-27 358
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org