From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> To: Stephen Rothwell <sfr@canb.auug.org.au>, Intel Graphics <intel-gfx@lists.freedesktop.org>, DRI <dri-devel@lists.freedesktop.org>, linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Wilson <chris@chris-wilson.co.uk> Subject: Re: linux-next: build failure after merge of the rcu tree Date: Wed, 8 Mar 2017 09:40:13 -0800 [thread overview] Message-ID: <20170308174013.GH30506@linux.vnet.ibm.com> (raw) In-Reply-To: <20170308101338.sp4yekncbext7qzf@phenom.ffwll.local> On Wed, Mar 08, 2017 at 11:13:38AM +0100, Daniel Vetter wrote: > On Wed, Mar 08, 2017 at 12:16:45PM +1100, Stephen Rothwell wrote: > > Hi Paul, > > > > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig) > > failed like this: > > > > In file included from include/linux/resource_ext.h:19:0, > > from include/linux/pci.h:32, > > from include/drm/drmP.h:50, > > from drivers/gpu/drm/i915/i915_gem.c:28: > > drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function 'mock_gem_device': > > drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:9: error: 'SLAB_DESTROY_BY_RCU' undeclared (first use in this function) > > SLAB_DESTROY_BY_RCU); > > ^ > > include/linux/slab.h:149:4: note: in definition of macro 'KMEM_CACHE' > > (__flags), NULL) > > ^ > > drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:9: note: each undeclared identifier is reported only once for each function it appears in > > SLAB_DESTROY_BY_RCU); > > ^ > > include/linux/slab.h:149:4: note: in definition of macro 'KMEM_CACHE' > > (__flags), NULL) > > ^ > > / > > > > Caused by commit > > > > 24b7cb25b8d1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU") > > Awesome rename. Count us in among the people who first thought this > provides more guarantees than it does. Glad you like it! ;-) > > interacting with commit > > > > 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission") > > > > from the drm-intel tree. > > > > I added the following merge fix patch: > > > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > Date: Wed, 8 Mar 2017 12:09:49 +1100 > > Subject: [PATCH] drm/i915: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to > > SLAB_TYPESAFE_BY_RCU" > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > > Should we handle this with a topic branch? It's trivial to resolve, but I > fear the note that this conflict exists might get lost somewhere between > now and when the drm pull lands in Linus' inbox in 2 months ... > > Otoh he's probably going to compile test drm extra carefully and will > notice :-) If it gets too ugly, I can always allow both SLAB_TYPESAFE_BY_RCU and SLAB_DESTROY_BY_RCU as synonyms in 4.12, and then remove SLAB_DESTROY_BY_RCU in 4.13. Thanx, Paul > -Daniel > > > --- > > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > index 6a8258eacdcb..9f24c5da3f8d 100644 > > --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > @@ -174,7 +174,7 @@ struct drm_i915_private *mock_gem_device(void) > > i915->requests = KMEM_CACHE(mock_request, > > SLAB_HWCACHE_ALIGN | > > SLAB_RECLAIM_ACCOUNT | > > - SLAB_DESTROY_BY_RCU); > > + SLAB_TYPESAFE_BY_RCU); > > if (!i915->requests) > > goto err_vmas; > > > > -- > > 2.11.0 > > > > -- > > Cheers, > > Stephen Rothwell > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch >
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> To: Stephen Rothwell <sfr@canb.auug.org.au>, Intel Graphics <intel-gfx@lists.freedesktop.org>, DRI <dri-devel@lists.freedesktop.org>, linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Wilson <chris@chris-wilson.co.uk> Subject: Re: linux-next: build failure after merge of the rcu tree Date: Wed, 8 Mar 2017 09:40:13 -0800 [thread overview] Message-ID: <20170308174013.GH30506@linux.vnet.ibm.com> (raw) In-Reply-To: <20170308101338.sp4yekncbext7qzf@phenom.ffwll.local> On Wed, Mar 08, 2017 at 11:13:38AM +0100, Daniel Vetter wrote: > On Wed, Mar 08, 2017 at 12:16:45PM +1100, Stephen Rothwell wrote: > > Hi Paul, > > > > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig) > > failed like this: > > > > In file included from include/linux/resource_ext.h:19:0, > > from include/linux/pci.h:32, > > from include/drm/drmP.h:50, > > from drivers/gpu/drm/i915/i915_gem.c:28: > > drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function 'mock_gem_device': > > drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:9: error: 'SLAB_DESTROY_BY_RCU' undeclared (first use in this function) > > SLAB_DESTROY_BY_RCU); > > ^ > > include/linux/slab.h:149:4: note: in definition of macro 'KMEM_CACHE' > > (__flags), NULL) > > ^ > > drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:9: note: each undeclared identifier is reported only once for each function it appears in > > SLAB_DESTROY_BY_RCU); > > ^ > > include/linux/slab.h:149:4: note: in definition of macro 'KMEM_CACHE' > > (__flags), NULL) > > ^ > > / > > > > Caused by commit > > > > 24b7cb25b8d1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU") > > Awesome rename. Count us in among the people who first thought this > provides more guarantees than it does. Glad you like it! ;-) > > interacting with commit > > > > 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission") > > > > from the drm-intel tree. > > > > I added the following merge fix patch: > > > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > Date: Wed, 8 Mar 2017 12:09:49 +1100 > > Subject: [PATCH] drm/i915: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to > > SLAB_TYPESAFE_BY_RCU" > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > > Should we handle this with a topic branch? It's trivial to resolve, but I > fear the note that this conflict exists might get lost somewhere between > now and when the drm pull lands in Linus' inbox in 2 months ... > > Otoh he's probably going to compile test drm extra carefully and will > notice :-) If it gets too ugly, I can always allow both SLAB_TYPESAFE_BY_RCU and SLAB_DESTROY_BY_RCU as synonyms in 4.12, and then remove SLAB_DESTROY_BY_RCU in 4.13. Thanx, Paul > -Daniel > > > --- > > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > index 6a8258eacdcb..9f24c5da3f8d 100644 > > --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > @@ -174,7 +174,7 @@ struct drm_i915_private *mock_gem_device(void) > > i915->requests = KMEM_CACHE(mock_request, > > SLAB_HWCACHE_ALIGN | > > SLAB_RECLAIM_ACCOUNT | > > - SLAB_DESTROY_BY_RCU); > > + SLAB_TYPESAFE_BY_RCU); > > if (!i915->requests) > > goto err_vmas; > > > > -- > > 2.11.0 > > > > -- > > Cheers, > > Stephen Rothwell > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-03-08 17:40 UTC|newest] Thread overview: 156+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-08 1:16 linux-next: build failure after merge of the rcu tree Stephen Rothwell 2017-03-08 1:16 ` Stephen Rothwell 2017-03-08 10:13 ` Daniel Vetter 2017-03-08 10:13 ` Daniel Vetter 2017-03-08 17:40 ` Paul E. McKenney [this message] 2017-03-08 17:40 ` Paul E. McKenney -- strict thread matches above, loose matches on Subject: below -- 2024-01-24 4:17 Stephen Rothwell 2024-01-24 9:49 ` Jiri Wiesner 2024-01-24 12:12 ` Paul E. McKenney 2024-01-24 13:31 ` Jiri Wiesner 2024-01-24 14:20 ` Paul E. McKenney 2023-07-27 4:19 Stephen Rothwell 2023-07-27 14:08 ` Paul E. McKenney 2023-05-19 0:59 Stephen Rothwell 2023-05-19 2:12 ` Paul E. McKenney 2023-05-22 1:45 ` Stephen Rothwell 2023-05-22 14:57 ` Paul E. McKenney 2023-03-14 1:29 Stephen Rothwell 2023-03-14 4:43 ` Paul E. McKenney 2022-10-17 23:26 Stephen Rothwell 2022-10-18 10:43 ` Frederic Weisbecker 2022-10-18 14:57 ` Paul E. McKenney 2022-04-19 2:36 Stephen Rothwell 2022-04-19 3:31 ` Paul E. McKenney 2021-05-03 0:11 Stephen Rothwell 2021-05-03 16:25 ` Paul E. McKenney 2021-04-22 4:10 Stephen Rothwell 2021-04-22 16:36 ` Paul E. McKenney 2021-03-17 5:36 Stephen Rothwell 2021-03-17 14:23 ` Paul E. McKenney 2021-01-04 0:37 Stephen Rothwell 2021-01-04 12:56 ` Frederic Weisbecker 2020-12-04 8:25 Stephen Rothwell 2020-12-04 19:20 ` Paul E. McKenney 2020-12-06 21:39 ` Stephen Rothwell 2020-12-07 4:48 ` Paul E. McKenney 2020-12-07 8:59 ` Stephen Rothwell 2020-09-17 5:19 Stephen Rothwell 2020-09-17 22:01 ` Paul E. McKenney 2020-09-18 0:00 ` Stephen Rothwell 2020-09-08 5:38 Stephen Rothwell 2020-09-08 13:54 ` Paul E. McKenney 2020-08-18 1:43 Stephen Rothwell 2020-08-18 14:08 ` Paul E. McKenney 2020-06-25 2:57 Stephen Rothwell 2020-06-25 3:45 ` Paul E. McKenney 2020-05-28 9:05 Stephen Rothwell 2020-05-28 16:33 ` Paul E. McKenney 2020-05-28 21:03 ` Paul E. McKenney 2020-04-05 1:49 Stephen Rothwell 2020-04-05 3:10 ` Paul E. McKenney 2020-01-17 3:07 Stephen Rothwell 2019-12-12 2:45 Stephen Rothwell 2019-12-12 4:07 ` Paul E. McKenney 2019-12-12 4:26 ` Stephen Rothwell 2019-12-12 4:41 ` Paul E. McKenney 2020-01-17 3:09 ` Stephen Rothwell 2019-08-13 7:57 Stephen Rothwell 2019-08-13 15:31 ` Paul E. McKenney 2019-08-12 6:12 Stephen Rothwell 2019-08-12 16:19 ` Paul E. McKenney 2019-08-13 5:25 ` Stephen Rothwell 2019-08-13 14:38 ` Paul E. McKenney 2017-09-04 4:50 Stephen Rothwell 2017-09-04 16:39 ` Paul E. McKenney 2017-08-28 4:25 Stephen Rothwell 2017-08-28 17:50 ` Paul E. McKenney 2017-08-11 4:43 Stephen Rothwell 2017-08-11 4:54 ` Paul E. McKenney 2017-08-11 9:14 ` Peter Zijlstra 2017-08-11 14:39 ` Paul E. McKenney 2017-08-11 14:45 ` Peter Zijlstra 2017-08-11 14:41 ` Peter Zijlstra 2017-08-11 20:12 ` Paul E. McKenney 2017-05-29 6:02 Stephen Rothwell 2017-05-29 21:15 ` Paul E. McKenney 2017-05-30 1:40 ` Stephen Rothwell 2017-05-30 1:54 ` Joe Perches 2017-05-30 2:14 ` Paul E. McKenney 2017-05-30 2:20 ` Joe Perches 2017-05-30 3:13 ` Stephen Rothwell 2017-05-30 4:10 ` Michael Ellerman 2017-06-02 17:51 ` Paul E. McKenney 2017-04-20 5:36 Stephen Rothwell 2017-04-20 14:23 ` Paul E. McKenney 2017-04-19 3:50 Stephen Rothwell 2017-04-19 4:06 ` Paul E. McKenney 2017-04-19 5:45 ` Stephen Rothwell 2017-01-19 3:34 Stephen Rothwell 2017-01-19 21:54 ` Paul McKenney 2017-02-13 2:21 ` Stephen Rothwell 2017-02-13 4:37 ` Paul E. McKenney 2017-02-13 6:43 ` Stephen Rothwell 2017-03-08 1:16 ` Stephen Rothwell 2017-03-08 1:37 ` Paul E. McKenney 2017-03-08 18:05 ` Paul E. McKenney 2016-05-02 4:37 Stephen Rothwell 2016-05-02 11:06 ` Paul E. McKenney 2016-02-01 2:55 Stephen Rothwell 2016-02-01 9:53 ` Paul E. McKenney 2016-01-07 8:57 Stephen Rothwell 2016-01-07 18:02 ` Paul E. McKenney 2016-01-07 20:19 ` Stephen Rothwell 2016-01-07 20:52 ` Paul E. McKenney 2016-01-08 1:37 ` Boqun Feng 2016-01-08 3:41 ` Paul E. McKenney 2016-01-08 4:08 ` Stephen Rothwell 2016-01-08 4:48 ` Paul E. McKenney 2016-01-08 4:54 ` Boqun Feng 2016-01-08 15:53 ` Paul E. McKenney 2016-01-08 15:57 ` Tejun Heo 2016-01-08 16:18 ` Paul E. McKenney 2016-01-08 15:58 ` Boqun Feng 2016-01-08 4:10 ` Stephen Rothwell 2015-09-01 3:50 Stephen Rothwell 2015-09-01 7:49 ` Paul E. McKenney 2015-09-02 3:58 ` Stephen Rothwell 2015-09-02 5:26 ` Paul E. McKenney 2015-09-02 6:40 ` Davidlohr Bueso 2015-09-02 7:14 ` Paul E. McKenney 2015-09-02 7:29 ` Ingo Molnar 2015-09-02 8:34 ` Paul E. McKenney 2015-07-16 3:14 Stephen Rothwell 2015-07-16 3:51 ` Paul E. McKenney 2015-07-16 5:50 ` Stephen Rothwell 2015-07-17 11:40 ` Ingo Molnar 2015-07-17 17:35 ` Paul E. McKenney 2015-07-17 18:53 ` Paul E. McKenney 2015-07-17 19:51 ` Ingo Molnar 2015-07-17 21:33 ` Paul E. McKenney 2015-07-18 2:40 ` Ingo Molnar 2015-04-13 10:39 Stephen Rothwell 2015-04-13 11:06 ` Borislav Petkov 2015-04-13 11:34 ` Ingo Molnar 2015-04-13 12:40 ` Paul E. McKenney 2015-02-27 2:18 Stephen Rothwell 2015-02-27 5:59 ` Paul E. McKenney 2014-12-26 7:51 Stephen Rothwell 2014-12-26 16:54 ` Paul E. McKenney 2014-12-27 16:24 ` Pranith Kumar 2014-12-27 17:20 ` Pranith Kumar 2014-12-31 1:45 ` Paul E. McKenney 2014-12-12 6:12 Stephen Rothwell 2014-12-12 17:23 ` Paul E. McKenney 2014-12-10 8:09 Stephen Rothwell 2014-12-10 15:03 ` Pranith Kumar 2014-12-10 15:18 ` Paul E. McKenney 2014-12-09 11:42 Stephen Rothwell 2014-12-09 14:07 ` Paul E. McKenney 2012-04-16 4:11 Stephen Rothwell 2012-04-16 17:02 ` Paul E. McKenney 2010-09-17 2:42 Stephen Rothwell 2010-09-17 2:42 ` Stephen Rothwell 2010-09-17 4:39 ` David Miller 2010-09-17 5:34 ` Eric Dumazet 2010-09-17 23:17 ` Paul E. McKenney
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=20170308174013.GH30506@linux.vnet.ibm.com \ --to=paulmck@linux.vnet.ibm.com \ --cc=chris@chris-wilson.co.uk \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-next@vger.kernel.org \ --cc=sfr@canb.auug.org.au \ /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: linkBe 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.