Re: [PATCH] drm/ttm: Use __GFP_NOWARN for huge pages in ttm_pool_alloc_page
On Thu, 28 Jan 2021, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Without __GFP_NOWARN, attempts at allocating huge pages can trigger
> dmesg splats like below (which are essentially noise, since TTM falls
> back to normal pages if it can't get a huge one).
>
> [ 9556.710241] clinfo: page allocation failure: order:9,
> mode:0x194dc2(GFP_HIGHUSER|__GFP_RETRY_MAYFAIL|__GFP_NORETRY|__GFP_ZERO|__GFP_NOMEMALLOC),
> nodemask=(null),cpuset=user.slice,mems_allowed=0
> [ 9556.710259] CPU: 1 PID: 470821 Comm: clinfo Tainted: GE
> 5.10.10+ #4
> [ 9556.710264] Hardware name: Micro-Star International Co., Ltd. MS-7A34/B350
> TOMAHAWK (MS-7A34), BIOS 1.OR 11/29/2019
> [ 9556.710268] Call Trace:
> [ 9556.710281] dump_stack+0x6b/0x83
> [ 9556.710288] warn_alloc.cold+0x7b/0xdf
> [ 9556.710297] ? __alloc_pages_direct_compact+0x137/0x150
> [ 9556.710303] __alloc_pages_slowpath.constprop.0+0xc1b/0xc50
> [ 9556.710312] __alloc_pages_nodemask+0x2ec/0x320
> [ 9556.710325] ttm_pool_alloc+0x2e4/0x5e0 [ttm]
> [ 9556.710332] ? kvmalloc_node+0x46/0x80
> [ 9556.710341] ttm_tt_populate+0x37/0xe0 [ttm]
> [ 9556.710350] ttm_bo_handle_move_mem+0x142/0x180 [ttm]
> [ 9556.710359] ttm_bo_validate+0x11d/0x190 [ttm]
> [ 9556.710391] ? drm_vma_offset_add+0x2f/0x60 [drm]
> [ 9556.710399] ttm_bo_init_reserved+0x2a7/0x320 [ttm]
> [ 9556.710529] amdgpu_bo_do_create+0x1b8/0x500 [amdgpu]
> [ 9556.710657] ? amdgpu_bo_subtract_pin_size+0x60/0x60 [amdgpu]
> [ 9556.710663] ? get_page_from_freelist+0x11f9/0x1450
> [ 9556.710789] amdgpu_bo_create+0x40/0x270 [amdgpu]
> [ 9556.710797] ? _raw_spin_unlock+0x16/0x30
> [ 9556.710927] amdgpu_gem_create_ioctl+0x123/0x310 [amdgpu]
> [ 9556.711062] ? amdgpu_gem_force_release+0x150/0x150 [amdgpu]
> [ 9556.711098] drm_ioctl_kernel+0xaa/0xf0 [drm]
> [ 9556.711133] drm_ioctl+0x20f/0x3a0 [drm]
> [ 9556.711267] ? amdgpu_gem_force_release+0x150/0x150 [amdgpu]
> [ 9556.711276] ? preempt_count_sub+0x9b/0xd0
> [ 9556.711404] amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
> [ 9556.711411] __x64_sys_ioctl+0x83/0xb0
> [ 9556.711417] do_syscall_64+0x33/0x80
> [ 9556.711421] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Fixes: bf9eee249ac2 ("drm/ttm: stop using GFP_TRANSHUGE_LIGHT")
> Signed-off-by: Michel Dänzer
Acked-by: David Rientjes
Mikhail Gavrilov reported the same issue.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: INFO: trying to register non-static key in __flush_work
On Sat, 29 Dec 2018, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:5694cecdb092 Merge tag 'arm64-upstream' of git://git.kerne.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=124eebc740 > kernel config: https://syzkaller.appspot.com/x/.config?x=91a256823ef17263 > dashboard link: https://syzkaller.appspot.com/bug?extid=12f1b031b6da017e34f8 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1174a1dd40 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1336e38b40 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+12f1b031b6da017e3...@syzkaller.appspotmail.com > > INFO: trying to register non-static key. > the code is fine but needs lockdep annotation. > turning off the locking correctness validator. > CPU: 0 PID: 8039 Comm: syz-executor964 Not tainted 4.20.0+ #389 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google > 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1d3/0x2c6 lib/dump_stack.c:113 > assign_lock_key kernel/locking/lockdep.c:727 [inline] > register_lock_class+0x21c5/0x29d0 kernel/locking/lockdep.c:753 > __lock_acquire+0x184/0x4c20 kernel/locking/lockdep.c:3227 > lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 > __flush_work+0x752/0x9b0 kernel/workqueue.c:2912 > flush_work+0x17/0x20 kernel/workqueue.c:2938 > vkms_atomic_crtc_destroy_state+0x2b/0x40 drivers/gpu/drm/vkms/vkms_crtc.c:139 > drm_atomic_state_default_clear+0x37c/0xda0 drivers/gpu/drm/drm_atomic.c:171 > drm_atomic_state_clear+0x9f/0xd0 drivers/gpu/drm/drm_atomic.c:240 > __drm_atomic_state_free+0x3a/0xf0 drivers/gpu/drm/drm_atomic.c:256 > kref_put include/linux/kref.h:70 [inline] > drm_atomic_state_put include/drm/drm_atomic.h:385 [inline] > drm_atomic_helper_set_config+0xe6/0x160 > drivers/gpu/drm/drm_atomic_helper.c:2947 > drm_mode_setcrtc+0x767/0x1890 drivers/gpu/drm/drm_crtc.c:748 > drm_ioctl_kernel+0x278/0x330 drivers/gpu/drm/drm_ioctl.c:758 > drm_ioctl+0x58f/0xb90 drivers/gpu/drm/drm_ioctl.c:858 > vfs_ioctl fs/ioctl.c:46 [inline] > file_ioctl fs/ioctl.c:509 [inline] > do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 > __do_sys_ioctl fs/ioctl.c:720 [inline] > __se_sys_ioctl fs/ioctl.c:718 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x443e59 > Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 0f > 83 7b d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7fff2bc037c8 EFLAGS: 0213 ORIG_RAX: 0010 > RAX: ffda RBX: 004002e0 RCX: 00443e59 > RDX: 2100 RSI: c06864a2 RDI: 0003 > RBP: 006ce018 R08: R09: 004002e0 > R10: 000f R11: 0213 R12: 00401b60 > R13: 00401bf0 R14: R15: 0 > This is reproducible up to at least commit e60b5f79bd7529e76b13cf1e85823abbd0e33634 Merge: 6089a91fc02e 8f5b27347e88 Author: Linus Torvalds Date: Sat Feb 23 11:13:50 2019 -0800 Merge tag 'powerpc-5.0-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux and my theory is that it's due to this: commit dfb9f5cabfe31b8e936b725b5de8f787f7c18b0f Author: Haneen Mohammed Date: Tue Jul 24 19:31:05 2018 +0300 drm/vkms: subclass CRTC state in 4.20-rc1. We aren't doing INIT_WORK() for the workqueue that is being flushed. Don't we need to do INIT_WORK() in vkms_atomic_crtc_reset() too? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: INFO: trying to register non-static key in __flush_work
On Mon, 25 Feb 2019, Daniel Vetter wrote: > On Sun, Feb 24, 2019 at 12:40:19PM -0800, David Rientjes wrote: > > On Sat, 29 Dec 2018, syzbot wrote: > > > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit:5694cecdb092 Merge tag 'arm64-upstream' of > > > git://git.kerne.. > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=124eebc740 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=91a256823ef17263 > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=12f1b031b6da017e34f8 > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1174a1dd40 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1336e38b40 > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+12f1b031b6da017e3...@syzkaller.appspotmail.com > > > > > > INFO: trying to register non-static key. > > > the code is fine but needs lockdep annotation. > > > turning off the locking correctness validator. > > > CPU: 0 PID: 8039 Comm: syz-executor964 Not tainted 4.20.0+ #389 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > > Google > > > 01/01/2011 > > > Call Trace: > > > __dump_stack lib/dump_stack.c:77 [inline] > > > dump_stack+0x1d3/0x2c6 lib/dump_stack.c:113 > > > assign_lock_key kernel/locking/lockdep.c:727 [inline] > > > register_lock_class+0x21c5/0x29d0 kernel/locking/lockdep.c:753 > > > __lock_acquire+0x184/0x4c20 kernel/locking/lockdep.c:3227 > > > lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 > > > __flush_work+0x752/0x9b0 kernel/workqueue.c:2912 > > > flush_work+0x17/0x20 kernel/workqueue.c:2938 > > > vkms_atomic_crtc_destroy_state+0x2b/0x40 > > > drivers/gpu/drm/vkms/vkms_crtc.c:139 > > > drm_atomic_state_default_clear+0x37c/0xda0 > > > drivers/gpu/drm/drm_atomic.c:171 > > > drm_atomic_state_clear+0x9f/0xd0 drivers/gpu/drm/drm_atomic.c:240 > > > __drm_atomic_state_free+0x3a/0xf0 drivers/gpu/drm/drm_atomic.c:256 > > > kref_put include/linux/kref.h:70 [inline] > > > drm_atomic_state_put include/drm/drm_atomic.h:385 [inline] > > > drm_atomic_helper_set_config+0xe6/0x160 > > > drivers/gpu/drm/drm_atomic_helper.c:2947 > > > drm_mode_setcrtc+0x767/0x1890 drivers/gpu/drm/drm_crtc.c:748 > > > drm_ioctl_kernel+0x278/0x330 drivers/gpu/drm/drm_ioctl.c:758 > > > drm_ioctl+0x58f/0xb90 drivers/gpu/drm/drm_ioctl.c:858 > > > vfs_ioctl fs/ioctl.c:46 [inline] > > > file_ioctl fs/ioctl.c:509 [inline] > > > do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 > > > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 > > > __do_sys_ioctl fs/ioctl.c:720 [inline] > > > __se_sys_ioctl fs/ioctl.c:718 [inline] > > > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 > > > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > RIP: 0033:0x443e59 > > > Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 > > > 0f > > > 83 7b d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > > > RSP: 002b:7fff2bc037c8 EFLAGS: 0213 ORIG_RAX: 0010 > > > RAX: ffda RBX: 004002e0 RCX: 00443e59 > > > RDX: 2100 RSI: c06864a2 RDI: 0003 > > > RBP: 006ce018 R08: R09: 004002e0 > > > R10: 000f R11: 0213 R12: 00401b60 > > > R13: 00401bf0 R14: R15: 0 > > > > > > > This is reproducible up to at least > > > > commit e60b5f79bd7529e76b13cf1e85823abbd0e33634 > > Merge: 6089a91fc02e 8f5b27347e88 > > Author: Linus Torvalds > > Date: Sat Feb 23 11:13:50 2019 -0800 > > > > Merge tag 'powerpc-5.0-6' of > > git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux > > > > and my theory is that it's due to this: > > > > commit dfb9f5cabfe31b8e936b725b5de8f787f7c18b0f > > Author: Haneen Mohammed > > Date: Tue Jul 24 19:31:05 2018 +0300 > > > > drm/vkms: subclass CRTC state > > > > in 4.20-rc1. We aren't doing INIT_WORK() for the workqueue that is being > > flushed. > > > > Don't we need to do INIT_WORK() in vkms_atomic_crtc_reset() too? > > Patch is in linux-next: > > commit b30b61ff6b1dc37f276cf56a8328b80086a3ffca > Author: Tetsuo Handa > Date: Sat Jan 19 01:43:43 2019 +0900 > > drm/vkms: Fix flush_work() without INIT_WORK() > Great, thanks Tetsuo! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/18] mm/gup: introduce pin_user_pages*() and FOLL_PIN
On Sun, 3 Nov 2019, John Hubbard wrote: > Introduce pin_user_pages*() variations of get_user_pages*() calls, > and also pin_longterm_pages*() variations. > > These variants all set FOLL_PIN, which is also introduced, and > thoroughly documented. > > The pin_longterm*() variants also set FOLL_LONGTERM, in addition > to FOLL_PIN: > > pin_user_pages() > pin_user_pages_remote() > pin_user_pages_fast() > > pin_longterm_pages() > pin_longterm_pages_remote() > pin_longterm_pages_fast() > > All pages that are pinned via the above calls, must be unpinned via > put_user_page(). > Hi John, I'm curious what consideration is given to what pageblock migrate types that FOLL_PIN and FOLL_LONGTERM pages originate from, assuming that longterm would want to originate from MIGRATE_UNMOVABLE pageblocks for the purposes of anti-fragmentation? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Tue, 24 Jul 2018, Michal Hocko wrote:
> oom_reap_task_mm should return false when __oom_reap_task_mm return
> false. This is what my patch did but it seems this changed by
> http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
> so that one should be fixed.
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 104ef4a01a55..88657e018714 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -565,7 +565,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
> struct mm_struct *mm)
> /* failed to reap part of the address space. Try again later */
> if (!__oom_reap_task_mm(mm)) {
> up_read(&mm->mmap_sem);
> - return true;
> + return false;
> }
>
> pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
> file-rss:%lukB, shmem-rss:%lukB\n",
>
>
> On top of that the proposed cleanup looks as follows:
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 88657e018714..4e185a282b3d 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -541,8 +541,16 @@ bool __oom_reap_task_mm(struct mm_struct *mm)
> return ret;
> }
>
> +/*
> + * Reaps the address space of the give task.
> + *
> + * Returns true on success and false if none or part of the address space
> + * has been reclaimed and the caller should retry later.
> + */
> static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
> {
> + bool ret = true;
> +
> if (!down_read_trylock(&mm->mmap_sem)) {
> trace_skip_task_reaping(tsk->pid);
> return false;
> @@ -555,28 +563,28 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
> struct mm_struct *mm)
>* down_write();up_write() cycle in exit_mmap().
>*/
> if (test_bit(MMF_OOM_SKIP, &mm->flags)) {
> - up_read(&mm->mmap_sem);
> trace_skip_task_reaping(tsk->pid);
> - return true;
> + goto out_unlock;
> }
>
> trace_start_task_reaping(tsk->pid);
>
> /* failed to reap part of the address space. Try again later */
> - if (!__oom_reap_task_mm(mm)) {
> - up_read(&mm->mmap_sem);
> - return false;
> - }
> + ret = __oom_reap_task_mm(mm);
> + if (!ret)
> + goto out_finish;
>
> pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
> file-rss:%lukB, shmem-rss:%lukB\n",
> task_pid_nr(tsk), tsk->comm,
> K(get_mm_counter(mm, MM_ANONPAGES)),
> K(get_mm_counter(mm, MM_FILEPAGES)),
> K(get_mm_counter(mm, MM_SHMEMPAGES)));
> +out_finish:
> + trace_finish_task_reaping(tsk->pid);
> +out_unlock:
> up_read(&mm->mmap_sem);
>
> - trace_finish_task_reaping(tsk->pid);
> - return true;
> + return ret;
> }
>
> #define MAX_OOM_REAP_RETRIES 10
I think we still want to trace when reaping was skipped to know that the
oom reaper will retry again later.
mm/oom_kill.c: clean up oom_reap_task_mm() fix
indicate reaping has been partially skipped so we can expect future skips
or another start before finish.
Signed-off-by: David Rientjes
---
mm/oom_kill.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -569,10 +569,12 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
struct mm_struct *mm)
trace_start_task_reaping(tsk->pid);
- /* failed to reap part of the address space. Try again later */
ret = __oom_reap_task_mm(mm);
- if (!ret)
+ if (!ret) {
+ /* Failed to reap part of the address space. Try again later */
+ trace_skip_task_reaping(tsk->pid);
goto out_finish;
+ }
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
task_pid_nr(tsk), tsk->comm,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: avoid switching to text console if there is no panic timeout
On Mon, 17 Oct 2011, Mandeep Singh Baines wrote: > From: Hugh Dickins > > Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if > we're going to reboot immediately, the user will not be able to see the > messages anyway, and messing with the video mode may display artifacts, > and certainly get into several layers of complexity (including mutexes and > memory allocations) which we shall be much safer to avoid. > > Signed-off-by: Hugh Dickins > [ Edited commit message and modified to short-circuit panic_timeout < 0 > instead of testing panic_timeout >= 0. -Mandeep ] > Signed-off-by: Mandeep Singh Baines > Cc: Dave Airlie > Cc: Andrew Morton > Cc: dri-devel@lists.freedesktop.org Acked-by: David Rientjes ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: avoid switching to text console if there is no panic timeout
On Mon, 17 Oct 2011, David Rientjes wrote: > On Mon, 17 Oct 2011, Mandeep Singh Baines wrote: > > > From: Hugh Dickins > > > > Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if > > we're going to reboot immediately, the user will not be able to see the > > messages anyway, and messing with the video mode may display artifacts, > > and certainly get into several layers of complexity (including mutexes and > > memory allocations) which we shall be much safer to avoid. > > > > Signed-off-by: Hugh Dickins > > [ Edited commit message and modified to short-circuit panic_timeout < 0 > > instead of testing panic_timeout >= 0. -Mandeep ] > > Signed-off-by: Mandeep Singh Baines > > Cc: Dave Airlie > > Cc: Andrew Morton > > Cc: dri-devel@lists.freedesktop.org > > Acked-by: David Rientjes > Dave, where do we stand on this? I haven't seen it hit Linus' tree and I don't see it in git://people.freedesktop.org/~airlied/linux. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.1.4] mm slub memory corruption in drm_vblank_cleanup
On Tue, 13 Dec 2011, batouzo wrote: > Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup. > > After some debugging it seems to be use after freed memory corruption > caused by radeon driver. That's not what's indicated here, this is the poison value being overwritten and detected on free. > With radeon + kms the bug happens around 1 in 3 boot ups, right after > the radeon is enabled (with slub debugging) or later with no debug (few > seconds later or on shutdown esp. in rmmod). > > When disabling radeon and KMS the bug was not seen; > > > Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in > drm_vblank_cleanup+0x78/0x90 [drm] > Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in > drm_vblank_cleanup+0x48/0x90 [drm] > > It is Amd Bulldozer computer, with Radeon card: > 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO > [Radeon HD 5450] > > Debian stable. Builded with make-kpkg using gcc 4.4.5 > >messages: http://pastebin.com/NXN5EPtG > config used: http://pastebin.com/AeVxEX7c > > Interesting part of the messages linked above is: > > > [ 94.401991] fb0: radeondrmfb frame buffer device > [ 94.401992] drm: registered panic notifier > [ 94.402033] [drm] Initialized radeon 2.11.0 20080528 for :01:00.0 > on minor 0 > [ 94.402921] > = > [ 94.402961] BUG kmalloc-16: Poison overwritten > [ 94.402982] > - > [ 94.402983] > [ 94.403025] INFO: 0x880137dbbc38-0x880137dbbc3b. First byte > 0x0 instead of 0x6b > [ 94.403066] INFO: Allocated in drm_vblank_init+0x139/0x260 [drm] > age=253 cpu=3 pid=535 > [ 94.403103] set_track+0x58/0x100 > [ 94.403119] alloc_debug_processing+0x160/0x170 > [ 94.403140] __slab_alloc+0x26d/0x440 > [ 94.403160] drm_vblank_init+0x139/0x260 [drm] > [ 94.403182] drm_debugfs_create_files+0xcb/0x1a0 [drm] > [ 94.403208] drm_vblank_init+0x139/0x260 [drm] > [ 94.403228] __kmalloc+0x100/0x180 > [ 94.403247] drm_vblank_init+0x139/0x260 [drm] > [ 94.403276] radeon_irq_kms_init+0x6d/0x160 [radeon] > [ 94.403303] evergreen_init+0x11c/0x2a0 [radeon] > [ 94.403337] radeon_device_init+0x3c9/0x470 [radeon] > [ 94.403367] radeon_driver_load_kms+0xad/0x160 [radeon] > [ 94.403394] drm_get_pci_dev+0x198/0x2c0 [drm] > [ 94.403416] local_pci_probe+0x55/0xd0 > [ 94.403433] pci_device_probe+0x10a/0x130 > [ 94.403453] driver_sysfs_add+0x72/0xa0 > [ 94.403474] INFO: Freed in drm_vblank_cleanup+0x78/0x90 [drm] age=235 > cpu=0 pid=535 > [ 94.403508] set_track+0x58/0x100 > [ 94.403524] free_debug_processing+0x1f3/0x240 > [ 94.403545] __slab_free+0x1a6/0x2b0 > [ 94.403562] native_read_tsc+0x2/0x20 > [ 94.403580] delay_tsc+0x42/0x80 > [ 94.403598] drm_vblank_cleanup+0x78/0x90 [drm] > [ 94.403625] radeon_irq_kms_fini+0xd/0x60 [radeon] > [ 94.403651] evergreen_init+0x289/0x2a0 [radeon] > [ 94.403677] radeon_device_init+0x3c9/0x470 [radeon] > [ 94.403704] radeon_driver_load_kms+0xad/0x160 [radeon] > [ 94.403731] drm_get_pci_dev+0x198/0x2c0 [drm] > [ 94.403751] local_pci_probe+0x55/0xd0 > [ 94.403772] pci_device_probe+0x10a/0x130 > [ 94.403791] driver_sysfs_add+0x72/0xa0 > [ 94.404806] driver_probe_device+0x8e/0x1b0 > [ 94.405782] __driver_attach+0x93/0xa0 > [ 94.406031] INFO: Slab 0xea0004df6e80 objects=23 used=23 fp=0x >(null) flags=0x2004080 > [ 94.406031] INFO: Object 0x880137dbbc38 @offset=7224 > fp=0x880137dbb830 > [ 94.406031] > [ 94.406031] Bytes b4 0x880137dbbc28: 06 0e ff ff 00 00 00 00 5a > 5a 5a 5a 5a 5a 5a 5a ..?? > [ 94.406031] Object 0x880137dbbc38: 00 00 00 00 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b a5 kkk??? > [ 94.406031] Redzone 0x880137dbbc48: bb bb bb bb bb bb bb bb > > [ 94.406031] Padding 0x880137dbbd88: 5a 5a 5a 5a 5a 5a 5a 5a > > [ 94.406031] Pid: 466, comm: udevd Not tainted 3.1.4-norm007+dbg #1 > [ 94.406031] Call Trace: > [ 94.406031] [] ? check_bytes_and_report+0x110/0x150 > [ 94.406031] [] ? check_object+0x1fe/0x250 > [ 94.406031] [] ? shmem_symlink+0xd4/0x220 > [ 94.406031] [] ? shmem_symlink+0xd4/0x220 > [ 94.406031] [] ? alloc_debug_processing+0xee/0x170 > [ 94.406031] [] ? __slab_alloc+0x26d/0x440 > [ 94.406031] [] ? shmem_symlink+0xd4/0x220 > [ 94.406031] [] ? inode_init_always+0xfc/0x1b0 > [ 94.406031] [] ? alloc_inode+0x32/0x90 > [ 94.406031] [] ? shmem_symlink+0xd4/0x220 > [ 94.406031] [] ? __kmalloc_track_caller+0xf8/0x180 > [ 94.406031] [] ? kmemdup+0x27/0x60 > [ 94.406031] [] ? shmem_symlink+0xd4/0x220 > [ 94.406031] [] ? vfs_symlink+0x87/0xa0 > [ 94.406031] [] ? sys_symlinkat+0xdc/0xf0 > [ 94.406031] [] ? system_call_fastpath+0x16/0x1b
Re: [PATCH 4/6] char: use vma_pages() to replace (vm_end - vm_start) >> PAGE_SHIFT
On Mon, 15 Apr 2013, Libin wrote:
> diff --git a/drivers/char/mspec.c b/drivers/char/mspec.c
> index e1f60f9..ed0703f 100644
> --- a/drivers/char/mspec.c
> +++ b/drivers/char/mspec.c
> @@ -168,7 +168,7 @@ mspec_close(struct vm_area_struct *vma)
> if (!atomic_dec_and_test(&vdata->refcnt))
> return;
>
> - last_index = (vdata->vm_end - vdata->vm_start) >> PAGE_SHIFT;
> + last_index = vma_pages(vdata);
> for (index = 0; index < last_index; index++) {
> if (vdata->maddr[index] == 0)
> continue;
vdata is of type struct vma_data * and vma_pages() takes a formal of type
struct vm_area_struct *, so these are incompatible. Hopefully you tested
the other changes and simply lack an ia64 cross compiler for this one,
because it will emit a warning.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] drivers, drm: fix qxl build error when debugfs is disabled
Fix build error when CONFIG_DEBUG_FS is disabled:
drivers/gpu/drm/qxl/qxl_debugfs.c: In function 'qxl_debugfs_init':
drivers/gpu/drm/qxl/qxl_debugfs.c:76:2: error: implicit declaration of function
'drm_debugfs_create_files'
drivers/gpu/drm/qxl/qxl_debugfs.c: In function 'qxl_debugfs_takedown':
drivers/gpu/drm/qxl/qxl_debugfs.c:84:2: error: implicit declaration of function
'drm_debugfs_remove_files'
Signed-off-by: David Rientjes
---
drivers/gpu/drm/qxl/qxl_debugfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c
b/drivers/gpu/drm/qxl/qxl_debugfs.c
--- a/drivers/gpu/drm/qxl/qxl_debugfs.c
+++ b/drivers/gpu/drm/qxl/qxl_debugfs.c
@@ -35,6 +35,7 @@
#include "qxl_object.h"
+#if defined(CONFIG_DEBUG_FS)
static int
qxl_debugfs_irq_received(struct seq_file *m, void *data)
{
@@ -69,20 +70,25 @@ static struct drm_info_list qxl_debugfs_list[] = {
{ "qxl_buffers", qxl_debugfs_buffers_info, 0, NULL },
};
#define QXL_DEBUGFS_ENTRIES ARRAY_SIZE(qxl_debugfs_list)
+#endif
int
qxl_debugfs_init(struct drm_minor *minor)
{
+#if defined(CONFIG_DEBUG_FS)
drm_debugfs_create_files(qxl_debugfs_list, QXL_DEBUGFS_ENTRIES,
minor->debugfs_root, minor);
+#endif
return 0;
}
void
qxl_debugfs_takedown(struct drm_minor *minor)
{
+#if defined(CONFIG_DEBUG_FS)
drm_debugfs_remove_files(qxl_debugfs_list, QXL_DEBUGFS_ENTRIES,
minor);
+#endif
}
int qxl_debugfs_add_files(struct qxl_device *qdev,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On Tue, 12 Apr 2011, Joerg Roedel wrote: > Bisecting actually gave a very weird result. It points to > > d2137d5af4259f50c19addb8246a186c9ffac325 > > which is a merge-commit in the x86 tree. Even more weird is that this > notebook is the only machine with these symptoms, all my other boxes are > fine. > During the bisect I tested commits from Yinghai which were good. It > seems like the problem appeared with the merge. > Alexandre Demers (cc'd) reports a boot failure bisected to the same merge on a 64-bit AMD tricore in https://bugzilla.kernel.org/show_bug.cgi?id=33012. We're awaiting earlyprintk= output from that kernel, if possible, and Yinghai asked for his .config and dmesg output from the last known working kernel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression in panic
On Mon, 20 Jun 2011, Mandeep Singh Baines wrote: > Hi Dave, > > I think this change is causing a regression I'm seeing in panic. > Before this change, I'd get a > reboot on panic (we've configured as such). > > With this change, my machine gets wedged if the machine is running in > X when the panic occurs. > > I traced the code flow to this: > > bust_spinlocks(0); > ->unblank_screen(); >->do_unblank_screen(0); > ->vc->vc_sw->con_blank(vc, 0, 0); >->fbcon_blank(vc, 0, 0); > ->update_screen(vc); >->redraw_screen(vc, 0); > ->vc->vc_sw->con_switch(vc); >->fbcon_switch(vc); > ->ops->update_start(info); >->bit_update_start(info); > ->fb_pan_display(info, &ops->var); > ->info->fbops->fb_pan_display(var, info); > ->drm_fb_helper_pan_display(var, info); > ->mutex_lock(&dev->mode_config.mutex); *this blocks* > > With this change, there is now a lot going on in the panic path. Stuff > that I'm not sure is safe when panicking. In addition to the > mutex_lock, there is also a del_timer_sync() > now happening in the context of panic(). > > I see this bug with a 2.6.38 kernel but did a quick scan of a newer > kernels and did not see anything that changed in this path so I > suspect its still there. > > Reverting this change fixes the regression. > Chris Fowler reports something similar when running 2.6.38 by inducing a kernel panic via the oom killer -- see http://marc.info/?l=linux-kernel&m=130805985022791. I've added him to the cc so he can participate in the thread and cherry-pick any fixes (last status update was that he was going to be trying 2.6.38.8). -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM-related kmalloc-32 memory leak in 2.6.35
On Mon, 27 Sep 2010, Andrew Morton wrote: > > Still present in 2.6.35. Appears to be DRM: > > > > 845 drm_vm_open_locked+0x72/0x109 age=43/37572/59269 pid=2089 > > cpus=0-1 > > > > That's after about a minute of uptime. Grows to 100k in about a day. > > > > dmesg bits: > > [0.834653] [drm] Initialized drm 1.1.0 20060810 > > [0.834986] pci :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > > [0.834995] pci :00:02.0: setting latency timer to 64 > > [1.002572] mtrr: type mismatch for e000,1000 old: write-back > > new: write-combining > > [1.002580] [drm] MTRR allocation failed. Graphics performance may > > suffer. > > [1.019880] acpi device:03: registered as cooling_device2 > > [1.021520] input: Video Bus as > > /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 > > [1.021543] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: > > no) > > [1.021855] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > > minor 0 > > > > This is with: > > > > 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 > > Integrated Graphics Controller (rev 03) > > 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 > > Integrated Graphics Controller (rev 03) > > > > Matt tells me that this (drop-dead box-killing!) bug is still present > in current kernels. Could someone take a look please? > > The code seems very simple, and I couldn't spot a problem. Probably > this means that I'm even simpler. > I'm wondering what reading /sys/kernel/debug/dri/.../vma says when DRM_DEBUG_CODE is enabled, it seems to have been written for this type of debugging. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: avoid switching to text console if there is no panic timeout
On Mon, 17 Oct 2011, Mandeep Singh Baines wrote: > From: Hugh Dickins > > Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if > we're going to reboot immediately, the user will not be able to see the > messages anyway, and messing with the video mode may display artifacts, > and certainly get into several layers of complexity (including mutexes and > memory allocations) which we shall be much safer to avoid. > > Signed-off-by: Hugh Dickins > [ Edited commit message and modified to short-circuit panic_timeout < 0 > instead of testing panic_timeout >= 0. -Mandeep ] > Signed-off-by: Mandeep Singh Baines > Cc: Dave Airlie > Cc: Andrew Morton > Cc: dri-devel at lists.freedesktop.org Acked-by: David Rientjes
DRM-related kmalloc-32 memory leak in 2.6.35
On Mon, 27 Sep 2010, Andrew Morton wrote: > > Still present in 2.6.35. Appears to be DRM: > > > > 845 drm_vm_open_locked+0x72/0x109 age=43/37572/59269 pid=2089 > > cpus=0-1 > > > > That's after about a minute of uptime. Grows to 100k in about a day. > > > > dmesg bits: > > [0.834653] [drm] Initialized drm 1.1.0 20060810 > > [0.834986] pci :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > > [0.834995] pci :00:02.0: setting latency timer to 64 > > [1.002572] mtrr: type mismatch for e000,1000 old: write-back > > new: write-combining > > [1.002580] [drm] MTRR allocation failed. Graphics performance may > > suffer. > > [1.019880] acpi device:03: registered as cooling_device2 > > [1.021520] input: Video Bus as > > /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 > > [1.021543] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: > > no) > > [1.021855] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > > minor 0 > > > > This is with: > > > > 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 > > Integrated Graphics Controller (rev 03) > > 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 > > Integrated Graphics Controller (rev 03) > > > > Matt tells me that this (drop-dead box-killing!) bug is still present > in current kernels. Could someone take a look please? > > The code seems very simple, and I couldn't spot a problem. Probably > this means that I'm even simpler. > I'm wondering what reading /sys/kernel/debug/dri/.../vma says when DRM_DEBUG_CODE is enabled, it seems to have been written for this type of debugging.
Linux 2.6.39-rc3
On Tue, 12 Apr 2011, Joerg Roedel wrote: > Bisecting actually gave a very weird result. It points to > > d2137d5af4259f50c19addb8246a186c9ffac325 > > which is a merge-commit in the x86 tree. Even more weird is that this > notebook is the only machine with these symptoms, all my other boxes are > fine. > During the bisect I tested commits from Yinghai which were good. It > seems like the problem appeared with the merge. > Alexandre Demers (cc'd) reports a boot failure bisected to the same merge on a 64-bit AMD tricore in https://bugzilla.kernel.org/show_bug.cgi?id=33012. We're awaiting earlyprintk= output from that kernel, if possible, and Yinghai asked for his .config and dmesg output from the last known working kernel.
[3.1.4] mm slub memory corruption in drm_vblank_cleanup
On Tue, 13 Dec 2011, batouzo wrote: > Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup. > > After some debugging it seems to be use after freed memory corruption > caused by radeon driver. That's not what's indicated here, this is the poison value being overwritten and detected on free. > With radeon + kms the bug happens around 1 in 3 boot ups, right after > the radeon is enabled (with slub debugging) or later with no debug (few > seconds later or on shutdown esp. in rmmod). > > When disabling radeon and KMS the bug was not seen; > > > Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in > drm_vblank_cleanup+0x78/0x90 [drm] > Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in > drm_vblank_cleanup+0x48/0x90 [drm] > > It is Amd Bulldozer computer, with Radeon card: > 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO > [Radeon HD 5450] > > Debian stable. Builded with make-kpkg using gcc 4.4.5 > >messages: http://pastebin.com/NXN5EPtG > config used: http://pastebin.com/AeVxEX7c > > Interesting part of the messages linked above is: > > > [ 94.401991] fb0: radeondrmfb frame buffer device > [ 94.401992] drm: registered panic notifier > [ 94.402033] [drm] Initialized radeon 2.11.0 20080528 for :01:00.0 > on minor 0 > [ 94.402921] > = > [ 94.402961] BUG kmalloc-16: Poison overwritten > [ 94.402982] > - > [ 94.402983] > [ 94.403025] INFO: 0x880137dbbc38-0x880137dbbc3b. First byte > 0x0 instead of 0x6b > [ 94.403066] INFO: Allocated in drm_vblank_init+0x139/0x260 [drm] > age=253 cpu=3 pid=535 > [ 94.403103] set_track+0x58/0x100 > [ 94.403119] alloc_debug_processing+0x160/0x170 > [ 94.403140] __slab_alloc+0x26d/0x440 > [ 94.403160] drm_vblank_init+0x139/0x260 [drm] > [ 94.403182] drm_debugfs_create_files+0xcb/0x1a0 [drm] > [ 94.403208] drm_vblank_init+0x139/0x260 [drm] > [ 94.403228] __kmalloc+0x100/0x180 > [ 94.403247] drm_vblank_init+0x139/0x260 [drm] > [ 94.403276] radeon_irq_kms_init+0x6d/0x160 [radeon] > [ 94.403303] evergreen_init+0x11c/0x2a0 [radeon] > [ 94.403337] radeon_device_init+0x3c9/0x470 [radeon] > [ 94.403367] radeon_driver_load_kms+0xad/0x160 [radeon] > [ 94.403394] drm_get_pci_dev+0x198/0x2c0 [drm] > [ 94.403416] local_pci_probe+0x55/0xd0 > [ 94.403433] pci_device_probe+0x10a/0x130 > [ 94.403453] driver_sysfs_add+0x72/0xa0 > [ 94.403474] INFO: Freed in drm_vblank_cleanup+0x78/0x90 [drm] age=235 > cpu=0 pid=535 > [ 94.403508] set_track+0x58/0x100 > [ 94.403524] free_debug_processing+0x1f3/0x240 > [ 94.403545] __slab_free+0x1a6/0x2b0 > [ 94.403562] native_read_tsc+0x2/0x20 > [ 94.403580] delay_tsc+0x42/0x80 > [ 94.403598] drm_vblank_cleanup+0x78/0x90 [drm] > [ 94.403625] radeon_irq_kms_fini+0xd/0x60 [radeon] > [ 94.403651] evergreen_init+0x289/0x2a0 [radeon] > [ 94.403677] radeon_device_init+0x3c9/0x470 [radeon] > [ 94.403704] radeon_driver_load_kms+0xad/0x160 [radeon] > [ 94.403731] drm_get_pci_dev+0x198/0x2c0 [drm] > [ 94.403751] local_pci_probe+0x55/0xd0 > [ 94.403772] pci_device_probe+0x10a/0x130 > [ 94.403791] driver_sysfs_add+0x72/0xa0 > [ 94.404806] driver_probe_device+0x8e/0x1b0 > [ 94.405782] __driver_attach+0x93/0xa0 > [ 94.406031] INFO: Slab 0xea0004df6e80 objects=23 used=23 fp=0x >(null) flags=0x2004080 > [ 94.406031] INFO: Object 0x880137dbbc38 @offset=7224 > fp=0x880137dbb830 > [ 94.406031] > [ 94.406031] Bytes b4 0x880137dbbc28: 06 0e ff ff 00 00 00 00 5a > 5a 5a 5a 5a 5a 5a 5a ..?? > [ 94.406031] Object 0x880137dbbc38: 00 00 00 00 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b 6b a5 kkk??? > [ 94.406031] Redzone 0x880137dbbc48: bb bb bb bb bb bb bb bb > > [ 94.406031] Padding 0x880137dbbd88: 5a 5a 5a 5a 5a 5a 5a 5a > > [ 94.406031] Pid: 466, comm: udevd Not tainted 3.1.4-norm007+dbg #1 > [ 94.406031] Call Trace: > [ 94.406031] [] ? check_bytes_and_report+0x110/0x150 > [ 94.406031] [] ? check_object+0x1fe/0x250 > [ 94.406031] [] ? shmem_symlink+0xd4/0x220 > [ 94.406031] [] ? shmem_symlink+0xd4/0x220 > [ 94.406031] [] ? alloc_debug_processing+0xee/0x170 > [ 94.406031] [] ? __slab_alloc+0x26d/0x440 > [ 94.406031] [] ? shmem_symlink+0xd4/0x220 > [ 94.406031] [] ? inode_init_always+0xfc/0x1b0 > [ 94.406031] [] ? alloc_inode+0x32/0x90 > [ 94.406031] [] ? shmem_symlink+0xd4/0x220 > [ 94.406031] [] ? __kmalloc_track_caller+0xf8/0x180 > [ 94.406031] [] ? kmemdup+0x27/0x60 > [ 94.406031] [] ? shmem_symlink+0xd4/0x220 > [ 94.406031] [] ? vfs_symlink+0x87/0xa0 > [ 94.406031] [] ? sys_symlinkat+0xdc/0xf0 > [ 94.406031] [] ? system_call_fastpath+0x16/0x1b
[PATCH] drm: avoid switching to text console if there is no panic timeout
On Mon, 17 Oct 2011, David Rientjes wrote: > On Mon, 17 Oct 2011, Mandeep Singh Baines wrote: > > > From: Hugh Dickins > > > > Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if > > we're going to reboot immediately, the user will not be able to see the > > messages anyway, and messing with the video mode may display artifacts, > > and certainly get into several layers of complexity (including mutexes and > > memory allocations) which we shall be much safer to avoid. > > > > Signed-off-by: Hugh Dickins > > [ Edited commit message and modified to short-circuit panic_timeout < 0 > > instead of testing panic_timeout >= 0. -Mandeep ] > > Signed-off-by: Mandeep Singh Baines > > Cc: Dave Airlie > > Cc: Andrew Morton > > Cc: dri-devel at lists.freedesktop.org > > Acked-by: David Rientjes > Dave, where do we stand on this? I haven't seen it hit Linus' tree and I don't see it in git://people.freedesktop.org/~airlied/linux.
Regression in panic
On Mon, 20 Jun 2011, Mandeep Singh Baines wrote: > Hi Dave, > > I think this change is causing a regression I'm seeing in panic. > Before this change, I'd get a > reboot on panic (we've configured as such). > > With this change, my machine gets wedged if the machine is running in > X when the panic occurs. > > I traced the code flow to this: > > bust_spinlocks(0); > ->unblank_screen(); >->do_unblank_screen(0); > ->vc->vc_sw->con_blank(vc, 0, 0); >->fbcon_blank(vc, 0, 0); > ->update_screen(vc); >->redraw_screen(vc, 0); > ->vc->vc_sw->con_switch(vc); >->fbcon_switch(vc); > ->ops->update_start(info); >->bit_update_start(info); > ->fb_pan_display(info, &ops->var); > ->info->fbops->fb_pan_display(var, info); > ->drm_fb_helper_pan_display(var, info); > ->mutex_lock(&dev->mode_config.mutex); *this blocks* > > With this change, there is now a lot going on in the panic path. Stuff > that I'm not sure is safe when panicking. In addition to the > mutex_lock, there is also a del_timer_sync() > now happening in the context of panic(). > > I see this bug with a 2.6.38 kernel but did a quick scan of a newer > kernels and did not see anything that changed in this path so I > suspect its still there. > > Reverting this change fixes the regression. > Chris Fowler reports something similar when running 2.6.38 by inducing a kernel panic via the oom killer -- see http://marc.info/?l=linux-kernel&m=130805985022791. I've added him to the cc so he can participate in the thread and cherry-pick any fixes (last status update was that he was going to be trying 2.6.38.8). -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/6] char: use vma_pages() to replace (vm_end - vm_start) >> PAGE_SHIFT
On Mon, 15 Apr 2013, Libin wrote:
> diff --git a/drivers/char/mspec.c b/drivers/char/mspec.c
> index e1f60f9..ed0703f 100644
> --- a/drivers/char/mspec.c
> +++ b/drivers/char/mspec.c
> @@ -168,7 +168,7 @@ mspec_close(struct vm_area_struct *vma)
> if (!atomic_dec_and_test(&vdata->refcnt))
> return;
>
> - last_index = (vdata->vm_end - vdata->vm_start) >> PAGE_SHIFT;
> + last_index = vma_pages(vdata);
> for (index = 0; index < last_index; index++) {
> if (vdata->maddr[index] == 0)
> continue;
vdata is of type struct vma_data * and vma_pages() takes a formal of type
struct vm_area_struct *, so these are incompatible. Hopefully you tested
the other changes and simply lack an ia64 cross compiler for this one,
because it will emit a warning.
[patch] drivers, drm: fix qxl build error when debugfs is disabled
Fix build error when CONFIG_DEBUG_FS is disabled:
drivers/gpu/drm/qxl/qxl_debugfs.c: In function 'qxl_debugfs_init':
drivers/gpu/drm/qxl/qxl_debugfs.c:76:2: error: implicit declaration of function
'drm_debugfs_create_files'
drivers/gpu/drm/qxl/qxl_debugfs.c: In function 'qxl_debugfs_takedown':
drivers/gpu/drm/qxl/qxl_debugfs.c:84:2: error: implicit declaration of function
'drm_debugfs_remove_files'
Signed-off-by: David Rientjes
---
drivers/gpu/drm/qxl/qxl_debugfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c
b/drivers/gpu/drm/qxl/qxl_debugfs.c
--- a/drivers/gpu/drm/qxl/qxl_debugfs.c
+++ b/drivers/gpu/drm/qxl/qxl_debugfs.c
@@ -35,6 +35,7 @@
#include "qxl_object.h"
+#if defined(CONFIG_DEBUG_FS)
static int
qxl_debugfs_irq_received(struct seq_file *m, void *data)
{
@@ -69,20 +70,25 @@ static struct drm_info_list qxl_debugfs_list[] = {
{ "qxl_buffers", qxl_debugfs_buffers_info, 0, NULL },
};
#define QXL_DEBUGFS_ENTRIES ARRAY_SIZE(qxl_debugfs_list)
+#endif
int
qxl_debugfs_init(struct drm_minor *minor)
{
+#if defined(CONFIG_DEBUG_FS)
drm_debugfs_create_files(qxl_debugfs_list, QXL_DEBUGFS_ENTRIES,
minor->debugfs_root, minor);
+#endif
return 0;
}
void
qxl_debugfs_takedown(struct drm_minor *minor)
{
+#if defined(CONFIG_DEBUG_FS)
drm_debugfs_remove_files(qxl_debugfs_list, QXL_DEBUGFS_ENTRIES,
minor);
+#endif
}
int qxl_debugfs_add_files(struct qxl_device *qdev,
[PATCH] drm: Do not use BUG_ON(!spin_is_locked())
On Sun, 10 Aug 2014, Guenter Roeck wrote: > spin_is_locked() always returns false in uniprocessor configurations > and can therefore not be used with BUG_ON. Replace it with > assert_spin_locked(), which exists for that very purpose. > It may be helpful to assess whether any of these sites should be converted to lockdep_assert_held() so they have no cost when lockdep isn't enabled but still reveal problems when debugging.
[PATCH] drm: Do not use BUG_ON(!spin_is_locked())
On Mon, 11 Aug 2014, sanjeev sharma wrote: > Hello David, > > Here is the old discussion carried out on this. > > http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802 > I'm suggesting that if you don't want to incur the cost of the conditional everytime you call a certain function with assert_spin_locked() that you could covert these to lockdep_assert_held() so the check is only done when lockdep is enabled for debugging.
[PATCH] drm: Do not use BUG_ON(!spin_is_locked())
On Mon, 11 Aug 2014, Rob Clark wrote: > > I'm suggesting that if you don't want to incur the cost of the conditional > > everytime you call a certain function with assert_spin_locked() that you > > could covert these to lockdep_assert_held() so the check is only done when > > lockdep is enabled for debugging. > > not sure about the nouveau parts, but for the omap and msm hunks, this > code getting called at potentially vblank rate (so maybe once or twice > per ~16ms).. and lockdep has considerable overhead (for a gpu driver) > so I don't always have it enabled. So it sounds like for those two at > least assert_spin_locked() is a better option. > Unless there's a bug, assert_spin_locked() is just going to incur an unnecessary cost every time it is called at runtime. My suggestion was to limit that check only to debugging kernels that include enabling lockdep when tracking down problems rather than needlessly evaluating the conditional every time when there are no bugs.
[PATCH] tree wide: Use kvfree() than conditional kfree()/vfree()
On Mon, 9 Nov 2015, Tetsuo Handa wrote: > There are many locations that do > > if (memory_was_allocated_by_vmalloc) > vfree(ptr); > else > kfree(ptr); > > but kvfree() can handle both kmalloc()ed memory and vmalloc()ed memory > using is_vmalloc_addr(). Unless callers have special reasons, we can > replace this branch with kvfree(). Please check and reply if you found > problems. > > Signed-off-by: Tetsuo Handa > Acked-by: Michal Hocko > Cc: Russell King # arm > Cc: # apei > Cc: # drbd > Cc: # mspec > Cc: # drm > Cc: Oleg Drokin # lustre > Cc: Andreas Dilger # lustre > Cc: # coda > Cc: # jffs2 > Cc: Jan Kara # udf > Cc: # xattr > Cc: # ipc + mm > Cc: # ipv4 Acked-by: David Rientjes
