Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

15 participants
3030 discussions

[PATCH linux-next] drm/ttm: remove duplicate included header files

by cgel.zte＠gmail.com

From: Xu Panda <xu.panda(a)zte.com.cn> drm/drm_drv.h is included more than once. Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Xu Panda <xu.panda(a)zte.com.cn> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index b1c455329023..c659d4535ee0 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -43,7 +43,6 @@ #include <linux/sizes.h> #include <linux/module.h> -#include <drm/drm_drv.h> #include <drm/ttm/ttm_bo_api.h> #include <drm/ttm/ttm_bo_driver.h> #include <drm/ttm/ttm_placement.h> -- 2.15.2

3 years

[PATCH v3 0/6] dma-buf: Check status of enable-signaling bit on debug

by Arvind Yadav

Fence signaling must be enabled to make sure that the dma_fence_is_signaled() function ever returns true. Since drivers and implementations sometimes mess this up, this ensures correct behaviour when DEBUG_WW_MUTEX_SLOWPATH is used during debugging. This should make any implementation bugs resulting in not signaled fences much more obvious. Arvind Yadav (6): [PATCH v3 1/6] dma-buf: Remove the signaled bit status check [PATCH v3 2/6] dma-buf: set signaling bit for the stub fence [PATCH v3 3/6] dma-buf: Enable signaling on fence for selftests [PATCH v3 4/6] drm/amdgpu: Enable signaling on fence. [PATCH v3 5/6] drm/sched: Use parent fence instead of finished [PATCH v3 6/6] dma-buf: Check status of enable-signaling bit on debug drivers/dma-buf/dma-fence.c | 7 ++++--- drivers/dma-buf/st-dma-fence-chain.c | 4 ++++ drivers/dma-buf/st-dma-fence-unwrap.c | 22 ++++++++++++++++++++++ drivers/dma-buf/st-dma-fence.c | 16 ++++++++++++++++ drivers/dma-buf/st-dma-resv.c | 10 ++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 ++ drivers/gpu/drm/scheduler/sched_main.c | 4 ++-- include/linux/dma-fence.h | 5 +++++ 8 files changed, 65 insertions(+), 5 deletions(-) -- 2.25.1

3 years

[PATCH v2 0/4] dma-buf: To check enable signaling before signaled

by Arvind Yadav

TTM, GEM, DRM or the core DMA-buf framework are needs to enable software signaling before the fence is signaled. The core DMA-buf framework software can forget to call enable_signaling before the fence is signaled. It means framework code can forget to call dma_fence_enable_sw_signaling() before calling dma_fence_is_signaled(). To avoid this scenario on debug kernel, check the DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT bit status before checking the MA_FENCE_FLAG_SIGNALED_BIT bit status to confirm that software signaling is enabled. Arvind Yadav (4): [PATCH v2 1/4] drm/sched: Enable signaling for finished fence [PATCH v2 2/4] dma-buf: enable signaling for the stub fence on debug [PATCH v2 3/4] dma-buf: enable signaling for selftest fence on debug [PATCH v2 4/4] dma-buf: Check status of enable-signaling bit on debug drivers/dma-buf/dma-fence.c | 7 ++++ drivers/dma-buf/st-dma-fence-chain.c | 8 +++++ drivers/dma-buf/st-dma-fence-unwrap.c | 44 ++++++++++++++++++++++++++ drivers/dma-buf/st-dma-fence.c | 25 ++++++++++++++- drivers/dma-buf/st-dma-resv.c | 20 ++++++++++++ drivers/gpu/drm/scheduler/sched_main.c | 2 ++ include/linux/dma-fence.h | 5 +++ 7 files changed, 110 insertions(+), 1 deletion(-) -- 2.25.1

3 years

Re: [PATCH v2 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf

by jgg＠nvidia.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

3 years

[PATCH v2 0/3] dma-buf: map-info support

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> See 1/3 for motivation. Rob Clark (3): dma-buf: Add ioctl to query mmap coherency/cache info drm/prime: Wire up mmap_info support drm/msm/prime: Add mmap_info support drivers/dma-buf/dma-buf.c | 63 ++++++++++++++++++++++++++------ drivers/gpu/drm/drm_prime.c | 3 ++ drivers/gpu/drm/msm/msm_gem.c | 12 +++++++ include/drm/drm_gem.h | 11 ++++++ include/linux/dma-buf.h | 11 ++++++ include/uapi/linux/dma-buf.h | 68 +++++++++++++++++++++++++++++++++++ 6 files changed, 158 insertions(+), 10 deletions(-) -- 2.36.1

3 years

linaro-mm-sig@lists.linaro.org Received AWB Documents via WeTransfer

by Noreply＠lists.linaro.org

3 years

[PATCH v2 0/4] Allow MMIO regions to be exported through dma-buf

by Jason Gunthorpe

dma-buf has become a way to safely acquire a handle to non-struct page memory that can still have lifetime controlled by the exporter. Notably RDMA can now import dma-buf FDs and build them into MRs which allows for PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory from PCI device BARs. This series supports a use case for SPDK where a NVMe device will be owned by SPDK through VFIO but interacting with a RDMA device. The RDMA device may directly access the NVMe CMB or directly manipulate the NVMe device's doorbell using PCI P2P. However, as a general mechanism, it can support many other scenarios with VFIO. I imagine this dmabuf approach to be usable by iommufd as well for generic and safe P2P mappings. This series goes after the "Break up ioctl dispatch functions to one function per ioctl" series. This is on github: https://github.com/jgunthorpe/linux/commits/vfio_dma_buf v2: - Name the new file dma_buf.c - Restore orig_nents before freeing - Fix reversed logic around priv->revoked - Set priv->index - Rebased on v2 "Break up ioctl dispatch functions" v1: https://lore.kernel.org/r/0-v1-9e6e1739ed95+5fa-vfio_dma_buf_jgg@nvidia.com Cc: linux-rdma(a)vger.kernel.org Cc: Oded Gabbay <ogabbay(a)kernel.org> Cc: Christian König <christian.koenig(a)amd.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Leon Romanovsky <leon(a)kernel.org> Cc: Maor Gottlieb <maorg(a)nvidia.com> Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> Jason Gunthorpe (4): dma-buf: Add dma_buf_try_get() vfio: Add vfio_device_get() vfio_pci: Do not open code pci_try_reset_function() vfio/pci: Allow MMIO regions to be exported through dma-buf drivers/vfio/pci/Makefile | 1 + drivers/vfio/pci/dma_buf.c | 269 +++++++++++++++++++++++++++++ drivers/vfio/pci/vfio_pci_config.c | 22 ++- drivers/vfio/pci/vfio_pci_core.c | 33 +++- drivers/vfio/pci/vfio_pci_priv.h | 24 +++ drivers/vfio/vfio_main.c | 3 +- include/linux/dma-buf.h | 13 ++ include/linux/vfio.h | 6 + include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 18 ++ 10 files changed, 368 insertions(+), 22 deletions(-) create mode 100644 drivers/vfio/pci/dma_buf.c base-commit: 285fef0ff7f1a97d8acd380971c061985d8dafb5 -- 2.37.2

3 years

[PATCH v3] drm/ast: add dmabuf/prime buffer sharing support

by oushixiong

This patch adds ast specific codes for DRM prime feature, this is to allow for offloading of rending in one direction and outputs in other. This patch is designed to solve the problem that the AST is not displayed when the server plug in a discrete graphics card at the same time. We call the dirty callback function to copy the rendering results of the discrete graphics card to the ast side by dma-buf. v1->v2: - Fix the comment. v2->v3: - we remove the gem_prime_import_sg_table callback and use the gem_prime_import callback, because it just map and access the buffer with the CPU. and do not to pin the buffer. Signed-off-by: oushixiong <oushixiong(a)kylinos.cn> Acked-by: Christian K��nig <christian.koenig(a)amd.com> --- drivers/gpu/drm/ast/ast_drv.c | 27 +++++++ drivers/gpu/drm/ast/ast_mode.c | 125 ++++++++++++++++++++++++++++++++- 2 files changed, 151 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c index 7465c4f0156a..fd3c4bad2eb4 100644 --- a/drivers/gpu/drm/ast/ast_drv.c +++ b/drivers/gpu/drm/ast/ast_drv.c @@ -28,6 +28,7 @@ #include <linux/module.h> #include <linux/pci.h> +#include <linux/dma-buf.h> #include <drm/drm_aperture.h> #include <drm/drm_atomic_helper.h> @@ -50,6 +51,29 @@ module_param_named(modeset, ast_modeset, int, 0400); DEFINE_DRM_GEM_FOPS(ast_fops); +static struct drm_gem_object *ast_gem_prime_import(struct drm_device *dev, + struct dma_buf *dma_buf) +{ + struct drm_gem_vram_object *gbo; + + gbo = drm_gem_vram_of_gem(dma_buf->priv); + if (gbo->bo.base.dev == dev) { + /* + * Importing dmabuf exported from out own gem increases + * refcount on gem itself instead of f_count of dmabuf. + */ + drm_gem_object_get(&gbo->bo.base); + return &gbo->bo.base; + } + + gbo = drm_gem_vram_create(dev, dma_buf->size, 0); + if (IS_ERR(gbo)) + return NULL; + + get_dma_buf(dma_buf); + return &gbo->bo.base; +} + static const struct drm_driver ast_driver = { .driver_features = DRIVER_ATOMIC | DRIVER_GEM | @@ -63,6 +87,9 @@ static const struct drm_driver ast_driver = { .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, + .prime_fd_to_handle = drm_gem_prime_fd_to_handle, + .gem_prime_import = ast_gem_prime_import, + DRM_GEM_VRAM_DRIVER }; diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 45b56b39ad47..65a4342c5622 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -48,6 +48,8 @@ #include "ast_drv.h" #include "ast_tables.h" +MODULE_IMPORT_NS(DMA_BUF); + static inline void ast_load_palette_index(struct ast_private *ast, u8 index, u8 red, u8 green, u8 blue) @@ -1535,8 +1537,129 @@ static const struct drm_mode_config_helper_funcs ast_mode_config_helper_funcs = .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm, }; +static int ast_handle_damage(struct drm_framebuffer *fb, int x, int y, + int width, int height) +{ + struct drm_gem_vram_object *dst_bo = NULL; + void *dst = NULL; + int ret = 0, i; + unsigned long offset = 0; + bool unmap = false; + unsigned int bytesPerPixel; + struct iosys_map map; + struct iosys_map dmabuf_map; + + bytesPerPixel = fb->format->cpp[0]; + + if (!fb->obj[0]->dma_buf) + return -EINVAL; + + if (!fb->obj[0]->dma_buf->vmap_ptr.vaddr) { + ret = dma_buf_vmap(fb->obj[0]->dma_buf, &dmabuf_map); + if (ret) + return ret; + } else + dmabuf_map.vaddr = fb->obj[0]->dma_buf->vmap_ptr.vaddr; + + dst_bo = drm_gem_vram_of_gem(fb->obj[0]); + + ret = drm_gem_vram_pin(dst_bo, 0); + if (ret) { + DRM_ERROR("ast_bo_pin failed\n"); + return ret; + } + + if (!dst_bo->map.vaddr) { + ret = drm_gem_vram_vmap(dst_bo, &map); + if (ret) { + drm_gem_vram_unpin(dst_bo); + DRM_ERROR("failed to vmap fbcon\n"); + return ret; + } + unmap = true; + } + dst = dst_bo->map.vaddr; + + for (i = y; i < y + height; i++) { + offset = i * fb->pitches[0] + (x * bytesPerPixel); + memcpy_toio(dst + offset, dmabuf_map.vaddr + offset, + width * bytesPerPixel); + } + + if (unmap) + drm_gem_vram_vunmap(dst_bo, &map); + + drm_gem_vram_unpin(dst_bo); + + return 0; +} + + +static int ast_user_framebuffer_dirty(struct drm_framebuffer *fb, + struct drm_file *file, + unsigned int flags, + unsigned int color, + struct drm_clip_rect *clips, + unsigned int num_clips) +{ + int i, ret = 0; + + drm_modeset_lock_all(fb->dev); + if (fb->obj[0]->dma_buf) { + ret = dma_buf_begin_cpu_access(fb->obj[0]->dma_buf, + DMA_FROM_DEVICE); + if (ret) + goto unlock; + } + + for (i = 0; i < num_clips; i++) { + ret = ast_handle_damage(fb, clips[i].x1, clips[i].y1, + clips[i].x2 - clips[i].x1, clips[i].y2 - clips[i].y1); + if (ret) + break; + } + + if (fb->obj[0]->dma_buf) { + dma_buf_end_cpu_access(fb->obj[0]->dma_buf, + DMA_FROM_DEVICE); + } + +unlock: + drm_modeset_unlock_all(fb->dev); + + return ret; +} + +static void ast_user_framebuffer_destroy(struct drm_framebuffer *fb) +{ + struct iosys_map dmabuf_map; + + if (fb->obj[0]->dma_buf) { + dmabuf_map.is_iomem = fb->obj[0]->dma_buf->vmap_ptr.is_iomem; + dmabuf_map.vaddr = fb->obj[0]->dma_buf->vmap_ptr.vaddr; + if (dmabuf_map.vaddr) + dma_buf_vunmap(fb->obj[0]->dma_buf, &dmabuf_map); + } + + drm_gem_fb_destroy(fb); +} + +static const struct drm_framebuffer_funcs ast_gem_fb_funcs_dirtyfb = { + .destroy = ast_user_framebuffer_destroy, + .create_handle = drm_gem_fb_create_handle, + .dirty = ast_user_framebuffer_dirty, +}; + +static struct drm_framebuffer * +ast_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file, + const struct drm_mode_fb_cmd2 *mode_cmd) +{ + return drm_gem_fb_create_with_funcs(dev, file, mode_cmd, + &ast_gem_fb_funcs_dirtyfb); +} + static const struct drm_mode_config_funcs ast_mode_config_funcs = { - .fb_create = drm_gem_fb_create, + .fb_create = ast_gem_fb_create_with_dirty, .mode_valid = drm_vram_helper_mode_valid, .atomic_check = drm_atomic_helper_check, .atomic_commit = drm_atomic_helper_commit, -- 2.17.1 Content-type: Text/plain No virus found Checked by Hillstone Network AntiVirus

3 years

[PATCH v2 0/3] dma-buf: map-info support

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> See 1/3 for motivation. Rob Clark (3): dma-buf: Add ioctl to query mmap info drm/prime: Wire up mmap_info support drm/msm/prime: Add mmap_info support drivers/dma-buf/dma-buf.c | 26 ++++++++++++++++++++++++++ drivers/gpu/drm/drm_prime.c | 12 ++++++++++++ drivers/gpu/drm/msm/msm_drv.c | 1 + drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_gem_prime.c | 11 +++++++++++ include/drm/drm_drv.h | 7 +++++++ include/linux/dma-buf.h | 7 +++++++ include/uapi/linux/dma-buf.h | 28 ++++++++++++++++++++++++++++ 8 files changed, 93 insertions(+) -- 2.36.1

3 years

Re: [syzbot] KASAN: use-after-free Read in task_work_run (2)

by Dmitry Vyukov

On Tue, 6 Sept 2022 at 09:36, syzbot <syzbot+9228d6098455bb209ec8(a)syzkaller.appspotmail.com> wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit: c5e4d5e99162 Merge tag 'fscache-fixes-20220831' of git://g.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=142e0e1b080000 > kernel config: https://syzkaller.appspot.com/x/.config?x=9c5c41fc03fda66f > dashboard link: https://syzkaller.appspot.com/bug?extid=9228d6098455bb209ec8 > compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+9228d6098455bb209ec8(a)syzkaller.appspotmail.com Looks like the issue is in dma-buf.c +dma-buf.c maintainers > ================================================================== > BUG: KASAN: use-after-free in task_work_run+0x126/0x1c0 kernel/task_work.c:176 > Read of size 8 at addr ffff88801d1fe500 by task syz-executor.2/18582 > > CPU: 0 PID: 18582 Comm: syz-executor.2 Not tainted 6.0.0-rc3-syzkaller-00031-gc5e4d5e99162 #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 > Call Trace: > <TASK> > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 > print_address_description+0x65/0x4b0 mm/kasan/report.c:317 > print_report+0x108/0x220 mm/kasan/report.c:433 > kasan_report+0xfb/0x130 mm/kasan/report.c:495 > task_work_run+0x126/0x1c0 kernel/task_work.c:176 > resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] > exit_to_user_mode_loop+0x134/0x160 kernel/entry/common.c:169 > exit_to_user_mode_prepare+0xad/0x110 kernel/entry/common.c:201 > __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] > syscall_exit_to_user_mode+0x2e/0x60 kernel/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > RIP: 0033:0x7f287f289279 > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 b8 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007f28804cd168 EFLAGS: 00000246 ORIG_RAX: 0000000000000119 > RAX: 0000000000000001 RBX: 00007f287f39bf80 RCX: 00007f287f289279 > RDX: 0000000000000001 RSI: 0000000020000000 RDI: 0000000000000003 > RBP: 00007f287f2e32e9 R08: 0000000000000000 R09: 0000000000000000 > R10: 00000000000006ff R11: 0000000000000246 R12: 0000000000000000 > R13: 00007ffd34f4ba0f R14: 00007f28804cd300 R15: 0000000000022000 > </TASK> > > Allocated by task 18586: > kasan_save_stack mm/kasan/common.c:38 [inline] > kasan_set_track mm/kasan/common.c:45 [inline] > set_alloc_info mm/kasan/common.c:437 [inline] > __kasan_slab_alloc+0xb2/0xe0 mm/kasan/common.c:470 > kasan_slab_alloc include/linux/kasan.h:224 [inline] > slab_post_alloc_hook mm/slab.h:727 [inline] > slab_alloc_node mm/slub.c:3243 [inline] > slab_alloc mm/slub.c:3251 [inline] > __kmem_cache_alloc_lru mm/slub.c:3258 [inline] > kmem_cache_alloc+0x1a6/0x310 mm/slub.c:3268 > kmem_cache_zalloc include/linux/slab.h:723 [inline] > __alloc_file+0x26/0x230 fs/file_table.c:138 > alloc_empty_file+0xa9/0x1b0 fs/file_table.c:187 > alloc_file+0x58/0x5e0 fs/file_table.c:229 > alloc_file_pseudo+0x260/0x300 fs/file_table.c:272 > dma_buf_getfile drivers/dma-buf/dma-buf.c:534 [inline] > dma_buf_export+0x634/0x920 drivers/dma-buf/dma-buf.c:652 > drm_gem_dmabuf_export drivers/gpu/drm/drm_prime.c:253 [inline] > drm_gem_prime_export+0x255/0x400 drivers/gpu/drm/drm_prime.c:895 > export_and_register_object drivers/gpu/drm/drm_prime.c:397 [inline] > drm_gem_prime_handle_to_fd+0x3e6/0x530 drivers/gpu/drm/drm_prime.c:465 > drm_ioctl_kernel+0x33e/0x4f0 drivers/gpu/drm/drm_ioctl.c:782 > drm_ioctl+0x626/0xa10 drivers/gpu/drm/drm_ioctl.c:885 > vfs_ioctl fs/ioctl.c:51 [inline] > __do_sys_ioctl fs/ioctl.c:870 [inline] > __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > Freed by task 18595: > kasan_save_stack mm/kasan/common.c:38 [inline] > kasan_set_track+0x4c/0x70 mm/kasan/common.c:45 > kasan_set_free_info+0x1f/0x40 mm/kasan/generic.c:370 > ____kasan_slab_free+0xd8/0x120 mm/kasan/common.c:367 > kasan_slab_free include/linux/kasan.h:200 [inline] > slab_free_hook mm/slub.c:1754 [inline] > slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1780 > slab_free mm/slub.c:3534 [inline] > kmem_cache_free+0x95/0x1d0 mm/slub.c:3551 > rcu_do_batch kernel/rcu/tree.c:2245 [inline] > rcu_core+0xa61/0x1710 kernel/rcu/tree.c:2505 > __do_softirq+0x382/0x793 kernel/softirq.c:571 > > Last potentially related work creation: > kasan_save_stack+0x3b/0x60 mm/kasan/common.c:38 > __kasan_record_aux_stack+0xaf/0xc0 mm/kasan/generic.c:348 > call_rcu+0x163/0x9c0 kernel/rcu/tree.c:2793 > task_work_run+0x146/0x1c0 kernel/task_work.c:177 > resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] > exit_to_user_mode_loop+0x134/0x160 kernel/entry/common.c:169 > exit_to_user_mode_prepare+0xad/0x110 kernel/entry/common.c:201 > __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] > syscall_exit_to_user_mode+0x2e/0x60 kernel/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > Second to last potentially related work creation: > kasan_save_stack+0x3b/0x60 mm/kasan/common.c:38 > __kasan_record_aux_stack+0xaf/0xc0 mm/kasan/generic.c:348 > task_work_add+0x2f/0x200 kernel/task_work.c:48 > fput+0xdc/0x1a0 fs/file_table.c:381 > dma_buf_poll_cb drivers/dma-buf/dma-buf.c:213 [inline] > dma_buf_poll+0x53a/0x680 drivers/dma-buf/dma-buf.c:295 > vfs_poll include/linux/poll.h:88 [inline] > ep_item_poll fs/eventpoll.c:853 [inline] > ep_send_events fs/eventpoll.c:1692 [inline] > ep_poll+0xb27/0x1e60 fs/eventpoll.c:1821 > do_epoll_wait+0x1a2/0x210 fs/eventpoll.c:2256 > do_epoll_pwait fs/eventpoll.c:2290 [inline] > __do_sys_epoll_pwait fs/eventpoll.c:2303 [inline] > __se_sys_epoll_pwait+0x28e/0x480 fs/eventpoll.c:2297 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > The buggy address belongs to the object at ffff88801d1fe500 > which belongs to the cache filp of size 456 > The buggy address is located 0 bytes inside of > 456-byte region [ffff88801d1fe500, ffff88801d1fe6c8) > > The buggy address belongs to the physical page: > page:ffffea0000747f80 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1d1fe > head:ffffea0000747f80 order:1 compound_mapcount:0 compound_pincount:0 > memcg:ffff888072449c01 > flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) > raw: 00fff00000010200 ffffea00005ddf80 dead000000000002 ffff888140007a00 > raw: 0000000000000000 00000000000c000c 00000001ffffffff ffff888072449c01 > page dumped because: kasan: bad access detected > page_owner tracks the page as allocated > page last allocated via order 1, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 3111, tgid 3111 (v4l_id), ts 20130623440, free_ts 19733718234 > prep_new_page mm/page_alloc.c:2532 [inline] > get_page_from_freelist+0x72b/0x7a0 mm/page_alloc.c:4283 > __alloc_pages+0x259/0x560 mm/page_alloc.c:5515 > alloc_slab_page+0x70/0xf0 mm/slub.c:1824 > allocate_slab+0x5e/0x520 mm/slub.c:1969 > new_slab mm/slub.c:2029 [inline] > ___slab_alloc+0x42e/0xce0 mm/slub.c:3031 > __slab_alloc mm/slub.c:3118 [inline] > slab_alloc_node mm/slub.c:3209 [inline] > slab_alloc mm/slub.c:3251 [inline] > __kmem_cache_alloc_lru mm/slub.c:3258 [inline] > kmem_cache_alloc+0x25d/0x310 mm/slub.c:3268 > kmem_cache_zalloc include/linux/slab.h:723 [inline] > __alloc_file+0x26/0x230 fs/file_table.c:138 > alloc_empty_file+0xa9/0x1b0 fs/file_table.c:187 > path_openat+0xf1/0x2e00 fs/namei.c:3677 > do_filp_open+0x275/0x500 fs/namei.c:3718 > do_sys_openat2+0x13b/0x500 fs/open.c:1311 > do_sys_open fs/open.c:1327 [inline] > __do_sys_openat fs/open.c:1343 [inline] > __se_sys_openat fs/open.c:1338 [inline] > __x64_sys_openat+0x243/0x290 fs/open.c:1338 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > page last free stack trace: > reset_page_owner include/linux/page_owner.h:24 [inline] > free_pages_prepare mm/page_alloc.c:1449 [inline] > free_pcp_prepare+0x812/0x900 mm/page_alloc.c:1499 > free_unref_page_prepare mm/page_alloc.c:3380 [inline] > free_unref_page+0x7d/0x630 mm/page_alloc.c:3476 > qlist_free_all+0x2b/0x70 mm/kasan/quarantine.c:187 > kasan_quarantine_reduce+0x169/0x180 mm/kasan/quarantine.c:294 > __kasan_slab_alloc+0x2f/0xe0 mm/kasan/common.c:447 > kasan_slab_alloc include/linux/kasan.h:224 [inline] > slab_post_alloc_hook mm/slab.h:727 [inline] > slab_alloc_node mm/slub.c:3243 [inline] > slab_alloc mm/slub.c:3251 [inline] > __kmem_cache_alloc_lru mm/slub.c:3258 [inline] > kmem_cache_alloc+0x1a6/0x310 mm/slub.c:3268 > vm_area_alloc+0x20/0xe0 kernel/fork.c:459 > mmap_region+0xb4a/0x16f0 mm/mmap.c:1732 > do_mmap+0x7a7/0xdf0 mm/mmap.c:1540 > vm_mmap_pgoff+0x1e5/0x2f0 mm/util.c:552 > ksys_mmap_pgoff+0x48c/0x6d0 mm/mmap.c:1586 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > Memory state around the buggy address: > ffff88801d1fe400: fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc > ffff88801d1fe480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > >ffff88801d1fe500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > ffff88801d1fe580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff88801d1fe600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ================================================================== > > > --- > 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. > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe(a)googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/000000000000fad77705e7fd40….

3 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig