linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the workqueues tree with Linus' tree
@ 2014-01-13  4:09 Stephen Rothwell
  0 siblings, 0 replies; 9+ messages in thread
From: Stephen Rothwell @ 2014-01-13  4:09 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-next, linux-kernel, Chuansheng Liu, Bjorn Helgaas

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
kernel/workqueue.c between commit 12997d1a999c ("Revert "workqueue: allow
work_on_cpu() to be called recursively"") from Linus' tree and commit
440a11360326 ("workqueue: Calling destroy_work_on_stack() to pair with
INIT_WORK_ONSTACK()") from the workqueues tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/workqueue.c
index b010eac595d2,fdeec6e9d025..000000000000
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@@ -4827,7 -4833,15 +4828,8 @@@ long work_on_cpu(int cpu, long (*fn)(vo
  
  	INIT_WORK_ONSTACK(&wfc.work, work_for_cpu_fn);
  	schedule_work_on(cpu, &wfc.work);
 -
 -	/*
 -	 * The work item is on-stack and can't lead to deadlock through
 -	 * flushing.  Use __flush_work() to avoid spurious lockdep warnings
 -	 * when work_on_cpu()s are nested.
 -	 */
 -	__flush_work(&wfc.work);
 -
 +	flush_work(&wfc.work);
+ 	destroy_work_on_stack(&wfc.work);
  	return wfc.ret;
  }
  EXPORT_SYMBOL_GPL(work_on_cpu);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* linux-next: manual merge of the workqueues tree with Linus' tree
@ 2023-06-26  4:11 Stephen Rothwell
  0 siblings, 0 replies; 9+ messages in thread
From: Stephen Rothwell @ 2023-06-26  4:11 UTC (permalink / raw)
  To: Tejun Heo
  Cc: Arnd Bergmann, Linus Torvalds, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

Hi all,

Today's linux-next merge of the workqueues tree got a conflict in:

  include/linux/workqueue.h

between commit:

  afa4bb778e48 ("workqueue: clean up WORK_* constant types, clarify masking")

from Linus' tree and commit:

  525ff9c29657 ("workqueue: fix enum type for gcc-13")

from the workqueues tree.

I fixed it up (I just used the former 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* linux-next: manual merge of the workqueues tree with Linus' tree
@ 2021-07-15  1:22 Stephen Rothwell
  0 siblings, 0 replies; 9+ messages in thread
From: Stephen Rothwell @ 2021-07-15  1:22 UTC (permalink / raw)
  To: Tejun Heo
  Cc: Christian Brauner, Linux Kernel Mailing List,
	Linux Next Mailing List, Paul Gortmaker

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

Hi all,

Today's linux-next merge of the workqueues tree got a conflict in:

  include/linux/fs_context.h

between commit:

  d1d488d81370 ("fs: add vfs_parse_fs_param_source() helper")

from Linus' tree and commit:

  7f5ba4806d3c ("cgroup1: fix leaked context root causing sporadic NULL deref in LTP")

from the workqueues 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.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/fs_context.h
index e2bc16300c82,5b44b0195a28..000000000000
--- a/include/linux/fs_context.h
+++ b/include/linux/fs_context.h
@@@ -139,8 -139,7 +139,9 @@@ extern int vfs_parse_fs_string(struct f
  extern int generic_parse_monolithic(struct fs_context *fc, void *data);
  extern int vfs_get_tree(struct fs_context *fc);
  extern void put_fs_context(struct fs_context *fc);
 +extern int vfs_parse_fs_param_source(struct fs_context *fc,
 +				     struct fs_parameter *param);
+ extern void fc_drop_locked(struct fs_context *fc);
  
  /*
   * sget() wrappers to be called from the ->get_tree() op.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: linux-next: manual merge of the workqueues tree with Linus' tree
  2013-03-19 22:13     ` Tejun Heo
@ 2013-03-19 22:20       ` Stephen Rothwell
  0 siblings, 0 replies; 9+ messages in thread
From: Stephen Rothwell @ 2013-03-19 22:20 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-next, linux-kernel, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

Hi Tejun,

On Tue, 19 Mar 2013 15:13:08 -0700 Tejun Heo <tj@kernel.org> wrote:
>
> On Wed, Mar 20, 2013 at 09:05:40AM +1100, Stephen Rothwell wrote:
> > > Anyways, I pulled master into wq/for-next and resolved it there, so it
> > > shouldn't cause you any more trouble.
> > 
> > Ah, OK, thanks.   One small point, when you do a back merge like that,
> > you should always put an explanation in the commit message for the merge.
> 
> Oh, I do that for any permanent branches.  for-next branches are
> ephemeral (at least in my trees) so I usually don't bother.  I do
> compare against for-next when and after sending pull requests with
> proper conflict descriptions, so things are not likely to slip through
> there.  Hmmm.... if it's gonna be helpful to you, I'd be happy to
> describe merge conflicts and resolutions in for-next merges.  Would
> that be helpful?

No, that's OK.  I do wonder some times why some people have "ephemeral"
-next branches, though?  I guess, in your case, that you send your stuff
to Linus in more than one pull request and have just combined them to
reduce the conflicts for my benefit?  Which is fine.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: linux-next: manual merge of the workqueues tree with Linus' tree
  2013-03-19 22:05   ` Stephen Rothwell
@ 2013-03-19 22:13     ` Tejun Heo
  2013-03-19 22:20       ` Stephen Rothwell
  0 siblings, 1 reply; 9+ messages in thread
From: Tejun Heo @ 2013-03-19 22:13 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Andrew Morton

On Wed, Mar 20, 2013 at 09:05:40AM +1100, Stephen Rothwell wrote:
> > Anyways, I pulled master into wq/for-next and resolved it there, so it
> > shouldn't cause you any more trouble.
> 
> Ah, OK, thanks.   One small point, when you do a back merge like that,
> you should always put an explanation in the commit message for the merge.

Oh, I do that for any permanent branches.  for-next branches are
ephemeral (at least in my trees) so I usually don't bother.  I do
compare against for-next when and after sending pull requests with
proper conflict descriptions, so things are not likely to slip through
there.  Hmmm.... if it's gonna be helpful to you, I'd be happy to
describe merge conflicts and resolutions in for-next merges.  Would
that be helpful?

Thanks.

-- 
tejun

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: linux-next: manual merge of the workqueues tree with Linus' tree
  2013-03-19 21:12 ` Tejun Heo
@ 2013-03-19 22:05   ` Stephen Rothwell
  2013-03-19 22:13     ` Tejun Heo
  0 siblings, 1 reply; 9+ messages in thread
From: Stephen Rothwell @ 2013-03-19 22:05 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-next, linux-kernel, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]

Hi Tejun,

On Tue, 19 Mar 2013 14:12:33 -0700 Tejun Heo <tj@kernel.org> wrote:
>
> On Tue, Mar 19, 2013 at 01:19:38PM +1100, Stephen Rothwell wrote:
> > @@@ -456,40 -462,30 +462,30 @@@ static int worker_pool_assign_id(struc
> >   {
> >   	int ret;
> >   
> > - 	mutex_lock(&worker_pool_idr_mutex);
> > - 	ret = idr_alloc(&worker_pool_idr, pool, 0, 0, GFP_KERNEL);
> > - 	if (ret >= 0)
> > - 		pool->id = ret;
> > - 	mutex_unlock(&worker_pool_idr_mutex);
> > + 	lockdep_assert_held(&wq_mutex);
> > + 
> > + 	do {
> >  -		if (!idr_pre_get(&worker_pool_idr, GFP_KERNEL))
> >  -			return -ENOMEM;
> >  -		ret = idr_get_new(&worker_pool_idr, pool, &pool->id);
> > ++		ret = idr_alloc(&worker_pool_idr, pool, 0, 0, GFP_KERNEL);
> > ++		if (ret >= 0)
> > ++			pool->id = ret;
> > + 	} while (ret == -EAGAIN);
> >   
> >  -	return ret;
> >  +	return ret < 0 ? ret : 0;
> 
> We don't need the loop anymore, so it should look like
> 
>   static int worker_pool_assign_id(struct worker_pool *pool)
>   {
> 	  int ret;
> 
> 	  lockdep_assert_held(&wq_mutex);
> 
> 	  ret = idr_alloc(&worker_pool_idr, pool, 0, 0, GFP_KERNEL);
> 	  if (ret >= 0) {
> 		  pool->id = ret;
> 		  return 0;
> 	  }
> 	  return ret;
>   }
> 
> Anyways, I pulled master into wq/for-next and resolved it there, so it
> shouldn't cause you any more trouble.

Ah, OK, thanks.   One small point, when you do a back merge like that,
you should always put an explanation in the commit message for the merge.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: linux-next: manual merge of the workqueues tree with Linus' tree
  2013-03-19  2:19 Stephen Rothwell
@ 2013-03-19 21:12 ` Tejun Heo
  2013-03-19 22:05   ` Stephen Rothwell
  0 siblings, 1 reply; 9+ messages in thread
From: Tejun Heo @ 2013-03-19 21:12 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Andrew Morton

Hey, Stephen.

On Tue, Mar 19, 2013 at 01:19:38PM +1100, Stephen Rothwell wrote:
> @@@ -456,40 -462,30 +462,30 @@@ static int worker_pool_assign_id(struc
>   {
>   	int ret;
>   
> - 	mutex_lock(&worker_pool_idr_mutex);
> - 	ret = idr_alloc(&worker_pool_idr, pool, 0, 0, GFP_KERNEL);
> - 	if (ret >= 0)
> - 		pool->id = ret;
> - 	mutex_unlock(&worker_pool_idr_mutex);
> + 	lockdep_assert_held(&wq_mutex);
> + 
> + 	do {
>  -		if (!idr_pre_get(&worker_pool_idr, GFP_KERNEL))
>  -			return -ENOMEM;
>  -		ret = idr_get_new(&worker_pool_idr, pool, &pool->id);
> ++		ret = idr_alloc(&worker_pool_idr, pool, 0, 0, GFP_KERNEL);
> ++		if (ret >= 0)
> ++			pool->id = ret;
> + 	} while (ret == -EAGAIN);
>   
>  -	return ret;
>  +	return ret < 0 ? ret : 0;

We don't need the loop anymore, so it should look like

  static int worker_pool_assign_id(struct worker_pool *pool)
  {
	  int ret;

	  lockdep_assert_held(&wq_mutex);

	  ret = idr_alloc(&worker_pool_idr, pool, 0, 0, GFP_KERNEL);
	  if (ret >= 0) {
		  pool->id = ret;
		  return 0;
	  }
	  return ret;
  }

Anyways, I pulled master into wq/for-next and resolved it there, so it
shouldn't cause you any more trouble.

Thanks!

-- 
tejun

^ permalink raw reply	[flat|nested] 9+ messages in thread

* linux-next: manual merge of the workqueues tree with Linus' tree
@ 2013-03-19  2:19 Stephen Rothwell
  2013-03-19 21:12 ` Tejun Heo
  0 siblings, 1 reply; 9+ messages in thread
From: Stephen Rothwell @ 2013-03-19  2:19 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-next, linux-kernel, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
kernel/workqueue.c between commit e68035fb65de ("workqueue: convert to
idr_alloc()") from Linus' tree and commit 5bcab3355a55 ("workqueue:
separate out pool and workqueue locking into wq_mutex") from the
workqueues tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/workqueue.c
index 55fac5b,833a152..0000000
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@@ -456,40 -462,30 +462,30 @@@ static int worker_pool_assign_id(struc
  {
  	int ret;
  
- 	mutex_lock(&worker_pool_idr_mutex);
- 	ret = idr_alloc(&worker_pool_idr, pool, 0, 0, GFP_KERNEL);
- 	if (ret >= 0)
- 		pool->id = ret;
- 	mutex_unlock(&worker_pool_idr_mutex);
+ 	lockdep_assert_held(&wq_mutex);
+ 
+ 	do {
 -		if (!idr_pre_get(&worker_pool_idr, GFP_KERNEL))
 -			return -ENOMEM;
 -		ret = idr_get_new(&worker_pool_idr, pool, &pool->id);
++		ret = idr_alloc(&worker_pool_idr, pool, 0, 0, GFP_KERNEL);
++		if (ret >= 0)
++			pool->id = ret;
+ 	} while (ret == -EAGAIN);
  
 -	return ret;
 +	return ret < 0 ? ret : 0;
  }
  
- /*
-  * Lookup worker_pool by id.  The idr currently is built during boot and
-  * never modified.  Don't worry about locking for now.
+ /**
+  * first_pwq - return the first pool_workqueue of the specified workqueue
+  * @wq: the target workqueue
+  *
+  * This must be called either with pwq_lock held or sched RCU read locked.
+  * If the pwq needs to be used beyond the locking in effect, the caller is
+  * responsible for guaranteeing that the pwq stays online.
   */
- static struct worker_pool *worker_pool_by_id(int pool_id)
- {
- 	return idr_find(&worker_pool_idr, pool_id);
- }
- 
- static struct worker_pool *get_std_worker_pool(int cpu, bool highpri)
+ static struct pool_workqueue *first_pwq(struct workqueue_struct *wq)
  {
- 	struct worker_pool *pools = std_worker_pools(cpu);
- 
- 	return &pools[highpri];
- }
- 
- static struct pool_workqueue *get_pwq(unsigned int cpu,
- 				      struct workqueue_struct *wq)
- {
- 	if (!(wq->flags & WQ_UNBOUND)) {
- 		if (likely(cpu < nr_cpu_ids))
- 			return per_cpu_ptr(wq->pool_wq.pcpu, cpu);
- 	} else if (likely(cpu == WORK_CPU_UNBOUND))
- 		return wq->pool_wq.single;
- 	return NULL;
+ 	assert_rcu_or_pwq_lock();
+ 	return list_first_or_null_rcu(&wq->pwqs, struct pool_workqueue,
+ 				      pwqs_node);
  }
  
  static unsigned int work_color_to_flags(int color)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* linux-next: manual merge of the workqueues tree with Linus' tree
@ 2013-03-14  4:29 Stephen Rothwell
  0 siblings, 0 replies; 9+ messages in thread
From: Stephen Rothwell @ 2013-03-14  4:29 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-next, linux-kernel, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
kernel/workqueue.c between commit e68035fb65de ("workqueue: convert to
idr_alloc()") from Linus' tree and commit fa1b54e69bc6 ("workqueue:
update synchronization rules on worker_pool_idr") from the workqueues
tree.

I fixed it up (as suggested - see below) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/workqueue.c
index 55fac5b,2ebd182..0000000
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@@ -456,40 -456,31 +456,32 @@@ static int worker_pool_assign_id(struc
  {
  	int ret;
  
- 	mutex_lock(&worker_pool_idr_mutex);
- 	ret = idr_alloc(&worker_pool_idr, pool, 0, 0, GFP_KERNEL);
- 	if (ret >= 0)
- 		pool->id = ret;
- 	mutex_unlock(&worker_pool_idr_mutex);
+ 	do {
 -		if (!idr_pre_get(&worker_pool_idr, GFP_KERNEL))
 -			return -ENOMEM;
 -
++		idr_preload(GFP_KERNEL);
+ 		spin_lock_irq(&workqueue_lock);
 -		ret = idr_get_new(&worker_pool_idr, pool, &pool->id);
++		ret = idr_alloc(&worker_pool_idr, pool, 0, 0, GFP_NOWAIT);
++		if (ret >= 0)
++			pool->id = ret;
+ 		spin_unlock_irq(&workqueue_lock);
++		idr_preload_end();
+ 	} while (ret == -EAGAIN);
  
 -	return ret;
 +	return ret < 0 ? ret : 0;
  }
  
- /*
-  * Lookup worker_pool by id.  The idr currently is built during boot and
-  * never modified.  Don't worry about locking for now.
+ /**
+  * first_pwq - return the first pool_workqueue of the specified workqueue
+  * @wq: the target workqueue
+  *
+  * This must be called either with workqueue_lock held or sched RCU read
+  * locked.  If the pwq needs to be used beyond the locking in effect, the
+  * caller is responsible for guaranteeing that the pwq stays online.
   */
- static struct worker_pool *worker_pool_by_id(int pool_id)
- {
- 	return idr_find(&worker_pool_idr, pool_id);
- }
- 
- static struct worker_pool *get_std_worker_pool(int cpu, bool highpri)
- {
- 	struct worker_pool *pools = std_worker_pools(cpu);
- 
- 	return &pools[highpri];
- }
- 
- static struct pool_workqueue *get_pwq(unsigned int cpu,
- 				      struct workqueue_struct *wq)
+ static struct pool_workqueue *first_pwq(struct workqueue_struct *wq)
  {
- 	if (!(wq->flags & WQ_UNBOUND)) {
- 		if (likely(cpu < nr_cpu_ids))
- 			return per_cpu_ptr(wq->pool_wq.pcpu, cpu);
- 	} else if (likely(cpu == WORK_CPU_UNBOUND))
- 		return wq->pool_wq.single;
- 	return NULL;
+ 	assert_rcu_or_wq_lock();
+ 	return list_first_or_null_rcu(&wq->pwqs, struct pool_workqueue,
+ 				      pwqs_node);
  }
  
  static unsigned int work_color_to_flags(int color)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2023-06-26  4:11 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-13  4:09 linux-next: manual merge of the workqueues tree with Linus' tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2023-06-26  4:11 Stephen Rothwell
2021-07-15  1:22 Stephen Rothwell
2013-03-19  2:19 Stephen Rothwell
2013-03-19 21:12 ` Tejun Heo
2013-03-19 22:05   ` Stephen Rothwell
2013-03-19 22:13     ` Tejun Heo
2013-03-19 22:20       ` Stephen Rothwell
2013-03-14  4:29 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).