All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.