Re: linux-next: manual merge of the rcu tree with Linus' tree

[Paul E. McKenney]

On Mon, Jun 18, 2018 at 01:49:47PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Mon, 18 Jun 2018 13:48:49 +1000 Stephen Rothwell  
> wrote:
> >
> > I am still getting this.
> 
> Maybe this was a bit premature :-)

Actually, this whole mess was due to me forgetting to do the merge-window
reset of rcu/next to the tree actually submitted to mainline.  :-/

Please accept my apologies for the resulting hassles!

Thanx, Paul

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Paul E. McKenney]

On Mon, Jun 18, 2018 at 01:49:47PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Mon, 18 Jun 2018 13:48:49 +1000 Stephen Rothwell  
> wrote:
> >
> > I am still getting this.
> 
> Maybe this was a bit premature :-)

Actually, this whole mess was due to me forgetting to do the merge-window
reset of rcu/next to the tree actually submitted to mainline.  :-/

Please accept my apologies for the resulting hassles!

Thanx, Paul

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Stephen Rothwell]

Hi Paul,

On Mon, 18 Jun 2018 13:48:49 +1000 Stephen Rothwell  
wrote:
>
> I am still getting this.

Maybe this was a bit premature :-)

-- 
Cheers,
Stephen Rothwell


pgpctU4_DnFxM.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Stephen Rothwell]

Hi Paul,

On Mon, 18 Jun 2018 13:48:49 +1000 Stephen Rothwell  
wrote:
>
> I am still getting this.

Maybe this was a bit premature :-)

-- 
Cheers,
Stephen Rothwell


pgpctU4_DnFxM.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Stephen Rothwell]

Hi all,

On Tue, 12 Jun 2018 10:46:07 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   drivers/iommu/amd_iommu.c
> 
> between commit:
> 
>   94c793accacd ("iommu/amd: Hide unused iommu_table_lock")
> 
> from Linus' tree and commit:
> 
>   1df9bb146146 ("EXP iommu: Placeholder for fix in mainline")
> 
> from the rcu tree.

I am still getting this.
-- 
Cheers,
Stephen Rothwell


pgp1L2ooEuUvL.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Stephen Rothwell]

Hi all,

On Tue, 12 Jun 2018 10:46:07 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   drivers/iommu/amd_iommu.c
> 
> between commit:
> 
>   94c793accacd ("iommu/amd: Hide unused iommu_table_lock")
> 
> from Linus' tree and commit:
> 
>   1df9bb146146 ("EXP iommu: Placeholder for fix in mainline")
> 
> from the rcu tree.

I am still getting this.
-- 
Cheers,
Stephen Rothwell


pgp1L2ooEuUvL.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Paul E. McKenney]

On Tue, Jun 12, 2018 at 10:46:07AM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   drivers/iommu/amd_iommu.c
> 
> between commit:
> 
>   94c793accacd ("iommu/amd: Hide unused iommu_table_lock")
> 
> from Linus' tree and commit:
> 
>   1df9bb146146 ("EXP iommu: Placeholder for fix in mainline")
> 
> from the rcu tree.
> 
> I fixed it up (they share some code change) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

I expect to be dropping my commit as soon as I rebase to v4.18-rc1.
In the meantime, please accept my apologies for the noise!

Thanx, Paul

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Paul E. McKenney]

On Tue, Jun 12, 2018 at 10:46:07AM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   drivers/iommu/amd_iommu.c
> 
> between commit:
> 
>   94c793accacd ("iommu/amd: Hide unused iommu_table_lock")
> 
> from Linus' tree and commit:
> 
>   1df9bb146146 ("EXP iommu: Placeholder for fix in mainline")
> 
> from the rcu tree.
> 
> I fixed it up (they share some code change) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

I expect to be dropping my commit as soon as I rebase to v4.18-rc1.
In the meantime, please accept my apologies for the noise!

Thanx, Paul

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Paul E. McKenney]

On Mon, May 14, 2018 at 01:46:36PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   drivers/nvme/host/core.c
> 
> between commit:
> 
>   12d9f07022dc ("nvme: fix use-after-free in nvme_free_ns_head")
> 
> from Linus' tree and commit:
> 
>   d9cf21bae6cf ("nvme: Avoid flush dependency in delete controller flow")
> 
> from the rcu tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thank you, Stephen!!!

Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/nvme/host/core.c
> index 99b857e5a7a9,c3cea8a29843..
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@@ -351,8 -349,7 +351,8 @@@ static void nvme_free_ns_head(struct kr
>   nvme_mpath_remove_disk(head);
>   ida_simple_remove(>subsys->ns_ida, head->instance);
>   list_del_init(>entry);
> - cleanup_srcu_struct(>srcu);
> + cleanup_srcu_struct_quiesced(>srcu);
>  +nvme_put_subsystem(head->subsys);
>   kfree(head);
>   }
>   

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Paul E. McKenney]

On Mon, May 14, 2018 at 01:46:36PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   drivers/nvme/host/core.c
> 
> between commit:
> 
>   12d9f07022dc ("nvme: fix use-after-free in nvme_free_ns_head")
> 
> from Linus' tree and commit:
> 
>   d9cf21bae6cf ("nvme: Avoid flush dependency in delete controller flow")
> 
> from the rcu tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thank you, Stephen!!!

Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/nvme/host/core.c
> index 99b857e5a7a9,c3cea8a29843..
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@@ -351,8 -349,7 +351,8 @@@ static void nvme_free_ns_head(struct kr
>   nvme_mpath_remove_disk(head);
>   ida_simple_remove(>subsys->ns_ida, head->instance);
>   list_del_init(>entry);
> - cleanup_srcu_struct(>srcu);
> + cleanup_srcu_struct_quiesced(>srcu);
>  +nvme_put_subsystem(head->subsys);
>   kfree(head);
>   }
>   

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Stephen Rothwell]

Hi Paul,

On Mon, 25 Sep 2017 20:26:28 -0700 "Paul E. McKenney" 
 wrote:
>
> This conflict will disappear tomorrow, as I have merged the commit
> from Linus's tree in place of mine and have added another commit that 
> removes the READ_ONCE()s.  Same result, but no conflict.  ;-)

Thanks, I figured something like that would happen.
-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Stephen Rothwell]

Hi Paul,

On Mon, 25 Sep 2017 20:26:28 -0700 "Paul E. McKenney" 
 wrote:
>
> This conflict will disappear tomorrow, as I have merged the commit
> from Linus's tree in place of mine and have added another commit that 
> removes the READ_ONCE()s.  Same result, but no conflict.  ;-)

Thanks, I figured something like that would happen.
-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Paul E. McKenney]

On Tue, Sep 26, 2017 at 01:00:18PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/rcu/tree.c
> 
> between commit:
> 
>   28585a832602 ("rcu: Allow for page faults in NMI handlers")
> 
> from Linus' tree and commit:
> 
>   3e2baa988b9c ("rcu: Allow for page faults in NMI handlers")
> 
> from the rcu tree.
> 
> I fixed it up (I just used the rcu tree version) and can carry the fix
> as necessary. This is now fixed as far as linux-next is concerned, but
> any non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Hello, Stephen,

This conflict will disappear tomorrow, as I have merged the commit
from Linus's tree in place of mine and have added another commit that 
removes the READ_ONCE()s.  Same result, but no conflict.  ;-)

Thanx, Paul

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Paul E. McKenney]

On Tue, Sep 26, 2017 at 01:00:18PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/rcu/tree.c
> 
> between commit:
> 
>   28585a832602 ("rcu: Allow for page faults in NMI handlers")
> 
> from Linus' tree and commit:
> 
>   3e2baa988b9c ("rcu: Allow for page faults in NMI handlers")
> 
> from the rcu tree.
> 
> I fixed it up (I just used the rcu tree version) and can carry the fix
> as necessary. This is now fixed as far as linux-next is concerned, but
> any non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Hello, Stephen,

This conflict will disappear tomorrow, as I have merged the commit
from Linus's tree in place of mine and have added another commit that 
removes the READ_ONCE()s.  Same result, but no conflict.  ;-)

Thanx, Paul

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Stephen Rothwell]

Hi Paul,

On Wed, 8 Mar 2017 11:46:33 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   mm/slab_common.c
> 
> between commit:
> 
>   657dc2f97220 ("slab: remove synchronous rcu_barrier() call in memcg cache 
> release path")
> 
> from Linus' tree and commit:
> 
>   24b7cb25b8d1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")
> 
> from the rcu tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

That resolution was obviously wrong, the correct one is this:

diff --cc mm/slab_common.c
index 09d0e849b07f,296413c2bbcd..
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@@ -494,55 -458,29 +494,55 @@@ out_unlock
  }
  EXPORT_SYMBOL(kmem_cache_create);
  
 -static int shutdown_cache(struct kmem_cache *s,
 -  struct list_head *release, bool *need_rcu_barrier)
 +static void slab_caches_to_rcu_destroy_workfn(struct work_struct *work)
  {
 -  if (__kmem_cache_shutdown(s) != 0)
 -  return -EBUSY;
 +  LIST_HEAD(to_destroy);
 +  struct kmem_cache *s, *s2;
 +
 +  /*
-* On destruction, SLAB_DESTROY_BY_RCU kmem_caches are put on the
++   * On destruction, SLAB_TYPESAFE_BY_RCU kmem_caches are put on the
 +   * @slab_caches_to_rcu_destroy list.  The slab pages are freed
 +   * through RCU and and the associated kmem_cache are dereferenced
 +   * while freeing the pages, so the kmem_caches should be freed only
 +   * after the pending RCU operations are finished.  As rcu_barrier()
 +   * is a pretty slow operation, we batch all pending destructions
 +   * asynchronously.
 +   */
 +  mutex_lock(_mutex);
 +  list_splice_init(_caches_to_rcu_destroy, _destroy);
 +  mutex_unlock(_mutex);
 +
 +  if (list_empty(_destroy))
 +  return;
  
 -  if (s->flags & SLAB_TYPESAFE_BY_RCU)
 -  *need_rcu_barrier = true;
 +  rcu_barrier();
  
 -  list_move(>list, release);
 -  return 0;
 +  list_for_each_entry_safe(s, s2, _destroy, list) {
 +#ifdef SLAB_SUPPORTS_SYSFS
 +  sysfs_slab_release(s);
 +#else
 +  slab_kmem_cache_release(s);
 +#endif
 +  }
  }
  
 -static void release_caches(struct list_head *release, bool need_rcu_barrier)
 +static int shutdown_cache(struct kmem_cache *s)
  {
 -  struct kmem_cache *s, *s2;
 +  /* free asan quarantined objects */
 +  kasan_cache_shutdown(s);
  
 -  if (need_rcu_barrier)
 -  rcu_barrier();
 +  if (__kmem_cache_shutdown(s) != 0)
 +  return -EBUSY;
  
 -  list_for_each_entry_safe(s, s2, release, list) {
 +  memcg_unlink_cache(s);
 +  list_del(>list);
 +
-   if (s->flags & SLAB_DESTROY_BY_RCU) {
++  if (s->flags & SLAB_TYPESAFE_BY_RCU) {
 +  list_add_tail(>list, _caches_to_rcu_destroy);
 +  schedule_work(_caches_to_rcu_destroy_work);
 +  } else {
  #ifdef SLAB_SUPPORTS_SYSFS
 -  sysfs_slab_remove(s);
 +  sysfs_slab_release(s);
  #else
slab_kmem_cache_release(s);
  #endif

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Stephen Rothwell]

Hi Paul,

On Wed, 8 Mar 2017 11:46:33 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   mm/slab_common.c
> 
> between commit:
> 
>   657dc2f97220 ("slab: remove synchronous rcu_barrier() call in memcg cache 
> release path")
> 
> from Linus' tree and commit:
> 
>   24b7cb25b8d1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")
> 
> from the rcu tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

That resolution was obviously wrong, the correct one is this:

diff --cc mm/slab_common.c
index 09d0e849b07f,296413c2bbcd..
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@@ -494,55 -458,29 +494,55 @@@ out_unlock
  }
  EXPORT_SYMBOL(kmem_cache_create);
  
 -static int shutdown_cache(struct kmem_cache *s,
 -  struct list_head *release, bool *need_rcu_barrier)
 +static void slab_caches_to_rcu_destroy_workfn(struct work_struct *work)
  {
 -  if (__kmem_cache_shutdown(s) != 0)
 -  return -EBUSY;
 +  LIST_HEAD(to_destroy);
 +  struct kmem_cache *s, *s2;
 +
 +  /*
-* On destruction, SLAB_DESTROY_BY_RCU kmem_caches are put on the
++   * On destruction, SLAB_TYPESAFE_BY_RCU kmem_caches are put on the
 +   * @slab_caches_to_rcu_destroy list.  The slab pages are freed
 +   * through RCU and and the associated kmem_cache are dereferenced
 +   * while freeing the pages, so the kmem_caches should be freed only
 +   * after the pending RCU operations are finished.  As rcu_barrier()
 +   * is a pretty slow operation, we batch all pending destructions
 +   * asynchronously.
 +   */
 +  mutex_lock(_mutex);
 +  list_splice_init(_caches_to_rcu_destroy, _destroy);
 +  mutex_unlock(_mutex);
 +
 +  if (list_empty(_destroy))
 +  return;
  
 -  if (s->flags & SLAB_TYPESAFE_BY_RCU)
 -  *need_rcu_barrier = true;
 +  rcu_barrier();
  
 -  list_move(>list, release);
 -  return 0;
 +  list_for_each_entry_safe(s, s2, _destroy, list) {
 +#ifdef SLAB_SUPPORTS_SYSFS
 +  sysfs_slab_release(s);
 +#else
 +  slab_kmem_cache_release(s);
 +#endif
 +  }
  }
  
 -static void release_caches(struct list_head *release, bool need_rcu_barrier)
 +static int shutdown_cache(struct kmem_cache *s)
  {
 -  struct kmem_cache *s, *s2;
 +  /* free asan quarantined objects */
 +  kasan_cache_shutdown(s);
  
 -  if (need_rcu_barrier)
 -  rcu_barrier();
 +  if (__kmem_cache_shutdown(s) != 0)
 +  return -EBUSY;
  
 -  list_for_each_entry_safe(s, s2, release, list) {
 +  memcg_unlink_cache(s);
 +  list_del(>list);
 +
-   if (s->flags & SLAB_DESTROY_BY_RCU) {
++  if (s->flags & SLAB_TYPESAFE_BY_RCU) {
 +  list_add_tail(>list, _caches_to_rcu_destroy);
 +  schedule_work(_caches_to_rcu_destroy_work);
 +  } else {
  #ifdef SLAB_SUPPORTS_SYSFS
 -  sysfs_slab_remove(s);
 +  sysfs_slab_release(s);
  #else
slab_kmem_cache_release(s);
  #endif

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Paul E. McKenney]

On Wed, Mar 30, 2016 at 11:32:14AM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/rcu/tree.c
> 
> between commit:
> 
>   abedf8e2419f ("rcu: Use simple wait queues where possible in rcutree")
> 
> from Linus' tree and commit:
> 
>   08cace5914ea ("DIAGS: Crude exploratory hack")
> 
> from the rcu tree.
> 
> I fixed it up (I used the rcu tree version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
> 
> I really don't think that that rcu tree patch should be in linux-next,
> right?

Right you are!  I will rework to get the diagnostics out of your way.
-Might- have helped find one of the bugs, but don't look now...

Thanx, Paul

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Paul E. McKenney]

On Wed, Mar 30, 2016 at 11:32:14AM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/rcu/tree.c
> 
> between commit:
> 
>   abedf8e2419f ("rcu: Use simple wait queues where possible in rcutree")
> 
> from Linus' tree and commit:
> 
>   08cace5914ea ("DIAGS: Crude exploratory hack")
> 
> from the rcu tree.
> 
> I fixed it up (I used the rcu tree version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
> 
> I really don't think that that rcu tree patch should be in linux-next,
> right?

Right you are!  I will rework to get the diagnostics out of your way.
-Might- have helped find one of the bugs, but don't look now...

Thanx, Paul

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Paul E. McKenney]

On Thu, Nov 29, 2012 at 02:06:51PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in
> arch/x86/kernel/ptrace.c between commit cb57a2b4cff7 ("x86-32: Export
> kernel_stack_pointer() for modules") from Linus' tree and commit
> 98dbec158343 ("context_tracking: New context tracking susbsystem") from
> the rcu tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good, thank you!

Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc arch/x86/kernel/ptrace.c
> index 974b67e,65b88a5..000
> --- a/arch/x86/kernel/ptrace.c
> +++ b/arch/x86/kernel/ptrace.c
> @@@ -21,8 -21,7 +21,8 @@@
>   #include 
>   #include 
>   #include 
> - #include 
>  +#include 
> + #include 
>   
>   #include 
>   #include 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the rcu tree with Linus' tree

[Paul E. McKenney]

On Thu, Nov 29, 2012 at 02:06:51PM +1100, Stephen Rothwell wrote:
 Hi Paul,
 
 Today's linux-next merge of the rcu tree got a conflict in
 arch/x86/kernel/ptrace.c between commit cb57a2b4cff7 (x86-32: Export
 kernel_stack_pointer() for modules) from Linus' tree and commit
 98dbec158343 (context_tracking: New context tracking susbsystem) from
 the rcu tree.
 
 I fixed it up (see below) and can carry the fix as necessary (no action
 is required).

Looks good, thank you!

Thanx, Paul

 -- 
 Cheers,
 Stephen Rothwells...@canb.auug.org.au
 
 diff --cc arch/x86/kernel/ptrace.c
 index 974b67e,65b88a5..000
 --- a/arch/x86/kernel/ptrace.c
 +++ b/arch/x86/kernel/ptrace.c
 @@@ -21,8 -21,7 +21,8 @@@
   #include linux/signal.h
   #include linux/perf_event.h
   #include linux/hw_breakpoint.h
 - #include linux/rcupdate.h
  +#include linux/module.h
 + #include linux/context_tracking.h
   
   #include asm/uaccess.h
   #include asm/pgtable.h


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/