All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, <stable@vger.kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Cc: "osstest service owner" <osstest-admin@xenproject.org>,
	xen-devel@lists.xensource.com,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
	"David Vrabel" <david.vrabel@citrix.com>
Subject: Re: [linux-3.14 bisection] complete test-amd64-i386-xl-qcow2
Date: Fri, 11 Sep 2015 16:10:46 +0100	[thread overview]
Message-ID: <1441984246.3549.82.camel@citrix.com> (raw)
In-Reply-To: <1441185512.26292.111.camel@citrix.com>

ping for 3.10.y and 3.14.y

Thanks,
Ian.

On Wed, 2015-09-02 at 10:18 +0100, Ian Campbell wrote:
> [resending to correct stable address, sorry folks]
> 
> TL;DR: Any backport of 30b03d05e074 to earlier than commit 1401c00e59e
> ("xen/gntdev: convert priv->lock to a mutex", which was added in v4.0)
> needs $something doing to it, either s/mutex/spinlock/ or (more likely)
> backporting of 1401c00e59e too.
> 
> Looking at LTS:
> 
> 3.18.y:	  Backported both.
> 3.16.y:	  Has backported neither
> 3.14.y:	* Only backported 30b03d05e074
> 3.12.y:	  Has backported neither
> 3.10.y:	* Only backported 30b03d05e074
> 3.4.y:	  Has backported neither
> 3.2.y:	  Has backported neither
> 
> So AFAICT 3.14.y and 3.10.y need fixes, probably following 3.18 and
> backporting 1401c00e59e.
> 
> 3.16/12/4/2 might need to be careful if they subsequently pick up
> 30b03d05.
> 
> See below for the build log error.
> 
> On Tue, 2015-09-01 at 11:05 +0100, Ian Campbell wrote:
> > On Tue, 2015-09-01 at 10:57 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [linux-3.14 bisection] complete test-amd64
> > > -i386
> > > -xl-qcow2"):
> > > > On Wed, 2015-08-26 at 20:02 +0000, osstest service owner wrote:
> > > > >   commit 9e6c072a69d87100808d16279d60e9f857291340
> > > > >   Author: Marek Marczykowski-Górecki <
> > > > > marmarek@invisiblethingslab.com
> > > > > > 
> > > > >   Date:   Fri Jun 26 03:28:24 2015 +0200
> > > > >   
> > > > >       xen/gntdevt: Fix race condition in gntdev_release()
> > > > 
> > > > I'm not sure what to make of this.
> > > > 
> > > > The qcow2 test is one of the only ones I'd expect to be exercising 
> > > > gntdev
> > > > (most tests use LVM+blkback), which explains why this particular 
> > > > commit 
> > > > is
> > > > apparently seeing issues due to this particular change.
> > > 
> > > (You mean `which explains why this particular _test_ is [failing]',
> > > I think.)
> > 
> > Indeed.
> > 
> > > The host serial log in one of the confirmation tests of 9e6c072a
> > > shows
> > > serious trouble:
> > > 
> > >  http://logs.test-lab.xenproject.org/osstest/logs/60893/test-amd64-i3
> > > 86
> > > -xl-qcow2/serial-huxelrebe1.log
> > > 
> > >  Aug 26 19:36:51.841068 [  738.050547] BUG: unable to handle kernel
> > >  NULL pointer dereference at 00000014
> > > 
> > >  Aug 26 19:36:56.753068 [  738.050594] IP: []
> > >  __mmu_notifier_invalidate_range_start+0x33/0x70
> > > 
> > > And the immediately preceding confirmation flight, which got a pass
> > > on
> > > 9e6c072a~1, seems fine:
> > > 
> > >  http://logs.test-lab.xenproject.org/osstest/logs/60892/test-amd64-i3
> > > 86
> > > -xl-qcow2/serial-huxelrebe1.log
> > > 
> > > But, it's difficult to see how that gntdev fix would be responsible
> > > for the bug.  Perhaps it changes the order in which certain things
> > > happen so as to expose another bug.
> > 
> > Or perhaps there was a fix and/or change in behaviour in the
> > mmunotifier
> > stuff which the patch relied on but which isn't in 3.14?
> 
> Looking at http://logs.test-lab.xenproject.org/osstest/logs/60949/'s buil
> d
> jobs:
> http://logs.test-lab.xenproject.org/osstest/logs/60949/build-amd64
> -pvops/5.ts-kernel-build.log contains:
> 
> drivers/xen/gntdev.c: In function ‘gntdev_release’:
> drivers/xen/gntdev.c:532:2: warning: passing argument 1 of
> ‘mutex_lock’
> from incompatible pointer type [enabled by default]
> In file included from include/linux/notifier.h:13:0,
>                  from include/linux/memory_hotplug.h:6,
>                  from include/linux/mmzone.h:821,
>                  from include/linux/gfp.h:5,
>                  from include/linux/kmod.h:22,
>                  from include/linux/module.h:13,
>                  from drivers/xen/gntdev.c:24:
> include/linux/mutex.h:157:13: note: expected ‘struct mutex *’ but
> argument is of type ‘struct spinlock_t *’
> drivers/xen/gntdev.c:539:2: warning: passing argument 1 of
> ‘mutex_unlock’ from incompatible pointer type [enabled by default]
> In file included from include/linux/notifier.h:13:0,
>                  from include/linux/memory_hotplug.h:6,
>                  from include/linux/mmzone.h:821,
>                  from include/linux/gfp.h:5,
>                  from include/linux/kmod.h:22,
>                  from include/linux/module.h:13,
>                  from drivers/xen/gntdev.c:24:
> include/linux/mutex.h:174:13: note: expected ‘struct mutex *’ but
> argument is of type ‘struct spinlock_t *’
> 
> Which is somehow a warning and not a build failure.
> 
> Ian.

WARNING: multiple messages have this Message-ID (diff)
From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	stable@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "osstest service owner" <osstest-admin@xenproject.org>,
	xen-devel@lists.xensource.com,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
	"David Vrabel" <david.vrabel@citrix.com>
Subject: Re: [linux-3.14 bisection] complete test-amd64-i386-xl-qcow2
Date: Fri, 11 Sep 2015 16:10:46 +0100	[thread overview]
Message-ID: <1441984246.3549.82.camel@citrix.com> (raw)
In-Reply-To: <1441185512.26292.111.camel@citrix.com>

ping for 3.10.y and 3.14.y

Thanks,
Ian.

On Wed, 2015-09-02 at 10:18 +0100, Ian Campbell wrote:
> [resending to correct stable address, sorry folks]
> 
> TL;DR: Any backport of 30b03d05e074 to earlier than commit 1401c00e59e
> ("xen/gntdev: convert priv->lock to a mutex", which was added in v4.0)
> needs $something doing to it, either s/mutex/spinlock/ or (more likely)
> backporting of 1401c00e59e too.
> 
> Looking at LTS:
> 
> 3.18.y:	  Backported both.
> 3.16.y:	  Has backported neither
> 3.14.y:	* Only backported 30b03d05e074
> 3.12.y:	  Has backported neither
> 3.10.y:	* Only backported 30b03d05e074
> 3.4.y:	  Has backported neither
> 3.2.y:	  Has backported neither
> 
> So AFAICT 3.14.y and 3.10.y need fixes, probably following 3.18 and
> backporting 1401c00e59e.
> 
> 3.16/12/4/2 might need to be careful if they subsequently pick up
> 30b03d05.
> 
> See below for the build log error.
> 
> On Tue, 2015-09-01 at 11:05 +0100, Ian Campbell wrote:
> > On Tue, 2015-09-01 at 10:57 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [linux-3.14 bisection] complete test-amd64
> > > -i386
> > > -xl-qcow2"):
> > > > On Wed, 2015-08-26 at 20:02 +0000, osstest service owner wrote:
> > > > >   commit 9e6c072a69d87100808d16279d60e9f857291340
> > > > >   Author: Marek Marczykowski-Górecki <
> > > > > marmarek@invisiblethingslab.com
> > > > > > 
> > > > >   Date:   Fri Jun 26 03:28:24 2015 +0200
> > > > >   
> > > > >       xen/gntdevt: Fix race condition in gntdev_release()
> > > > 
> > > > I'm not sure what to make of this.
> > > > 
> > > > The qcow2 test is one of the only ones I'd expect to be exercising 
> > > > gntdev
> > > > (most tests use LVM+blkback), which explains why this particular 
> > > > commit 
> > > > is
> > > > apparently seeing issues due to this particular change.
> > > 
> > > (You mean `which explains why this particular _test_ is [failing]',
> > > I think.)
> > 
> > Indeed.
> > 
> > > The host serial log in one of the confirmation tests of 9e6c072a
> > > shows
> > > serious trouble:
> > > 
> > >  http://logs.test-lab.xenproject.org/osstest/logs/60893/test-amd64-i3
> > > 86
> > > -xl-qcow2/serial-huxelrebe1.log
> > > 
> > >  Aug 26 19:36:51.841068 [  738.050547] BUG: unable to handle kernel
> > >  NULL pointer dereference at 00000014
> > > 
> > >  Aug 26 19:36:56.753068 [  738.050594] IP: []
> > >  __mmu_notifier_invalidate_range_start+0x33/0x70
> > > 
> > > And the immediately preceding confirmation flight, which got a pass
> > > on
> > > 9e6c072a~1, seems fine:
> > > 
> > >  http://logs.test-lab.xenproject.org/osstest/logs/60892/test-amd64-i3
> > > 86
> > > -xl-qcow2/serial-huxelrebe1.log
> > > 
> > > But, it's difficult to see how that gntdev fix would be responsible
> > > for the bug.  Perhaps it changes the order in which certain things
> > > happen so as to expose another bug.
> > 
> > Or perhaps there was a fix and/or change in behaviour in the
> > mmunotifier
> > stuff which the patch relied on but which isn't in 3.14?
> 
> Looking at http://logs.test-lab.xenproject.org/osstest/logs/60949/'s buil
> d
> jobs:
> http://logs.test-lab.xenproject.org/osstest/logs/60949/build-amd64
> -pvops/5.ts-kernel-build.log contains:
> 
> drivers/xen/gntdev.c: In function ‘gntdev_release’:
> drivers/xen/gntdev.c:532:2: warning: passing argument 1 of
> ‘mutex_lock’
> from incompatible pointer type [enabled by default]
> In file included from include/linux/notifier.h:13:0,
>                  from include/linux/memory_hotplug.h:6,
>                  from include/linux/mmzone.h:821,
>                  from include/linux/gfp.h:5,
>                  from include/linux/kmod.h:22,
>                  from include/linux/module.h:13,
>                  from drivers/xen/gntdev.c:24:
> include/linux/mutex.h:157:13: note: expected ‘struct mutex *’ but
> argument is of type ‘struct spinlock_t *’
> drivers/xen/gntdev.c:539:2: warning: passing argument 1 of
> ‘mutex_unlock’ from incompatible pointer type [enabled by default]
> In file included from include/linux/notifier.h:13:0,
>                  from include/linux/memory_hotplug.h:6,
>                  from include/linux/mmzone.h:821,
>                  from include/linux/gfp.h:5,
>                  from include/linux/kmod.h:22,
>                  from include/linux/module.h:13,
>                  from drivers/xen/gntdev.c:24:
> include/linux/mutex.h:174:13: note: expected ‘struct mutex *’ but
> argument is of type ‘struct spinlock_t *’
> 
> Which is somehow a warning and not a build failure.
> 
> Ian.

  parent reply	other threads:[~2015-09-11 15:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-26 20:02 [linux-3.14 bisection] complete test-amd64-i386-xl-qcow2 osstest service owner
2015-09-01  9:19 ` Ian Campbell
2015-09-01  9:38   ` Fabio Fantoni
2015-09-01 10:10     ` Ian Campbell
2015-09-01  9:57   ` Ian Jackson
2015-09-01 10:05     ` Ian Campbell
2015-09-02  9:03       ` Ian Campbell
2015-09-02  9:18       ` Ian Campbell
2015-09-02  9:18         ` Ian Campbell
2015-09-03 11:05         ` Luis Henriques
2015-09-03 11:16           ` [Xen-devel] " David Vrabel
2015-09-03 12:21             ` Luis Henriques
2015-09-03 12:21               ` Luis Henriques
2015-09-11 15:10         ` Ian Campbell [this message]
2015-09-11 15:10           ` Ian Campbell
2015-09-11 15:51           ` Greg Kroah-Hartman
2015-09-11 15:55             ` Ian Campbell
2015-09-26 17:30               ` Greg Kroah-Hartman
2015-09-28  9:27                 ` Ian Campbell
2015-09-28  9:43                   ` Ian Campbell
2015-10-08 22:14         ` Ben Hutchings
2015-10-09  9:15           ` Ian Campbell
2015-10-09  9:15             ` Ian Campbell
2015-10-12 10:11           ` [Xen-devel] " David Vrabel
2015-10-12 10:11             ` David Vrabel
2015-10-12 12:56             ` Ben Hutchings
2015-10-12 13:01               ` David Vrabel
2015-10-12 13:01                 ` David Vrabel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1441984246.3549.82.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=marmarek@invisiblethingslab.com \
    --cc=osstest-admin@xenproject.org \
    --cc=stable@vger.kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.