Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

1 participants
2905 discussions

Re: [RFC PATCH v3 06/12] memory-provider: dmabuf devmem memory provider

by Jakub Kicinski

On Sun, 5 Nov 2023 18:44:05 -0800 Mina Almasry wrote: > +static int mp_dmabuf_devmem_init(struct page_pool *pool) > +{ > + struct netdev_dmabuf_binding *binding = pool->mp_priv; > + > + if (!binding) > + return -EINVAL; > + > + if (pool->p.flags & PP_FLAG_DMA_MAP || > + pool->p.flags & PP_FLAG_DMA_SYNC_DEV) > + return -EOPNOTSUPP; This looks backwards, we should _force_ the driver to use the dma mapping built into the page pool APIs, to isolate the driver from how the DMA addr actually gets obtained. Right? Maybe seeing driver patches would illuminate.

1 year, 7 months

Re: [RFC PATCH v3 10/12] tcp: RX path for devmem TCP

by Jakub Kicinski

On Thu, 09 Nov 2023 12:05:37 +0100 Paolo Abeni wrote: > > I suppose we just disagree on the elegance of the API. > > FWIW, I think sockopt +cmsg is the right API. FWIW it's fine by me as well.

1 year, 7 months

Re: [RFC PATCH v3 12/12] selftests: add ncdevmem, netcat for devmem TCP

by Jakub Kicinski

My brain is slightly fried after trying to catch up on the thread for close to 2h. So forgive me if I'm missing something. This applies to all emails I'm about to send :) On Sun, 5 Nov 2023 18:44:11 -0800 Mina Almasry wrote: > + trigger_device_reset(); The user space must not be responsible for the reset. We can add some temporary "recreate page pools" ndo until the queue API is ready. But it should not be visible to the user in any way. And then the kernel can issue the same reset when the netlink socket dies to flush device free lists. Maybe we should also add a "allow device/all-queues reload" flag to the netlink API to differentiate drivers which can't implement full queue API later on. We want to make sure the defaults work well in our "target design", rather than at the first stage. And target design will reload queues one by one.

1 year, 7 months

Re: [RFC PATCH v2] drm/test: add a test suite for GEM objects backed by shmem

by Maxime Ripard

On Wed, Nov 08, 2023 at 02:42:03PM +0100, Marco Pagani wrote: > This patch introduces an initial KUnit test suite for GEM objects > backed by shmem buffers. > > Suggested-by: Javier Martinez Canillas <javierm(a)redhat.com> > Signed-off-by: Marco Pagani <marpagan(a)redhat.com> > > v2: > - Improved description of test cases > - Cleaner error handling using KUnit actions > - Alphabetical order in Kconfig and Makefile > --- > drivers/gpu/drm/Kconfig | 9 +- > drivers/gpu/drm/tests/Makefile | 5 +- > drivers/gpu/drm/tests/drm_gem_shmem_test.c | 381 +++++++++++++++++++++ > 3 files changed, 389 insertions(+), 6 deletions(-) > create mode 100644 drivers/gpu/drm/tests/drm_gem_shmem_test.c > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 3eee8636f847..a2551c8c393a 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -76,14 +76,15 @@ config DRM_KUNIT_TEST > tristate "KUnit tests for DRM" if !KUNIT_ALL_TESTS > depends on DRM && KUNIT > select PRIME_NUMBERS > + select DRM_BUDDY > select DRM_DISPLAY_DP_HELPER > select DRM_DISPLAY_HELPER > - select DRM_LIB_RANDOM > - select DRM_KMS_HELPER > - select DRM_BUDDY > + select DRM_EXEC > select DRM_EXPORT_FOR_TESTS if m > + select DRM_GEM_SHMEM_HELPER > + select DRM_KMS_HELPER > select DRM_KUNIT_TEST_HELPERS > - select DRM_EXEC > + select DRM_LIB_RANDOM > default KUNIT_ALL_TESTS > help > This builds unit tests for DRM. This option is not useful for > diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile > index ba7baa622675..d6183b3d7688 100644 > --- a/drivers/gpu/drm/tests/Makefile > +++ b/drivers/gpu/drm/tests/Makefile > @@ -9,15 +9,16 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \ > drm_connector_test.o \ > drm_damage_helper_test.o \ > drm_dp_mst_helper_test.o \ > + drm_exec_test.o \ > drm_format_helper_test.o \ > drm_format_test.o \ > drm_framebuffer_test.o \ > + drm_gem_shmem_test.o \ > drm_managed_test.o \ > drm_mm_test.o \ > drm_modes_test.o \ > drm_plane_helper_test.o \ > drm_probe_helper_test.o \ > - drm_rect_test.o \ > - drm_exec_test.o > + drm_rect_test.o Thanks for reordering the tests and symbols, but they should part of a preliminary patch. > CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN) > diff --git a/drivers/gpu/drm/tests/drm_gem_shmem_test.c b/drivers/gpu/drm/tests/drm_gem_shmem_test.c > new file mode 100644 > index 000000000000..983380490673 > --- /dev/null > +++ b/drivers/gpu/drm/tests/drm_gem_shmem_test.c > @@ -0,0 +1,381 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * KUnit test suite for GEM objects backed by shmem buffers > + * > + * Copyright (C) 2023 Red Hat, Inc. > + * > + * Author: Marco Pagani <marpagan(a)redhat.com> > + */ > + > +#include <linux/dma-buf.h> > +#include <linux/iosys-map.h> > +#include <linux/sizes.h> > + > +#include <kunit/test.h> > + > +#include <drm/drm_device.h> > +#include <drm/drm_drv.h> > +#include <drm/drm_gem.h> > +#include <drm/drm_gem_shmem_helper.h> > +#include <drm/drm_kunit_helpers.h> > + > +#define TEST_SIZE SZ_1M > +#define TEST_BYTE 0xae > + > +struct fake_dev { > + struct drm_device drm_dev; > + struct device *dev; AFAICS, you're not using the dev pointer anywhere. You could remove the fake_dev struct entirely and pass the drm_device pointer in test->priv > +}; > + > +/* > + * Wrappers to avoid an explicit type casting when passing action > + * functions to kunit_add_action(). > + */ > +static void kfree_wrapper(void *p) > +{ > + kfree(p); > +} > + > +static void sg_free_table_wrapper(void *sgt) > +{ > + sg_free_table(sgt); > +} > + > +static void drm_gem_shmem_free_wrapper(void *shmem) > +{ > + drm_gem_shmem_free(shmem); > +} I think you need to explicitly cast the pointer (or do a temporary assignment to the proper type) to avoid a compiler warning. > +/* > + * Test creating a shmem GEM object backed by shmem buffer. The test > + * case succeeds if the GEM object is successfully allocated with the > + * shmem file node and object functions attributes set, and the size > + * attribute is equal to the correct size. > + */ Thanks for all those comments, it's super helpful > +static void drm_gem_shmem_test_obj_create(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + KUNIT_EXPECT_EQ(test, shmem->base.size, TEST_SIZE); > + KUNIT_EXPECT_NOT_NULL(test, shmem->base.filp); > + KUNIT_EXPECT_NOT_NULL(test, shmem->base.funcs); > + > + drm_gem_shmem_free(shmem); > +} > + > +/* > + * Test creating a shmem GEM object from a scatter/gather table exported > + * via a DMA-BUF. The test case succeed if the GEM object is successfully > + * created with the shmem file node attribute equal to NULL and the sgt > + * attribute pointing to the scatter/gather table that has been imported. > + */ > +static void drm_gem_shmem_test_obj_create_private(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + struct drm_gem_object *gem_obj; > + struct dma_buf buf_mock; > + struct dma_buf_attachment attach_mock; > + struct sg_table *sgt; > + char *buf; > + int ret; > + > + /* Create a mock scatter/gather table */ > + buf = kunit_kzalloc(test, TEST_SIZE, GFP_KERNEL); > + KUNIT_ASSERT_NOT_NULL(test, buf); > + > + sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); > + KUNIT_ASSERT_NOT_NULL(test, sgt); > + > + ret = kunit_add_action_or_reset(test, kfree_wrapper, sgt); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > + ret = sg_alloc_table(sgt, 1, GFP_KERNEL); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > + ret = kunit_add_action_or_reset(test, sg_free_table_wrapper, sgt); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > + sg_init_one(sgt->sgl, buf, TEST_SIZE); > + > + /* Init a mock DMA-BUF */ > + buf_mock.size = TEST_SIZE; > + attach_mock.dmabuf = &buf_mock; > + > + gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > + KUNIT_EXPECT_EQ(test, gem_obj->size, TEST_SIZE); > + KUNIT_EXPECT_NULL(test, gem_obj->filp); > + KUNIT_EXPECT_NOT_NULL(test, gem_obj->funcs); > + > + /* The scatter/gather table will be freed by drm_gem_shmem_free */ > + kunit_remove_action(test, sg_free_table_wrapper, sgt); > + kunit_remove_action(test, kfree_wrapper, sgt); > + > + shmem = to_drm_gem_shmem_obj(gem_obj); > + KUNIT_EXPECT_PTR_EQ(test, shmem->sgt, sgt); > + > + drm_gem_shmem_free(shmem); > +} > + > +/* > + * Test pinning backing pages for a shmem GEM object. The test case > + * succeeds if a suitable number of backing pages are allocated, and > + * the pages table counter attribute is increased by one. > + */ > +static void drm_gem_shmem_test_pin_pages(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + int i, ret; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + KUNIT_EXPECT_NULL(test, shmem->pages); > + KUNIT_EXPECT_EQ(test, shmem->pages_use_count, 0); > + > + ret = kunit_add_action_or_reset(test, drm_gem_shmem_free_wrapper, shmem); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > + ret = drm_gem_shmem_pin(shmem); > + KUNIT_ASSERT_EQ(test, ret, 0); > + KUNIT_ASSERT_NOT_NULL(test, shmem->pages); > + KUNIT_EXPECT_EQ(test, shmem->pages_use_count, 1); > + > + for (i = 0; i < (shmem->base.size >> PAGE_SHIFT); i++) > + KUNIT_ASSERT_NOT_NULL(test, shmem->pages[i]); > + > + drm_gem_shmem_unpin(shmem); > + KUNIT_EXPECT_NULL(test, shmem->pages); > + KUNIT_EXPECT_EQ(test, shmem->pages_use_count, 0); > +} > + > +/* > + * Test creating a virtual mapping for a shmem GEM object. The test > + * case succeeds if the backing memory is mapped and the reference > + * counter for virtual mapping is increased by one. Moreover, the test > + * case writes and then reads a test pattern over the mapped memory. > + */ > +static void drm_gem_shmem_test_vmap(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + struct iosys_map map; > + int ret, i; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + KUNIT_EXPECT_NULL(test, shmem->vaddr); > + KUNIT_EXPECT_EQ(test, shmem->vmap_use_count, 0); > + > + ret = kunit_add_action_or_reset(test, drm_gem_shmem_free_wrapper, shmem); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > + ret = drm_gem_shmem_vmap(shmem, &map); > + KUNIT_ASSERT_EQ(test, ret, 0); > + KUNIT_ASSERT_NOT_NULL(test, shmem->vaddr); > + KUNIT_ASSERT_FALSE(test, iosys_map_is_null(&map)); > + KUNIT_EXPECT_EQ(test, shmem->vmap_use_count, 1); > + > + iosys_map_memset(&map, 0, TEST_BYTE, TEST_SIZE); > + for (i = 0; i < TEST_SIZE; i++) > + KUNIT_EXPECT_EQ(test, iosys_map_rd(&map, i, u8), TEST_BYTE); > + > + drm_gem_shmem_vunmap(shmem, &map); > + KUNIT_EXPECT_NULL(test, shmem->vaddr); > + KUNIT_EXPECT_EQ(test, shmem->vmap_use_count, 0); > +} > + > +/* > + * Test exporting a scatter/gather table of pinned pages suitable for > + * PRIME usage from a shmem GEM object. The test case succeeds if a > + * scatter/gather table large enough to accommodate the backing memory > + * is successfully exported. > + */ > +static void drm_gem_shmem_test_get_pages_sgt(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + struct sg_table *sgt; > + struct scatterlist *sg; > + unsigned int si, len = 0; > + int ret; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + > + ret = kunit_add_action_or_reset(test, drm_gem_shmem_free_wrapper, shmem); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > + ret = drm_gem_shmem_pin(shmem); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > + sgt = drm_gem_shmem_get_sg_table(shmem); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, sgt); > + KUNIT_EXPECT_NULL(test, shmem->sgt); > + > + ret = kunit_add_action_or_reset(test, sg_free_table_wrapper, sgt); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > + for_each_sgtable_sg(sgt, sg, si) { > + KUNIT_EXPECT_NOT_NULL(test, sg); > + len += sg->length; > + } > + > + KUNIT_EXPECT_GE(test, len, TEST_SIZE); > +} > + > +/* > + * Test pinning pages and exporting a scatter/gather table suitable for > + * driver usage from a shmem GEM object. The test case succeeds if the > + * backing pages are pinned and a scatter/gather table large enough to > + * accommodate the backing memory is successfully exported. > + */ > +static void drm_gem_shmem_test_get_sg_table(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + struct sg_table *sgt; > + struct scatterlist *sg; > + unsigned int si, len, ret = 0; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + > + ret = kunit_add_action_or_reset(test, drm_gem_shmem_free_wrapper, shmem); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > + /* The scatter/gather table will be freed by drm_gem_shmem_free */ > + sgt = drm_gem_shmem_get_pages_sgt(shmem); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, sgt); > + KUNIT_ASSERT_NOT_NULL(test, shmem->pages); > + KUNIT_EXPECT_EQ(test, shmem->pages_use_count, 1); > + KUNIT_EXPECT_PTR_EQ(test, sgt, shmem->sgt); > + > + for_each_sgtable_sg(sgt, sg, si) { > + KUNIT_EXPECT_NOT_NULL(test, sg); > + len += sg->length; > + } > + > + KUNIT_EXPECT_GE(test, len, TEST_SIZE); > +} > + > +/* > + * Test updating the madvise state of a shmem GEM object. The test > + * case checks that the function for setting madv updates it only if > + * its current value is greater or equal than zero and returns false > + * if it has a negative value. > + */ > +static void drm_gem_shmem_test_madvise(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + int ret; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + KUNIT_ASSERT_EQ(test, shmem->madv, 0); > + > + ret = kunit_add_action_or_reset(test, drm_gem_shmem_free_wrapper, shmem); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > + ret = drm_gem_shmem_madvise(shmem, 1); > + KUNIT_EXPECT_TRUE(test, ret); > + KUNIT_ASSERT_EQ(test, shmem->madv, 1); > + > + /* Set madv to a negative value */ > + ret = drm_gem_shmem_madvise(shmem, -1); > + KUNIT_EXPECT_FALSE(test, ret); > + KUNIT_ASSERT_EQ(test, shmem->madv, -1); > + > + /* Check that madv cannot be set back to a positive value */ > + ret = drm_gem_shmem_madvise(shmem, 0); > + KUNIT_EXPECT_FALSE(test, ret); > + KUNIT_ASSERT_EQ(test, shmem->madv, -1); > +} > + > +/* > + * Test purging a shmem GEM object. First, assert that a newly created > + * shmem GEM object is not purgeable. Then, set madvise to a positive > + * value and call drm_gem_shmem_get_pages_sgt() to pin and dma-map the > + * backing pages. Finally, assert that the shmem GEM object is now > + * purgeable and purge it. > + */ > +static void drm_gem_shmem_test_purge(struct kunit *test) > +{ > + struct fake_dev *fdev = test->priv; > + struct drm_gem_shmem_object *shmem; > + struct sg_table *sgt; > + int ret; > + > + shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem); > + > + ret = kunit_add_action_or_reset(test, drm_gem_shmem_free_wrapper, shmem); > + KUNIT_ASSERT_EQ(test, ret, 0); > + > + ret = drm_gem_shmem_is_purgeable(shmem); > + KUNIT_EXPECT_FALSE(test, ret); > + > + ret = drm_gem_shmem_madvise(shmem, 1); > + KUNIT_EXPECT_TRUE(test, ret); > + > + /* The scatter/gather table will be freed by drm_gem_shmem_free */ > + sgt = drm_gem_shmem_get_pages_sgt(shmem); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, sgt); > + > + ret = drm_gem_shmem_is_purgeable(shmem); > + KUNIT_EXPECT_TRUE(test, ret); > + > + drm_gem_shmem_purge(shmem); > + KUNIT_EXPECT_NULL(test, shmem->pages); > + KUNIT_EXPECT_NULL(test, shmem->sgt); > + KUNIT_EXPECT_EQ(test, shmem->madv, -1); > +} > + > +static int drm_gem_shmem_test_init(struct kunit *test) > +{ > + struct fake_dev *fdev; > + struct device *dev; > + > + /* Allocate a parent device */ > + dev = drm_kunit_helper_alloc_device(test); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dev); > + > + /* > + * The DRM core will automatically initialize the GEM core and create > + * a DRM Memory Manager object which provides an address space pool > + * for GEM objects allocation. > + */ > + fdev = drm_kunit_helper_alloc_drm_device(test, dev, struct fake_dev, > + drm_dev, DRIVER_GEM); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, fdev); > + > + fdev->dev = dev; > + test->priv = fdev; > + > + return 0; > +} > + > +static struct kunit_case drm_gem_shmem_test_cases[] = { > + KUNIT_CASE(drm_gem_shmem_test_obj_create), > + KUNIT_CASE(drm_gem_shmem_test_obj_create_private), > + KUNIT_CASE(drm_gem_shmem_test_pin_pages), > + KUNIT_CASE(drm_gem_shmem_test_vmap), > + KUNIT_CASE(drm_gem_shmem_test_get_pages_sgt), > + KUNIT_CASE(drm_gem_shmem_test_get_sg_table), > + KUNIT_CASE(drm_gem_shmem_test_madvise), > + KUNIT_CASE(drm_gem_shmem_test_purge), > + {} > +}; > + > +static struct kunit_suite drm_gem_shmem_suite = { > + .name = "drm_gem_shmem", > + .init = drm_gem_shmem_test_init, > + .test_cases = drm_gem_shmem_test_cases > +}; > + > +kunit_test_suite(drm_gem_shmem_suite); Looks great otherwise, thanks! Maxime

1 year, 7 months

Re: [RFC PATCH v3 07/12] page-pool: device memory support

by Christian König

Am 09.11.23 um 04:20 schrieb Mina Almasry: > [SNIP] >> But we might be able to do something as folio is doing now, mm subsystem >> is still seeing 'struct folio/page', but other subsystem like slab is using >> 'struct slab', and there is still some common fields shared between >> 'struct folio' and 'struct slab'. >> > In my eyes this is almost exactly what I suggested in RFC v1 and got > immediately nacked with no room to negotiate. What we did for v1 is to > allocate struct pages for dma-buf to make dma-bufs look like struct > page to mm subsystem. Almost exactly what you're describing above. > It's a no-go. I don't think renaming struct page to netmem is going to > move the needle (it also re-introduces code-churn). What I feel like I > learnt is that dma-bufs are not struct pages and can't be made to look > like one, I think. Yeah, that pretty much hits the nail on the head. What was not mentioned yet and you could potentially try to do is to go the other way around. In other words instead of importing a DMA-buf file descriptor into the page-pool, you take some netdev page-pool pages and export them as DMA-buf handle. All you then need to do is to implement the necessary DMA-buf interface, e.g. wait for DMA-fences before accessing stuff, when you have an async operation install a DMA-fence so that other can wait for your operation to finish etc.. etc.. This still doesn't gives you peer 2 peer over for example the PCIe bus, but it would give you zero copy in the sense that a GPU or other acceleration device directly writes stuff into memory a network device can work with. We already have some similar functionality for at least Intel and AMD hw where an userptr mechanism is used to make malloced memory (backed by normal struct pages) available to the GPU. The problem with this approach is that most GPUs currently can't do good recoverable page faults which in turn makes the whole MMU notifier based approach just horrible inefficient. Just giving a few more pointers you might want to look into... Cheers, Christian.

