Re: [regression] [git pull] drm for 4.3
On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
> > The warning on boot seems to be gone as of rc3, but I can now trigger this
> > pretty easily..
>
> http://patchwork.freedesktop.org/patch/60618/
Back from several weeks of travel.. I tried again with rc6, and
I'm still seeing the same traces.
Dave
> > WARNING: CPU: 2 PID: 28911 at drivers/gpu/drm/drm_atomic.c:889
> > drm_atomic_get_property+0x244/0x2d0()
> > CPU: 2 PID: 28911 Comm: trinity-c313 Not tainted 4.3.0-rc3-think+ #14
> > 0379 8801a1377c88 8e35d5ec
> > 8801a1377cc0 8e07a862 880500b392b8 880500a13008
> > 880500b39290 8804fe3806d8 88003fa45668 8801a1377cd0
> > Call Trace:
> > [] dump_stack+0x4e/0x82
> > [] warn_slowpath_common+0x82/0xc0
> > [] warn_slowpath_null+0x1a/0x20
> > [] drm_atomic_get_property+0x244/0x2d0
> > [] drm_object_property_get_value+0x6c/0x70
> > [] dpms_show+0x2f/0x70
> > [] dev_attr_show+0x20/0x50
> > [] ? sysfs_file_ops+0x41/0x60
> > [] sysfs_kf_seq_show+0xb7/0x110
> > [] kernfs_seq_show+0x26/0x30
> > [] seq_read+0xe6/0x430
> > [] kernfs_fop_read+0x127/0x170
> > [] ? mutex_lock_nested+0x26b/0x3f0
> > [] __vfs_read+0x28/0xe0
> > [] ? mutex_lock_nested+0x287/0x3f0
> > [] ? __fdget_pos+0x49/0x50
> > [] ? __fdget_pos+0x49/0x50
> > [] vfs_read+0x86/0x130
> > [] SyS_read+0x49/0xb0
> > [] entry_SYSCALL_64_fastpath+0x12/0x6f
> > ---[ end trace e053063c697a1355 ]---
> >
> > 887 case DRM_MODE_OBJECT_CONNECTOR: {
> > 888 struct drm_connector *connector =
> > obj_to_connector(obj);
> > 889
> > WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
> > 890 ret = drm_atomic_connector_get_property(connector,
> > 891 connector->state, property, val);
> > 892 break;
> > 893 }
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
---end quoted text---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [regression] [git pull] drm for 4.3
On Tue, Oct 20, 2015 at 03:33:27PM +1000, Dave Airlie wrote: > On 20 October 2015 at 07:54, Daniel Vetter wrote: > > On Mon, Oct 19, 2015 at 04:19:08PM -0400, da...@codemonkey.org.uk wrote: > >> On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote: > >> > >> > > The warning on boot seems to be gone as of rc3, but I can now > >> trigger this pretty easily.. > >> > > >> > http://patchwork.freedesktop.org/patch/60618/ > >> > >> Back from several weeks of travel.. I tried again with rc6, and > >> I'm still seeing the same traces. > > > > Oh crap, applied patch to wrong tree. We need to cherry-pick > > > > commit 621bd0f6982badd6483acb191eb7b6226a578328 > > Author: Daniel Vetter > > Date: Tue Sep 29 09:56:53 2015 +0200 > > > > drm: Fix locking for sysfs dpms file > > > > to drm-fixes. Sorry about that screw-up. Dave, can you pls do that one? It > > even comes with the needed cc: stable included (since the locking breakage > > was done in 4.0, it only surface due to a new warning in 4.3). > > That is already in Linus's tree, I picked it last week I think. Yeah, that's in the tree I'm testing. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] [git pull] drm for 4.3
On Thu, Sep 24, 2015 at 04:26:28PM +0300, Jani Nikula wrote:
> On Thu, 24 Sep 2015, "da...@codemonkey.org.uk"
> wrote:
> > On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
> > > Hey,
> > >
> > > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
> > > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
> > > > > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
> > > > > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
> > > > > > > Cc'ing Maarten and Matt; I'm guessing this may be related to
> > one of
> > > > > > > their recent patches.
> > > > >
> > > > > Sounds like this showed up before my recent work, but I think I
> > might
> > > > > have seen similar problems while working on atomic watermarks; the
> > > > > issues I was seeing were because the initial hardware readout could
> > > > > leave primary->visible set to true even when the CRTC was off. My
> > > > > series (which is still under development) contains this patch to
> > fix
> > > > > that:
> > > > >
> > > > > http://patchwork.freedesktop.org/patch/59564/
> > > > >
> > > > > Does applying that help with the problems reported here?
> > > >
> > > > No difference at all for me.
> > > Looks like a (reopened) dup of 91952?
> > >
> > > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
> > > visible", and get me the results?
> >
> > This doesn't apply on top of Linus' current tree.
> > If you let me know what it's dependant on, I'll do a build with
> > those patches tomorrow.
>
> It's now part of the drm-intel-fixes pull request [1], maybe it's
> easiest to pull that in? Just four commits on top of
> v4.3-rc2. Alternatively pick it up from our repo [2].
The warning on boot seems to be gone as of rc3, but I can now trigger this
pretty easily..
WARNING: CPU: 2 PID: 28911 at drivers/gpu/drm/drm_atomic.c:889
drm_atomic_get_property+0x244/0x2d0()
CPU: 2 PID: 28911 Comm: trinity-c313 Not tainted 4.3.0-rc3-think+ #14
0379 8801a1377c88 8e35d5ec
8801a1377cc0 8e07a862 880500b392b8 880500a13008
880500b39290 8804fe3806d8 88003fa45668 8801a1377cd0
Call Trace:
[] dump_stack+0x4e/0x82
[] warn_slowpath_common+0x82/0xc0
[] warn_slowpath_null+0x1a/0x20
[] drm_atomic_get_property+0x244/0x2d0
[] drm_object_property_get_value+0x6c/0x70
[] dpms_show+0x2f/0x70
[] dev_attr_show+0x20/0x50
[] ? sysfs_file_ops+0x41/0x60
[] sysfs_kf_seq_show+0xb7/0x110
[] kernfs_seq_show+0x26/0x30
[] seq_read+0xe6/0x430
[] kernfs_fop_read+0x127/0x170
[] ? mutex_lock_nested+0x26b/0x3f0
[] __vfs_read+0x28/0xe0
[] ? mutex_lock_nested+0x287/0x3f0
[] ? __fdget_pos+0x49/0x50
[] ? __fdget_pos+0x49/0x50
[] vfs_read+0x86/0x130
[] SyS_read+0x49/0xb0
[] entry_SYSCALL_64_fastpath+0x12/0x6f
---[ end trace e053063c697a1355 ]---
887 case DRM_MODE_OBJECT_CONNECTOR: {
888 struct drm_connector *connector = obj_to_connector(obj);
889
WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
890 ret = drm_atomic_connector_get_property(connector,
891 connector->state, property, val);
892 break;
893 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] [git pull] drm for 4.3
On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote: > Hey, > > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]: > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote: > > > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote: > > > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote: > > > > > Cc'ing Maarten and Matt; I'm guessing this may be related to one of > > > > > their recent patches. > > > > > > Sounds like this showed up before my recent work, but I think I might > > > have seen similar problems while working on atomic watermarks; the > > > issues I was seeing were because the initial hardware readout could > > > leave primary->visible set to true even when the CRTC was off. My > > > series (which is still under development) contains this patch to fix > > > that: > > > > > > http://patchwork.freedesktop.org/patch/59564/ > > > > > > Does applying that help with the problems reported here? > > > > No difference at all for me. > Looks like a (reopened) dup of 91952? > > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's > visible", and get me the results? This doesn't apply on top of Linus' current tree. If you let me know what it's dependant on, I'll do a build with those patches tomorrow. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13
On Sun, Jul 16, 2017 at 10:57:27PM +, Trond Myklebust wrote: > > BUG: KASAN: global-out-of-bounds in call_start+0x93/0x100 > > Read of size 8 at addr 8d582588 by task kworker/0:1/22 > > Does the following patch fix it? Yep, seems to do the trick! Dave
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13
Another NFSv4 KASAN splat, this time from rc3. == BUG: KASAN: use-after-free in nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] Read of size 8 at addr 8804508af528 by task kworker/2:1/34 CPU: 2 PID: 34 Comm: kworker/2:1 Not tainted 4.13.0-rc3-think+ #1 Workqueue: rpciod rpc_async_schedule [sunrpc] Call Trace: dump_stack+0x68/0xa1 print_address_description+0xd9/0x270 kasan_report+0x257/0x370 ? nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] check_memory_region+0x13a/0x1a0 __asan_loadN+0xf/0x20 nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] ? nfs4_exchange_id_release+0xb0/0xb0 [nfsv4] rpc_exit_task+0x69/0x110 [sunrpc] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc] __rpc_execute+0x1a0/0x840 [sunrpc] ? rpc_wake_up_queued_task+0x50/0x50 [sunrpc] ? __lock_is_held+0x9a/0x100 ? debug_lockdep_rcu_enabled.part.16+0x1a/0x30 rpc_async_schedule+0x12/0x20 [sunrpc] process_one_work+0x4d5/0xa70 ? flush_delayed_work+0x70/0x70 ? lock_acquire+0xfc/0x220 worker_thread+0x88/0x630 ? pci_mmcfg_check_reserved+0xc0/0xc0 kthread+0x1a6/0x1f0 ? process_one_work+0xa70/0xa70 ? kthread_create_on_node+0xc0/0xc0 ret_from_fork+0x27/0x40 Allocated by task 1: save_stack_trace+0x1b/0x20 save_stack+0x46/0xd0 kasan_kmalloc+0xad/0xe0 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0xe0/0x2f0 getname_flags+0x43/0x220 getname+0x12/0x20 do_sys_open+0x14c/0x2b0 SyS_open+0x1e/0x20 do_syscall_64+0xea/0x260 return_from_SYSCALL_64+0x0/0x7a Freed by task 1: save_stack_trace+0x1b/0x20 save_stack+0x46/0xd0 kasan_slab_free+0x72/0xc0 kmem_cache_free+0xa8/0x300 putname+0x80/0x90 do_sys_open+0x22f/0x2b0 SyS_open+0x1e/0x20 do_syscall_64+0xea/0x260 return_from_SYSCALL_64+0x0/0x7a The buggy address belongs to the object at 8804508aeac0\x0a which belongs to the cache names_cache of size 4096 The buggy address is located 2664 bytes inside of\x0a 4096-byte region [8804508aeac0, 8804508afac0) The buggy address belongs to the page: page:ea0011422a00 count:1 mapcount:0 mapping: (null) index:0x0 [CONT START] compound_mapcount: 0 flags: 0x80008100(slab|head) raw: 80008100 000100070007 raw: ea00113d6020 ea001136e220 8804664f8040 page dumped because: kasan: bad access detected Memory state around the buggy address: 8804508af400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 8804508af480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >8804508af500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ 8804508af580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 8804508af600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13
On Mon, Jul 31, 2017 at 10:35:45PM -0700, Linus Torvalds wrote: > On Mon, Jul 31, 2017 at 8:43 AM, da...@codemonkey.org.uk > wrote: > > Another NFSv4 KASAN splat, this time from rc3. > > > > BUG: KASAN: use-after-free in nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] > > Ugh. It's really hard to tell what access that it - KASAN doesn't > actually give enough information. There's lots of 8-byte accesses > there in that function. > > Any chance of getting the output from > >./scripts/faddr2line vmlinux nfs4_exchange_id_done+0x3d7/0x8e0 Hm, that points to this.. 7463 /* Save the EXCHANGE_ID verifier session trunk tests */ 7464 memcpy(clp->cl_confirm.data, cdata->args.verifier->data, 7465sizeof(clp->cl_confirm.data)); Dave
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13
On Tue, Aug 01, 2017 at 10:20:31AM -0700, Linus Torvalds wrote: > So I think the 'pathname' part may actually be entirely a red herring, > and it's the underlying access itself that just picks up a random > pointer from a stack that now contains something different. And KASAN > didn't notice the stale stack access itself, because the stack slot is > still valid - it's just no longer the original 'verifier' allocation. > > Or *something* like that. > > None of this looks even remotely new, though - the code seems to go > back to 2009. Have you just changed what you're testing to trigger > these things? No idea why it only just showed up, but it isn't 100% reproducable either. A month or so ago I did disable the V4 code on the server completely (as I was using v3 everywhere else), so maybe I started hitting a fallback path somewhere. *shrug* Dave
