d0
> [ 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
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://sy
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 comm
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_L
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 reapin
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.freedeskt
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
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 det
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))
>
#x27;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/
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
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 pa
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] [d
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
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] [d
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
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 det
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
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 pa
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))
>
#x27;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/
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 shoul
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 cond
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 fo
gt; 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
25 matches
Mail list logo