1 year, 7 months

[syzbot] [dri?] kernel BUG in vmf_insert_pfn_prot (2)

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 9e6c269de404 Merge tag 'i2c-for-6.5-rc7' of git://git.kern.. git tree: upstream console+strace: https://syzkaller.appspot.com/x/log.txt?x=110b32d3a80000 kernel config: https://syzkaller.appspot.com/x/.config?x=aa796b6080b04102 dashboard link: https://syzkaller.appspot.com/bug?extid=398e17b61dab22cc56bc compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14284307a80000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/481d8421bfb2/disk-9e6c269d.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/5ec626f94634/vmlinux-9e6c269d.… kernel image: https://storage.googleapis.com/syzbot-assets/ab1e59619bd6/bzImage-9e6c269d.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+398e17b61dab22cc56bc(a)syzkaller.appspotmail.com ------------[ cut here ]------------ kernel BUG at mm/memory.c:2214! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 5157 Comm: syz-executor.3 Not tainted 6.5.0-rc6-syzkaller-00253-g9e6c269de404 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 RIP: 0010:vmf_insert_pfn_prot+0x247/0x430 mm/memory.c:2214 Code: 0f 0b e8 0c 4f c0 ff 49 89 ef bf 20 00 00 00 41 83 e7 28 4c 89 fe e8 88 4a c0 ff 49 83 ff 20 0f 85 aa fe ff ff e8 e9 4e c0 ff <0f> 0b 48 bd ff ff ff ff ff ff 0f 00 e8 d8 4e c0 ff 4c 89 f6 48 89 RSP: 0018:ffffc9000415f750 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8880275a0d00 RCX: 0000000000000000 RDX: ffff888018379dc0 RSI: ffffffff81c5b9b7 RDI: 0000000000000007 RBP: 000000000c140477 R08: 0000000000000007 R09: 0000000000000020 R10: 0000000000000020 R11: 000000000000001f R12: 0000000020ffc000 R13: 1ffff9200082beeb R14: 000000000007e79e R15: 0000000000000020 FS: 00007f235bd9a6c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ffc000 CR3: 0000000022a32000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> drm_gem_shmem_fault+0x1ea/0x3a0 drivers/gpu/drm/drm_gem_shmem_helper.c:563 __do_fault+0x107/0x5f0 mm/memory.c:4198 do_read_fault mm/memory.c:4547 [inline] do_fault mm/memory.c:4670 [inline] do_pte_missing mm/memory.c:3664 [inline] handle_pte_fault mm/memory.c:4939 [inline] __handle_mm_fault+0x27e0/0x3b80 mm/memory.c:5079 handle_mm_fault+0x2ab/0x9d0 mm/memory.c:5233 do_user_addr_fault+0x446/0xfc0 arch/x86/mm/fault.c:1392 handle_page_fault arch/x86/mm/fault.c:1486 [inline] exc_page_fault+0x5c/0xd0 arch/x86/mm/fault.c:1542 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:rep_movs_alternative+0x4a/0xb0 arch/x86/lib/copy_user_64.S:71 Code: 75 f1 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8b 06 48 89 07 48 83 c6 08 48 83 c7 08 83 e9 08 74 df 83 f9 08 73 e8 eb c9 <f3> a4 c3 0f 1f 00 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c 8b 5e 18 4c RSP: 0018:ffffc9000415fb50 EFLAGS: 00050206 RAX: 0000000000000001 RBX: 0000000020ffc000 RCX: 0000000000001000 RDX: 0000000000000000 RSI: 0000000020ffc000 RDI: ffff88807b764000 RBP: 0000000000001000 R08: 0000000000000001 R09: ffffed100f6ec9ff R10: ffff88807b764fff R11: 0000000000000000 R12: 0000000020ffd000 R13: ffff88807b764000 R14: 0000000000000000 R15: 0000000020ffc000 copy_user_generic arch/x86/include/asm/uaccess_64.h:112 [inline] raw_copy_from_user arch/x86/include/asm/uaccess_64.h:127 [inline] _copy_from_user+0xc2/0xf0 lib/usercopy.c:23 copy_from_user include/linux/uaccess.h:183 [inline] snd_rawmidi_kernel_write1+0x360/0x860 sound/core/rawmidi.c:1618 snd_rawmidi_write+0x278/0xc10 sound/core/rawmidi.c:1687 vfs_write+0x2a4/0xe40 fs/read_write.c:582 ksys_write+0x1f0/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f235b07cae9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f235bd9a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f235b19bf80 RCX: 00007f235b07cae9 RDX: 00000000fffffd2c RSI: 0000000020000000 RDI: 0000000000000005 RBP: 00007f235b0c847a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f235b19bf80 R15: 00007ffd9cdf0fe8 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:vmf_insert_pfn_prot+0x247/0x430 mm/memory.c:2214 Code: 0f 0b e8 0c 4f c0 ff 49 89 ef bf 20 00 00 00 41 83 e7 28 4c 89 fe e8 88 4a c0 ff 49 83 ff 20 0f 85 aa fe ff ff e8 e9 4e c0 ff <0f> 0b 48 bd ff ff ff ff ff ff 0f 00 e8 d8 4e c0 ff 4c 89 f6 48 89 RSP: 0018:ffffc9000415f750 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8880275a0d00 RCX: 0000000000000000 RDX: ffff888018379dc0 RSI: ffffffff81c5b9b7 RDI: 0000000000000007 RBP: 000000000c140477 R08: 0000000000000007 R09: 0000000000000020 R10: 0000000000000020 R11: 000000000000001f R12: 0000000020ffc000 R13: 1ffff9200082beeb R14: 000000000007e79e R15: 0000000000000020 FS: 00007f235bd9a6c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f93c20ffac1 CR3: 0000000022a32000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 ---------------- Code disassembly (best guess): 0: 75 f1 jne 0xfffffff3 2: c3 ret 3: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1) a: 00 00 00 00 e: 66 90 xchg %ax,%ax 10: 48 8b 06 mov (%rsi),%rax 13: 48 89 07 mov %rax,(%rdi) 16: 48 83 c6 08 add $0x8,%rsi 1a: 48 83 c7 08 add $0x8,%rdi 1e: 83 e9 08 sub $0x8,%ecx 21: 74 df je 0x2 23: 83 f9 08 cmp $0x8,%ecx 26: 73 e8 jae 0x10 28: eb c9 jmp 0xfffffff3 * 2a: f3 a4 rep movsb %ds:(%rsi),%es:(%rdi) <-- trapping instruction 2c: c3 ret 2d: 0f 1f 00 nopl (%rax) 30: 4c 8b 06 mov (%rsi),%r8 33: 4c 8b 4e 08 mov 0x8(%rsi),%r9 37: 4c 8b 56 10 mov 0x10(%rsi),%r10 3b: 4c 8b 5e 18 mov 0x18(%rsi),%r11 3f: 4c rex.WR --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. If the bug is already fixed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to overwrite bug's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the bug is a duplicate of another bug, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup

1 year, 7 months

Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags

by David Laight

From: Mina Almasry > Sent: 06 November 2023 02:44 > > For device memory TCP, we expect the skb headers to be available in host > memory for access, and we expect the skb frags to be in device memory > and unaccessible to the host. We expect there to be no mixing and > matching of device memory frags (unaccessible) with host memory frags > (accessible) in the same skb. > > Add a skb->devmem flag which indicates whether the frags in this skb > are device memory frags or not. > ... > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h > index 1fae276c1353..8fb468ff8115 100644 > --- a/include/linux/skbuff.h > +++ b/include/linux/skbuff.h > @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t; > * @csum_level: indicates the number of consecutive checksums found in > * the packet minus one that have been verified as > * CHECKSUM_UNNECESSARY (max 3) > + * @devmem: indicates that all the fragments in this skb are backed by > + * device memory. > * @dst_pending_confirm: need to confirm neighbour > * @decrypted: Decrypted SKB > * @slow_gro: state present at GRO time, slower prepare step required > @@ -991,7 +993,7 @@ struct sk_buff { > #if IS_ENABLED(CONFIG_IP_SCTP) > __u8 csum_not_inet:1; > #endif > - > + __u8 devmem:1; > #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS) > __u16 tc_index; /* traffic control index */ > #endif > @@ -1766,6 +1768,12 @@ static inline void skb_zcopy_downgrade_managed(struct sk_buff *skb) > __skb_zcopy_downgrade_managed(skb); > } Doesn't that bloat struct sk_buff? I'm not sure there are any spare bits available. Although CONFIG_NET_SWITCHDEV and CONFIG_NET_SCHED seem to already add padding. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)

1 year, 7 months

Re: [RFC PATCH] drm/test: add a test suite for GEM objects backed by shmem

by Maxime Ripard

On Mon, Oct 30, 2023 at 11:58:20AM +0100, Marco Pagani wrote: > On 2023-10-25 10:43, Maxime Ripard wrote: > > On Tue, Oct 24, 2023 at 07:14:25PM +0200, Marco Pagani wrote: > >>>> +static void drm_gem_shmem_test_obj_create_private(struct kunit *test) > >>>> +{ > >>>> + struct fake_dev *fdev = test->priv; > >>>> + struct drm_gem_shmem_object *shmem; > >>>> + struct drm_gem_object *gem_obj; > >>>> + struct dma_buf buf_mock; > >>>> + struct dma_buf_attachment attach_mock; > >>>> + struct sg_table *sgt; > >>>> + char *buf; > >>>> + int ret; > >>>> + > >>>> + /* Create a mock scatter/gather table */ > >>>> + buf = kunit_kzalloc(test, TEST_SIZE, GFP_KERNEL); > >>>> + KUNIT_ASSERT_NOT_NULL(test, buf); > >>>> + > >>>> + sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); > >>>> + KUNIT_ASSERT_NOT_NULL(test, sgt); > >>>> + > >>>> + ret = sg_alloc_table(sgt, 1, GFP_KERNEL); > >>>> + KUNIT_ASSERT_EQ(test, ret, 0); > >>>> + sg_init_one(sgt->sgl, buf, TEST_SIZE); > >>>> + > >>>> + /* Init a mock DMA-BUF */ > >>>> + buf_mock.size = TEST_SIZE; > >>>> + attach_mock.dmabuf = &buf_mock; > >>>> + > >>>> + gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); > >>>> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > >>>> + KUNIT_ASSERT_EQ(test, gem_obj->size, TEST_SIZE); > >>>> + KUNIT_ASSERT_NULL(test, gem_obj->filp); > >>>> + KUNIT_ASSERT_NOT_NULL(test, gem_obj->funcs); > >>>> + > >>>> + shmem = to_drm_gem_shmem_obj(gem_obj); > >>>> + KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); > >>>> + > >>>> + /* The scatter/gather table is freed by drm_gem_shmem_free */ > >>>> + drm_gem_shmem_free(shmem); > >>>> +} > >>> > >>> KUNIT_ASSERT_* will stop the execution of the test on failure, you > >>> should probably use a bit more of KUNIT_EXPECT_* calls otherwise you'll > >>> leak resources. > >>> > >>> You also probably want to use a kunit_action to clean up and avoid that > >>> whole discussion > >>> > >> > >> You are right. I slightly prefer using KUnit expectations (unless actions > >> are strictly necessary) since I feel using actions makes test cases a bit > >> less straightforward to understand. Is this okay for you? > > > > I disagree. Actions make it easier to reason about, even when comparing > > assertion vs expectation > > > > Like, for the call to sg_alloc_table and > > drm_gem_shmem_prime_import_sg_table(), the reasonable use of assert vs > > expect would be something like: > > > > sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); > > KUNIT_ASSERT_NOT_NULL(test, sgt); > > > > ret = sg_alloc_table(sgt, 1, GFP_KERNEL); > > KUNIT_ASSERT_EQ(test, ret, 0); > > > > /* > > * Here, it's already not super clear whether you want to expect vs > > * assert. expect will make you handle the failure case later, assert will > > * force you to call kfree on sgt. Both kind of suck in their own ways. > > */ > > > > sg_init_one(sgt->sgl, buf, TEST_SIZE); > > > > gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); > > KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > > > > /* > > * If the assert fails, we forgot to call sg_free_table(sgt) and kfree(sgt). > > */ > > > > KUNIT_EXPECT_EQ(test, gem_obj->size, TEST_SIZE); > > KUNIT_EXPECT_NULL(test, gem_obj->filp); > > KUNIT_EXPECT_NOT_NULL(test, gem_obj->funcs); > > > > /* > > * And here we have to handle the case where the expectation was wrong, > > * but the test still continued. > > */ > > > > But if you're not using an action, you still have to call kfree(sgt), > > which means that you might still > > > > shmem = to_drm_gem_shmem_obj(gem_obj); > > KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); > > > > /* > > * If the assertion fails, we now have to call drm_gem_shmem_free(shmem) > > */ > > > > /* The scatter/gather table is freed by drm_gem_shmem_free */ > > drm_gem_shmem_free(shmem); > > > > /* everything's fine now */ > > > > The semantics around drm_gem_shmem_free make it a bit convoluted, but > > doing it using goto/labels, plus handling the assertions and error > > reporting would be difficult. > > > > Using actions, we have: > > > > sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); > > KUNIT_ASSERT_NOT_NULL(test, sgt); > > > > ret = kunit_add_action_or_reset(test, kfree_wrapper, sgt); > > KUNIT_ASSERT_EQ(test, ret, 0); > > > > ret = sg_alloc_table(sgt, 1, GFP_KERNEL); > > KUNIT_ASSERT_EQ(test, ret, 0); > > > > ret = kunit_add_action_or_reset(test, sg_free_table_wrapper, sgt); > > KUNIT_ASSERT_EQ(test, ret, 0); > > > > sg_init_one(sgt->sgl, buf, TEST_SIZE); > > > > gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); > > KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > > KUNIT_EXPECT_EQ(test, gem_obj->size, TEST_SIZE); > > KUNIT_EXPECT_NULL(test, gem_obj->filp); > > KUNIT_EXPECT_NOT_NULL(test, gem_obj->funcs); > > > > /* drm_gem_shmem_free will free the struct sg_table itself */ > > kunit_remove_action(test, sg_free_table_wrapper, sgt); > > kunit_remove_action(test, kfree_wrapper, sgt); > > I agree that using actions makes error handling cleaner. However, I still > have some concerns about the additional complexity that actions introduce. > For instance, I feel these two lines make the testing harness more complex > without asserting any additional property of the component under test. If anything, the API makes it more difficult to deal with. It would actually be harder/messier to handle without an action. > In some sense, I wonder if it is worth worrying about memory leaks when > a test case fails. At that point, the system is already in an inconsistent > state due to a bug in the component under test, so it is unsafe to continue > anyway. I guess the larger issue is: once that code will be merged, we're going to have patches to convert to actions because they make it nicer and fix a couple of issues anyway. So, if it's still the state we're going to end up in, why not doing it right from the beginning? Maxime

1 year, 7 months

Re: [PATCH 8/9] dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP

by Yong Wu (吴勇)

On Wed, 2023-11-01 at 11:20 +0530, Jaskaran Singh wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On 10/20/2023 3:20 PM, Yong Wu (吴勇) wrote: > > On Thu, 2023-10-19 at 10:16 +0530, Vijayanand Jitta wrote: > >> > >> Instead of having a vendor specific binding for cma area, How > about > >> retrieving > >> > > > https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunih… > >> ? > >> dma_heap_add_cma can just associate cma region and create a heap. > So, > >> we can reuse cma heap > >> code for allocation instead of replicating that code here. > >> > > > > Thanks for the reference. I guess we can't use it. There are two > > reasons: > > > > a) The secure heap driver is a pure software driver and we have no > > device for it, therefore we cannot call dma_heap_add_cma. > > > > Hi Yong, > > We're considering using struct cma as the function argument to > dma_heap_add_cma() rather than struct device. Would this help > resolve the problem of usage with dma_heap_add_cma()? Yes. If we use "struct cma", I guess it works. > > > b) The CMA area here is dynamic for SVP. Normally this CMA can be > used > > in the kernel. In the SVP case we use cma_alloc to get it and pass > the > > entire CMA physical start address and size into TEE to protect the > CMA > > region. The original CMA heap cannot help with the TEE part. > > > > Referring the conversation at > https://lore.kernel.org/lkml/7a2995de23c24ef22c071c6976c02b97e9b50126.camel… > ; > > since we're considering abstracting secure mem ops, would it make > sense > to use the default CMA heap ops (cma_heap_ops), allocate buffers from > it > and secure each allocated buffer? Then it looks you also need tee operation like tee_client_open_session and tee_client_invoke_func, right? It seems we also need change a bit for "cma_heap_allocate" to allow cma support operations from secure heap. I will send a v2 to move the discussion forward. The v2 is based on our case, It won't include the cma part. > > Thanks, > Jaskaran. > > > Thanks. > > > >> Thanks, > >> Vijay > >> > >> > >> >

