| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CA+icZUV-UM_9OSfGfYyb0-qZrFSuqeX-7BiPQ0NbyF7bADW-qA@mail.gmail.com> Date: Thu, 25 Jul 2013 17:34:04 +0200 From: Sedat Dilek <sedat.dilek@...il.com> To: Daniel Vetter <daniel.vetter@...ll.ch> Cc: Jani Nikula <jani.nikula@...ux.intel.com>, Stephen Rothwell <sfr@...b.auug.org.au>, intel-gfx <intel-gfx@...ts.freedesktop.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, DRI <dri-devel@...ts.freedesktop.org>, linux-next <linux-next@...r.kernel.org> Subject: Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ] On Thu, Jul 25, 2013 at 5:05 PM, Daniel Vetter <daniel.vetter@...ll.ch> wrote: > On Thu, Jul 25, 2013 at 5:03 PM, Sedat Dilek <sedat.dilek@...il.com> wrote: >> On Thu, Jul 25, 2013 at 4:27 PM, Daniel Vetter <daniel@...ll.ch> wrote: >>> On Thu, Jul 25, 2013 at 04:23:40PM +0200, Sedat Dilek wrote: >>>> On Thu, Jul 25, 2013 at 3:36 PM, Daniel Vetter <daniel@...ll.ch> wrote: >>>> > On Thu, Jul 25, 2013 at 12:37:44PM +0200, Sedat Dilek wrote: >>>> >> On Thu, Jul 25, 2013 at 12:21 PM, Jani Nikula >>>> >> <jani.nikula@...ux.intel.com> wrote: >>>> >> > On Thu, 25 Jul 2013, Sedat Dilek <sedat.dilek@...il.com> wrote: >>>> >> >> On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek <sedat.dilek@...il.com> wrote: >>>> >> >>> On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula >>>> >> >>> <jani.nikula@...ux.intel.com> wrote: >>>> >> >>>> On Thu, 25 Jul 2013, Sedat Dilek <sedat.dilek@...il.com> wrote: >>>> >> >>>>> On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell <sfr@...b.auug.org.au> wrote: >>>> >> >>>>>> Hi all, >>>> >> >>>>>> >>>> >> >>>>>> Changes since 20130724: >>>> >> >>>>>> >>>> >> >>>>>> Removed tree: >>>> >> >>>>>> arm-dt (at maintainer's request) >>>> >> >>>>>> >>>> >> >>>>>> The wireless-next tree lost its build failure and gained a conflict >>>> >> >>>>>> against Linus' tree. >>>> >> >>>>>> >>>> >> >>>>>> The tty tree lost its build failure. >>>> >> >>>>>> >>>> >> >>>>>> The staging tree gained a build failure for which I disabled a driver. >>>> >> >>>>>> >>>> >> >>>>>> ---------------------------------------------------------------------------- >>>> >> >>>>>> >>>> >> >>>>> >>>> >> >>>>> [ CCing drm and drm-intel folks ] >>>> >> >>>>> >>>> >> >>>>> With today's next-20130725 I see the following: >>>> >> >>>> >>>> >> >>>> Use of dev_priv->gt_lock in I915_WRITE through >>>> >> >>>> intel_disable_gt_powersave before spin lock init, caused by >>>> >> >>>> >>>> >> >>>> commit 181d1b9e31c668259d3798c521672afb8edd355c >>>> >> >>>> Author: Daniel Vetter <daniel.vetter@...ll.ch> >>>> >> >>>> Date: Sun Jul 21 13:16:24 2013 +0200 >>>> >> >>>> >>>> >> >>>> drm/i915: fix up gt init sequence fallout >>>> >> >>>> >>>> >> >>> >>>> >> >>> Ah, cool. >>>> >> >>> >>>> >> >>> I assumed/tested "drm/i915: fix the racy object accounting", but this >>>> >> >>> does not fix it. >>>> >> >>> Will try with yours. >>>> >> >>> >>>> >> >> >>>> >> >> Sorry, Jani. >>>> >> >> >>>> >> >> next-20130725 ships the patch you pointed, too. >>>> >> > >>>> >> > Confused. I meant that the above mentioned commit "drm/i915: fix up gt >>>> >> > init sequence fallout" causes the problem. The patch I included in my >>>> >> > mail should fix it. Could you try that please? >>>> >> > >>>> >> >>>> >> [ Note2myself: Do not read half of the message... ] >>>> >> >>>> >> The bad... Your patch needed some refresh against next-20130725 (guess >>>> >> it's against drm-intel-nightly). >>>> >> >>>> >> The good... YES, your patch fixes the issue for me! >>>> >> >>>> >> The ugly... /me. >>>> >> >>>> >> Feel free to add my: >>>> >> >>>> >> Tested-by: Sedat Dilek <sedat.dilek@...il.com> >>>> >> >>>> >> Thanks for the quick fix! >>>> > >>>> > Thanks a lot for the report, since this should be something I should have >>>> > caught. And for added insult the offending patch is already in Linus' tree >>>> > :( Patch merged to -fixes. >>>> >>>> Hmmm, don't you merge -fixes into -nightly? >>> >>> I do, but it seems to only blow up with spinlock debugging enabling I >>> think. Our QA should run full debug buils in the -nightly testing, but >>> apparently they didn't catch this. I'm looking into what went wrong here >>> and fix up the process. >> >> First, I thought I made my merge wrong, but there is no >> >> $ grep spin_lock_init linux-next/drivers/gpu/drm/i915/i915_dma.c | grep gt_lock >> >> Same in [1]: >> ... >> spin_lock_init(&dev_priv->irq_lock); >> spin_lock_init(&dev_priv->gpu_error.lock); >> spin_lock_init(&dev_priv->backlight.lock); >> spin_lock_init(&dev_priv->uncore.lock); > > It's hiding in plain sight here ;-) -next has it renamed to > uncore.lock, so I've applied the patch to -fixes only. I've also > changed the patch in -fixes to cause an explicit conflict here, makes > merging a bit easier. Ah, I see... "drm/i915: Colocate all GT access routines in the same file" @@ -1493,7 +1477,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) ... - spin_lock_init(&dev_priv->gt_lock); + spin_lock_init(&dev_priv->uncore.lock); ... - Sedat - http://cgit.freedesktop.org/~danvet/drm-intel/commit/drivers/gpu/drm/i915/i915_dma.c?h=drm-intel-nightly&id=907b28c56ea40629aa6595ddfa414ec2fc7da41c > -Daniel > >> spin_lock_init(&dev_priv->mm.object_stat_lock); >> ... >> >> - Sedat - >> >> [1] http://cgit.freedesktop.org/~danvet/drm-intel/tree/drivers/gpu/drm/i915/i915_dma.c?h=drm-intel-nightly#n1477 >> >> >>> -Daniel >>> -- >>> Daniel Vetter >>> Software Engineer, Intel Corporation >>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists