From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luis Henriques Subject: Re: [linux-3.14 bisection] complete test-amd64-i386-xl-qcow2 Date: Thu, 3 Sep 2015 12:05:54 +0100 Message-ID: <20150903110554.GB2601@ares> References: <1441099198.27618.13.camel@citrix.com> <21989.30329.419566.715627@mariner.uk.xensource.com> <1441101938.27618.17.camel@citrix.com> <1441185512.26292.111.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <1441185512.26292.111.camel@citrix.com> Sender: stable-owner@vger.kernel.org To: Ian Campbell Cc: Ian Jackson , stable@vger.kernel.org, Greg Kroah-Hartman , osstest service owner , xen-devel@lists.xensource.com, Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= , David Vrabel , Jiri Slaby List-Id: xen-devel@lists.xenproject.org On Wed, Sep 02, 2015 at 10:18:32AM +0100, Ian Campbell wrote: > [resending to correct stable address, sorry folks] >=20 > TL;DR: Any backport of 30b03d05e074 to earlier than commit 1401c00e59= e > ("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 likel= y) > backporting of 1401c00e59e too. >=20 > Looking at LTS: >=20 > 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 >=20 > So AFAICT 3.14.y and 3.10.y need fixes, probably following 3.18 and > backporting 1401c00e59e. >=20 > 3.16/12/4/2 might need to be careful if they subsequently pick up 30b= 03d05. > Thank you Ian. In fact, I had explicitly dropped 30b03d05e074 ("xen/gntdevt: Fix race condition in gntdev_release()") from the 3.16 kernel and notified stable maintainers about this problem (in a reply t= o a 3.12 review email). Simply replacing the mutex by the spinlock in this commit seems to caus= e problems (sleep in atomic) as pointed out by Jiri in other thread. Since 1401c00e59ea ("xen/gntdev: convert priv->lock to a mutex") is a clean cherry-pick for 3.16 (and probably to older kernels as well), I'm happy to pick both commits if you can confirm they are both good for ol= der stable kernels (they seem to be!) Cheers, -- Lu=C3=ADs > See below for the build log error. >=20 > 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-am= d64 > > > -i386 > > > -xl-qcow2"): > > > > On Wed, 2015-08-26 at 20:02 +0000, osstest service owner wrote: > > > > > commit 9e6c072a69d87100808d16279d60e9f857291340 > > > > > Author: Marek Marczykowski-G=C3=B3recki < > > > > > marmarek@invisiblethingslab.com > > > > > >=20 > > > > > Date: Fri Jun 26 03:28:24 2015 +0200 > > > > > =20 > > > > > xen/gntdevt: Fix race condition in gntdev_release() > > > >=20 > > > > I'm not sure what to make of this. > > > >=20 > > > > The qcow2 test is one of the only ones I'd expect to be exercis= ing=20 > > > > gntdev > > > > (most tests use LVM+blkback), which explains why this particula= r=20 > > > > commit=20 > > > > is > > > > apparently seeing issues due to this particular change. > > >=20 > > > (You mean `which explains why this particular _test_ is [failing]= ', > > > I think.) > >=20 > > Indeed. > >=20 > > > The host serial log in one of the confirmation tests of 9e6c072a = shows > > > serious trouble: > > >=20 > > > http://logs.test-lab.xenproject.org/osstest/logs/60893/test-amd6= 4-i386 > > > -xl-qcow2/serial-huxelrebe1.log > > >=20 > > > Aug 26 19:36:51.841068 [ 738.050547] BUG: unable to handle kern= el > > > NULL pointer dereference at 00000014 > > >=20 > > > Aug 26 19:36:56.753068 [ 738.050594] IP: [] > > > __mmu_notifier_invalidate_range_start+0x33/0x70 > > >=20 > > > And the immediately preceding confirmation flight, which got a pa= ss on > > > 9e6c072a~1, seems fine: > > >=20 > > > http://logs.test-lab.xenproject.org/osstest/logs/60892/test-amd6= 4-i386 > > > -xl-qcow2/serial-huxelrebe1.log > > >=20 > > > But, it's difficult to see how that gntdev fix would be responsib= le > > > for the bug. Perhaps it changes the order in which certain thing= s > > > happen so as to expose another bug. > >=20 > > Or perhaps there was a fix and/or change in behaviour in the mmunot= ifier > > stuff which the patch relied on but which isn't in 3.14? >=20 > Looking at http://logs.test-lab.xenproject.org/osstest/logs/60949/'s = build > jobs: > http://logs.test-lab.xenproject.org/osstest/logs/60949/build-amd64 > -pvops/5.ts-kernel-build.log contains: >=20 > drivers/xen/gntdev.c: In function =C3=A2=E2=82=AC=CB=9Cgntdev_release= =C3=A2=E2=82=AC=E2=84=A2: > drivers/xen/gntdev.c:532:2: warning: passing argument 1 of =C3=A2=E2=82= =AC=CB=9Cmutex_lock=C3=A2=E2=82=AC=E2=84=A2 > 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 =C3=A2=E2=82=AC=CB=9Cstr= uct mutex *=C3=A2=E2=82=AC=E2=84=A2 but > argument is of type =C3=A2=E2=82=AC=CB=9Cstruct spinlock_t *=C3=A2=E2= =82=AC=E2=84=A2 > drivers/xen/gntdev.c:539:2: warning: passing argument 1 of > =C3=A2=E2=82=AC=CB=9Cmutex_unlock=C3=A2=E2=82=AC=E2=84=A2 from incomp= atible 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 =C3=A2=E2=82=AC=CB=9Cstr= uct mutex *=C3=A2=E2=82=AC=E2=84=A2 but > argument is of type =C3=A2=E2=82=AC=CB=9Cstruct spinlock_t *=C3=A2=E2= =82=AC=E2=84=A2 >=20 > Which is somehow a warning and not a build failure. >=20 > Ian. > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html