1 year, 7 months

[PATCH 0/9] dma-buf: heaps: Add MediaTek secure heap

by Yong Wu

This patchset consists of two parts, the first is from John and TJ. It adds some heap interfaces, then our kernel users could allocate buffer from special heap. The second part is adding MTK secure heap for SVP (Secure Video Path). A total of two heaps are added, one is mtk_svp and the other is mtk_svp_cma. The mtk_svp buffer is reserved for the secure world after bootup and it is used for ES/working buffer, while the mtk_svp_cma buffer is dynamically reserved for the secure world and will be get ready when we start playing secure videos, this heap is used for the frame buffer. Once the security video playing is complete, the CMA will be released. For easier viewing, I've split the new heap file into several patches. The consumers of new heap and new interfaces are our codec and drm which will send upstream soon, probably this week. Base on v6.6-rc1. John Stultz (2): dma-heap: Add proper kref handling on dma-buf heaps dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps T.J. Mercier (1): dma-buf: heaps: Deduplicate docs and adopt common format Yong Wu (6): dma-buf: heaps: Initialise MediaTek secure heap dma-buf: heaps: mtk_sec_heap: Initialise tee session dma-buf: heaps: mtk_sec_heap: Add tee service call for buffer allocating/freeing dma-buf: heaps: mtk_sec_heap: Add dma_ops dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP dma_buf: heaps: mtk_sec_heap: Add a new CMA heap .../mediatek,secure_cma_chunkmem.yaml | 42 ++ drivers/dma-buf/dma-heap.c | 127 +++-- drivers/dma-buf/heaps/Kconfig | 8 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/mtk_secure_heap.c | 458 ++++++++++++++++++ include/linux/dma-heap.h | 42 +- 6 files changed, 630 insertions(+), 48 deletions(-) create mode 100644 Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml create mode 100644 drivers/dma-buf/heaps/mtk_secure_heap.c -- 2.18.0

1 year, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig