linux-next: manual merge of the tip tree with the block tree

linux-next: manual merge of the tip tree with the block tree

[Stephen Rothwell]

Hi all,

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

  drivers/block/amiflop.c

between commit:

  f37ecbfc238b ("amifloppy: Convert timers to use timer_setup()")

from the block tree and commit:

  3c557df67257 ("timer: Remove meaningless .data/.function assignments")

from the tip tree.

I fixed it up (I just used the former version of the motor_on_callback
definition) 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

Re: linux-next: manual merge of the tip tree with the block tree

[Jens Axboe]

On 11/01/2017 12:10 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/block/amiflop.c
> 
> between commit:
> 
>   f37ecbfc238b ("amifloppy: Convert timers to use timer_setup()")
> 
> from the block tree and commit:
> 
>   3c557df67257 ("timer: Remove meaningless .data/.function assignments")
> 
> from the tip tree.
> 
> I fixed it up (I just used the former version of the motor_on_callback
> definition) 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.

Kees, why are we in this situation? Making similar timer fixups in the
same driver and submitting it through two different trees is a mess.

-- 
Jens Axboe

Re: linux-next: manual merge of the tip tree with the block tree

[Kees Cook]

On Wed, Nov 1, 2017 at 7:25 AM, Jens Axboe <axboe@kernel.dk> wrote:
> On 11/01/2017 12:10 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the tip tree got a conflict in:
>>
>>   drivers/block/amiflop.c
>>
>> between commit:
>>
>>   f37ecbfc238b ("amifloppy: Convert timers to use timer_setup()")
>>
>> from the block tree and commit:
>>
>>   3c557df67257 ("timer: Remove meaningless .data/.function assignments")
>>
>> from the tip tree.
>>
>> I fixed it up (I just used the former version of the motor_on_callback
>> definition) 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.
>
> Kees, why are we in this situation? Making similar timer fixups in the
> same driver and submitting it through two different trees is a mess.

It's a large conversion with a lot of moving parts and about 1100
callsites. I've tried to minimize conflicts, but without being able to
carry everything in a single tree, it's made things extremely complex.
I'm doing my best to avoid these glitches, but I haven't been 100%
successful. This is mainly the fault of the conversion uncovering more
and more corner cases as I went. :(

-Kees

-- 
Kees Cook
Pixel Security

Re: linux-next: manual merge of the tip tree with the block tree

[Jens Axboe]

On 11/9/20 6:45 AM, Thomas Gleixner wrote:
> On Mon, Nov 09 2020 at 14:14, Stephen Rothwell wrote:
>> Today's linux-next merge of the tip tree got a conflict in:
>>
>>   include/linux/sched/signal.h
>>   include/linux/tracehook.h
>>   kernel/signal.c
>>   kernel/task_work.c
>>
>> between commits:
>>
>>   fdb5f027ce66 ("task_work: use TIF_NOTIFY_SIGNAL if available")
>>   bf6996650675 ("task_work: remove legacy TWA_SIGNAL path")
>>   ceb39b7c17b7 ("kernel: remove checking for TIF_NOTIFY_SIGNAL")
>>
>> from the block tree and commit:
>>
>>   114518eb6430 ("task_work: Use TIF_NOTIFY_SIGNAL if available")
>>   12db8b690010 ("entry: Add support for TIF_NOTIFY_SIGNAL")
>>
>> from the tip tree.
> 
> Jens, how is that supposed to work?
> 
> You need to merge the 'core-entry-notify-signal' tag from the tip tree
> into your next branch to make the follow up changes actually work.

I just haven't rebased with that pulled in yet, will do that this
morning.

> Ideally you send the whole arch + core cleanup muck my way once the
> architecture people are happy.

Crossing fingers that I'll be able to collect all of the reviews in
time, some of them have been picked up in arch trees though. So probably
the easiest if we keep the setup as it is, which should work fine as
soon as I pull in your core branch.

-- 
Jens Axboe

Re: linux-next: manual merge of the tip tree with the block tree

[Thomas Gleixner]

On Mon, Nov 09 2020 at 14:14, Stephen Rothwell wrote:
> Today's linux-next merge of the tip tree got a conflict in:
>
>   include/linux/sched/signal.h
>   include/linux/tracehook.h
>   kernel/signal.c
>   kernel/task_work.c
>
> between commits:
>
>   fdb5f027ce66 ("task_work: use TIF_NOTIFY_SIGNAL if available")
>   bf6996650675 ("task_work: remove legacy TWA_SIGNAL path")
>   ceb39b7c17b7 ("kernel: remove checking for TIF_NOTIFY_SIGNAL")
>
> from the block tree and commit:
>
>   114518eb6430 ("task_work: Use TIF_NOTIFY_SIGNAL if available")
>   12db8b690010 ("entry: Add support for TIF_NOTIFY_SIGNAL")
>
> from the tip tree.

Jens, how is that supposed to work?

You need to merge the 'core-entry-notify-signal' tag from the tip tree
into your next branch to make the follow up changes actually work.

Ideally you send the whole arch + core cleanup muck my way once the
architecture people are happy.

Thanks,

        tglx

linux-next: manual merge of the tip tree with the block tree

[Stephen Rothwell]

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

Hi all,

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

  include/linux/sched/signal.h
  include/linux/tracehook.h
  kernel/signal.c
  kernel/task_work.c

between commits:

  fdb5f027ce66 ("task_work: use TIF_NOTIFY_SIGNAL if available")
  bf6996650675 ("task_work: remove legacy TWA_SIGNAL path")
  ceb39b7c17b7 ("kernel: remove checking for TIF_NOTIFY_SIGNAL")

from the block tree and commit:

  114518eb6430 ("task_work: Use TIF_NOTIFY_SIGNAL if available")
  12db8b690010 ("entry: Add support for TIF_NOTIFY_SIGNAL")

from the tip tree.

I fixed it up (I just used the former versions - this may be wrong,
please let me know) 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 --]

linux-next: manual merge of the tip tree with the block tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the tip tree got conflicts in:

  arch/x86/entry/syscalls/syscall_32.tbl
  arch/x86/entry/syscalls/syscall_64.tbl
  include/uapi/asm-generic/unistd.h

between commits:

  1690d3ffa284 ("Add io_uring IO interface")
  0e5d5b5a94c8 ("io_uring: add support for pre-mapped user IO buffers")

from the block tree and commits:

  0d6040d46817 ("arch: add split IPC system calls where needed")

and folloing ones

from the tip 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 arch/x86/entry/syscalls/syscall_32.tbl
index 2eefd2a7c1ce,955ab6a3b61f..000000000000
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@@ -396,8 -396,36 +396,39 @@@
  382	i386	pkey_free		sys_pkey_free			__ia32_sys_pkey_free
  383	i386	statx			sys_statx			__ia32_sys_statx
  384	i386	arch_prctl		sys_arch_prctl			__ia32_compat_sys_arch_prctl
- 385	i386	io_pgetevents		sys_io_pgetevents		__ia32_compat_sys_io_pgetevents
+ 385	i386	io_pgetevents		sys_io_pgetevents_time32	__ia32_compat_sys_io_pgetevents
  386	i386	rseq			sys_rseq			__ia32_sys_rseq
+ # don't use numbers 387 through 392, add new calls at the end
+ 393	i386	semget			sys_semget    			__ia32_sys_semget
+ 394	i386	semctl			sys_semctl    			__ia32_compat_sys_semctl
+ 395	i386	shmget			sys_shmget    			__ia32_sys_shmget
+ 396	i386	shmctl			sys_shmctl    			__ia32_compat_sys_shmctl
+ 397	i386	shmat			sys_shmat     			__ia32_compat_sys_shmat
+ 398	i386	shmdt			sys_shmdt     			__ia32_sys_shmdt
+ 399	i386	msgget			sys_msgget    			__ia32_sys_msgget
+ 400	i386	msgsnd			sys_msgsnd    			__ia32_compat_sys_msgsnd
+ 401	i386	msgrcv			sys_msgrcv    			__ia32_compat_sys_msgrcv
+ 402	i386	msgctl			sys_msgctl    			__ia32_compat_sys_msgctl
+ 403	i386	clock_gettime64		sys_clock_gettime		__ia32_sys_clock_gettime
+ 404	i386	clock_settime64		sys_clock_settime		__ia32_sys_clock_settime
+ 405	i386	clock_adjtime64		sys_clock_adjtime		__ia32_sys_clock_adjtime
+ 406	i386	clock_getres_time64	sys_clock_getres		__ia32_sys_clock_getres
+ 407	i386	clock_nanosleep_time64	sys_clock_nanosleep		__ia32_sys_clock_nanosleep
+ 408	i386	timer_gettime64		sys_timer_gettime		__ia32_sys_timer_gettime
+ 409	i386	timer_settime64		sys_timer_settime		__ia32_sys_timer_settime
+ 410	i386	timerfd_gettime64	sys_timerfd_gettime		__ia32_sys_timerfd_gettime
+ 411	i386	timerfd_settime64	sys_timerfd_settime		__ia32_sys_timerfd_settime
+ 412	i386	utimensat_time64	sys_utimensat			__ia32_sys_utimensat
+ 413	i386	pselect6_time64		sys_pselect6			__ia32_compat_sys_pselect6_time64
+ 414	i386	ppoll_time64		sys_ppoll			__ia32_compat_sys_ppoll_time64
+ 416	i386	io_pgetevents_time64	sys_io_pgetevents		__ia32_sys_io_pgetevents
+ 417	i386	recvmmsg_time64		sys_recvmmsg			__ia32_compat_sys_recvmmsg_time64
+ 418	i386	mq_timedsend_time64	sys_mq_timedsend		__ia32_sys_mq_timedsend
+ 419	i386	mq_timedreceive_time64	sys_mq_timedreceive		__ia32_sys_mq_timedreceive
+ 420	i386	semtimedop_time64	sys_semtimedop			__ia32_sys_semtimedop
+ 421	i386	rt_sigtimedwait_time64	sys_rt_sigtimedwait		__ia32_compat_sys_rt_sigtimedwait_time64
+ 422	i386	futex_time64		sys_futex			__ia32_sys_futex
+ 423	i386	sched_rr_get_interval_time64	sys_sched_rr_get_interval	__ia32_sys_sched_rr_get_interval
 +425	i386	io_uring_setup		sys_io_uring_setup		__ia32_sys_io_uring_setup
 +426	i386	io_uring_enter		sys_io_uring_enter		__ia32_sys_io_uring_enter
 +427	i386	io_uring_register	sys_io_uring_register		__ia32_sys_io_uring_register
diff --cc arch/x86/entry/syscalls/syscall_64.tbl
index 65c026185e61,2ae92fddb6d5..000000000000
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@@ -343,9 -343,8 +343,11 @@@
  332	common	statx			__x64_sys_statx
  333	common	io_pgetevents		__x64_sys_io_pgetevents
  334	common	rseq			__x64_sys_rseq
+ # don't use numbers 387 through 423, add new calls after the last
+ # 'common' entry
 +425	common	io_uring_setup		__x64_sys_io_uring_setup
 +426	common	io_uring_enter		__x64_sys_io_uring_enter
 +427	common	io_uring_register	__x64_sys_io_uring_register
  
  #
  # x32-specific system call numbers start at 512 to avoid cache impact
diff --cc include/uapi/asm-generic/unistd.h
index d346229a1eb0,acf9a07ab2ff..000000000000
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@@ -740,15 -740,52 +740,58 @@@ __SC_COMP_3264(__NR_io_pgetevents, sys_
  __SYSCALL(__NR_rseq, sys_rseq)
  #define __NR_kexec_file_load 294
  __SYSCALL(__NR_kexec_file_load,     sys_kexec_file_load)
+ /* 295 through 402 are unassigned to sync up with generic numbers, don't use */
+ #if __BITS_PER_LONG == 32
+ #define __NR_clock_gettime64 403
+ __SYSCALL(__NR_clock_gettime64, sys_clock_gettime)
+ #define __NR_clock_settime64 404
+ __SYSCALL(__NR_clock_settime64, sys_clock_settime)
+ #define __NR_clock_adjtime64 405
+ __SYSCALL(__NR_clock_adjtime64, sys_clock_adjtime)
+ #define __NR_clock_getres_time64 406
+ __SYSCALL(__NR_clock_getres_time64, sys_clock_getres)
+ #define __NR_clock_nanosleep_time64 407
+ __SYSCALL(__NR_clock_nanosleep_time64, sys_clock_nanosleep)
+ #define __NR_timer_gettime64 408
+ __SYSCALL(__NR_timer_gettime64, sys_timer_gettime)
+ #define __NR_timer_settime64 409
+ __SYSCALL(__NR_timer_settime64, sys_timer_settime)
+ #define __NR_timerfd_gettime64 410
+ __SYSCALL(__NR_timerfd_gettime64, sys_timerfd_gettime)
+ #define __NR_timerfd_settime64 411
+ __SYSCALL(__NR_timerfd_settime64, sys_timerfd_settime)
+ #define __NR_utimensat_time64 412
+ __SYSCALL(__NR_utimensat_time64, sys_utimensat)
+ #define __NR_pselect6_time64 413
+ __SC_COMP(__NR_pselect6_time64, sys_pselect6, compat_sys_pselect6_time64)
+ #define __NR_ppoll_time64 414
+ __SC_COMP(__NR_ppoll_time64, sys_ppoll, compat_sys_ppoll_time64)
+ #define __NR_io_pgetevents_time64 416
+ __SYSCALL(__NR_io_pgetevents_time64, sys_io_pgetevents)
+ #define __NR_recvmmsg_time64 417
+ __SC_COMP(__NR_recvmmsg_time64, sys_recvmmsg, compat_sys_recvmmsg_time64)
+ #define __NR_mq_timedsend_time64 418
+ __SYSCALL(__NR_mq_timedsend_time64, sys_mq_timedsend)
+ #define __NR_mq_timedreceive_time64 419
+ __SYSCALL(__NR_mq_timedreceive_time64, sys_mq_timedreceive)
+ #define __NR_semtimedop_time64 420
+ __SYSCALL(__NR_semtimedop_time64, sys_semtimedop)
+ #define __NR_rt_sigtimedwait_time64 421
+ __SC_COMP(__NR_rt_sigtimedwait_time64, sys_rt_sigtimedwait, compat_sys_rt_sigtimedwait_time64)
+ #define __NR_futex_time64 422
+ __SYSCALL(__NR_futex_time64, sys_futex)
+ #define __NR_sched_rr_get_interval_time64 423
+ __SYSCALL(__NR_sched_rr_get_interval_time64, sys_sched_rr_get_interval)
+ #endif
 +#define __NR_io_uring_setup 425
 +__SYSCALL(__NR_io_uring_setup, sys_io_uring_setup)
 +#define __NR_io_uring_enter 426
 +__SYSCALL(__NR_io_uring_enter, sys_io_uring_enter)
 +#define __NR_io_uring_register 427
 +__SYSCALL(__NR_io_uring_register, sys_io_uring_register)
  
  #undef __NR_syscalls
 -#define __NR_syscalls 424
 +#define __NR_syscalls 428
  
  /*
   * 32 bit systems traditionally used different

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

Re: linux-next: manual merge of the tip tree with the block tree

[Stephen Rothwell]

Hi all,

On Mon, 3 Jul 2017 13:56:16 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>  +		if (cpu < nr_queues) {
> - 			map[cpu] = cpu_to_queue_index(nr_queues, cpu, online_mask);
> ++			map[cpu] = cpu_to_queue_index(nr_queues, cpu)
>  +		} else {
>  +			first_sibling = get_first_sibling(cpu);
>  +			if (first_sibling == cpu)
> - 				map[cpu] = cpu_to_queue_index(nr_queues, cpu, online_mask);
> ++				map[cpu] = cpu_to_queue_index(nr_queues, cpu)

Clearly, I dropped a couple of semicolons here ... I added them to the
merge resolution.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the tip tree with the block tree

[Stephen Rothwell]

Hi all,

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

  block/blk-mq-cpumap.c

between commit:

  fe631457ff3e ("blk-mq: map all HWQ also in hyperthreaded system")

from the block tree and commit:

  5f042e7cbd9e ("blk-mq: Include all present CPUs in the default queue mapping")

from the tip tree.

I fixed it up (I think - 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 block/blk-mq-cpumap.c
index 2cca4fc43f45,5eaecd40f701..000000000000
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@@ -14,15 -14,10 +14,14 @@@
  #include "blk.h"
  #include "blk-mq.h"
  
- static int cpu_to_queue_index(unsigned int nr_queues, const int cpu,
- 			      const struct cpumask *online_mask)
 -static int cpu_to_queue_index(unsigned int nr_cpus, unsigned int nr_queues,
 -			      const int cpu)
++static int cpu_to_queue_index(unsigned int nr_queues, const int cpu)
  {
 -	return cpu * nr_queues / nr_cpus;
 +	/*
- 	 * Non online CPU will be mapped to queue index 0.
++	 * Non present CPU will be mapped to queue index 0.
 +	 */
- 	if (!cpumask_test_cpu(cpu, online_mask))
++	if (!cpumask_test_cpu(cpu, cpu_present_mask))
 +		return 0;
 +	return cpu % nr_queues;
  }
  
  static int get_first_sibling(unsigned int cpu)
@@@ -40,27 -35,55 +39,26 @@@ int blk_mq_map_queues(struct blk_mq_tag
  {
  	unsigned int *map = set->mq_map;
  	unsigned int nr_queues = set->nr_hw_queues;
- 	const struct cpumask *online_mask = cpu_online_mask;
 -	unsigned int i, nr_cpus, nr_uniq_cpus, queue, first_sibling;
 -	cpumask_var_t cpus;
 -
 -	if (!alloc_cpumask_var(&cpus, GFP_ATOMIC))
 -		return -ENOMEM;
 -
 -	cpumask_clear(cpus);
 -	nr_cpus = nr_uniq_cpus = 0;
 -	for_each_present_cpu(i) {
 -		nr_cpus++;
 -		first_sibling = get_first_sibling(i);
 -		if (!cpumask_test_cpu(first_sibling, cpus))
 -			nr_uniq_cpus++;
 -		cpumask_set_cpu(i, cpus);
 -	}
 -
 -	queue = 0;
 -	for_each_possible_cpu(i) {
 -		if (!cpumask_test_cpu(i, cpu_present_mask)) {
 -			map[i] = 0;
 -			continue;
 -		}
 +	unsigned int cpu, first_sibling;
  
 +	for_each_possible_cpu(cpu) {
  		/*
 -		 * Easy case - we have equal or more hardware queues. Or
 -		 * there are no thread siblings to take into account. Do
 -		 * 1:1 if enough, or sequential mapping if less.
 +		 * First do sequential mapping between CPUs and queues.
 +		 * In case we still have CPUs to map, and we have some number of
 +		 * threads per cores then map sibling threads to the same queue for
 +		 * performace optimizations.
  		 */
 -		if (nr_queues >= nr_cpus || nr_cpus == nr_uniq_cpus) {
 -			map[i] = cpu_to_queue_index(nr_cpus, nr_queues, queue);
 -			queue++;
 -			continue;
 +		if (cpu < nr_queues) {
- 			map[cpu] = cpu_to_queue_index(nr_queues, cpu, online_mask);
++			map[cpu] = cpu_to_queue_index(nr_queues, cpu)
 +		} else {
 +			first_sibling = get_first_sibling(cpu);
 +			if (first_sibling == cpu)
- 				map[cpu] = cpu_to_queue_index(nr_queues, cpu, online_mask);
++				map[cpu] = cpu_to_queue_index(nr_queues, cpu)
 +			else
 +				map[cpu] = map[first_sibling];
  		}
 -
 -		/*
 -		 * Less then nr_cpus queues, and we have some number of
 -		 * threads per cores. Map sibling threads to the same
 -		 * queue.
 -		 */
 -		first_sibling = get_first_sibling(i);
 -		if (first_sibling == i) {
 -			map[i] = cpu_to_queue_index(nr_uniq_cpus, nr_queues,
 -							queue);
 -			queue++;
 -		} else
 -			map[i] = map[first_sibling];
  	}
  
 -	free_cpumask_var(cpus);
  	return 0;
  }
  EXPORT_SYMBOL_GPL(blk_mq_map_queues);

linux-next: manual merge of the tip tree with the block tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/block/mtip32xx/mtip32xx.c between commit b10fd728b985
("mtip32xx: convert to use blk-mq") from the block tree and commit
4e857c58efeb ("arch: Mass conversion of smp_mb__*()") from the tip tree.

I fixed it up (I used the block tree version which removed the code
being updated by the tip tree version) and can carry the fix as
necessary (no action is required).

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

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

Re: linux-next: manual merge of the tip tree with the block tree

[Paul E. McKenney]

On Tue, Jun 22, 2010 at 02:31:21PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in
> fs/fs-writeback.c between commit 79338d2a78ab78efdc1698f1309766a039addf9d
> ("writeback: simplify the write back thread queue") from the block tree
> and commit b97181f24212f4c29197890ce1b2b9100bcc184d ("fs: remove all rcu
> head initializations, except on_stack initializations") from the tip tree.
> 
> This time it is not clear if the RCU updates are needed any more at all,
> so for today I just used the version of fs/fs-writeback.c from the block
> tree.

The current -next tree has gotten rid of all teh RCU_INIT_HEAD, RCU_HEAD,
and INIT_RCU_HEAD calls, as it should.  Woo-hoo!!!  ;-)

							Thanx, Paul

Re: linux-next: manual merge of the tip tree with the block tree

[Paul E. McKenney]

On Tue, Jun 22, 2010 at 08:26:01AM +0200, Jens Axboe wrote:
> On 2010-06-22 02:40, Paul E. McKenney wrote:
> > On Tue, Jun 22, 2010 at 10:04:23AM +1000, Stephen Rothwell wrote:
> >> Hi Paul,
> >>
> >> On Tue, 22 Jun 2010 09:40:33 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>>
> >>> On Mon, 21 Jun 2010 10:13:00 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >>>>
> >>>> I took a look, and all of the changes from "fs: remove all rcu head
> >>>> initializations, except on_stack initializations" are reflected in -next.
> >>>
> >>> Thanks for checking.
> >>
> >> Is there some way that this commit can be merged via the block tree?  Or
> >> does later work in your tree depend on it?  There is considerable and
> >> ongoing work in the block tree on the same areas as your commit changes.
> >> Even today, this conflict is going to be much worse.
> > 
> > I have no problem with this patch being applied via the block tree, as
> > long as it doesn't take too many minor releases for it to hit mainline.  ;-)
> > 
> > How would everyone like to proceed?
> 
> The stuff in the block tree is either destined for the current release
> or the next one, the patches going into for-next are a merge of those
> two parts.
> 
> Is this rcu patch for .35 or .36?

.35 would be good.  ;-)  But I can make .36 work if need be.

Please see below for the patch.  Alternatively, feel free to grab commit
b97181f24212f4c29197890ce1b2b9100bcc184d from -tip or from
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git

							Thanx, Paul

------------------------------------------------------------------------

commit b97181f24212f4c29197890ce1b2b9100bcc184d
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Mon May 10 17:09:25 2010 -0700

    fs: remove all rcu head initializations, except on_stack initializations
    
    Remove all rcu head inits. We don't care about the RCU head state before passing
    it to call_rcu() anyway. Only leave the "on_stack" variants so debugobjects can
    keep track of objects on stack.
    
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Andries Brouwer <aeb@cwi.nl>

diff --git a/fs/file.c b/fs/file.c
index 34bb7f7..cccaead 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -178,7 +178,6 @@ static struct fdtable * alloc_fdtable(unsigned int nr)
 	fdt->open_fds = (fd_set *)data;
 	data += nr / BITS_PER_BYTE;
 	fdt->close_on_exec = (fd_set *)data;
-	INIT_RCU_HEAD(&fdt->rcu);
 	fdt->next = NULL;
 
 	return fdt;
@@ -312,7 +311,6 @@ struct files_struct *dup_fd(struct files_struct *oldf, int *errorp)
 	new_fdt->close_on_exec = (fd_set *)&newf->close_on_exec_init;
 	new_fdt->open_fds = (fd_set *)&newf->open_fds_init;
 	new_fdt->fd = &newf->fd_array[0];
-	INIT_RCU_HEAD(&new_fdt->rcu);
 	new_fdt->next = NULL;
 
 	spin_lock(&oldf->file_lock);
@@ -430,7 +428,6 @@ struct files_struct init_files = {
 		.fd		= &init_files.fd_array[0],
 		.close_on_exec	= (fd_set *)&init_files.close_on_exec_init,
 		.open_fds	= (fd_set *)&init_files.open_fds_init,
-		.rcu		= RCU_HEAD_INIT,
 	},
 	.file_lock	= __SPIN_LOCK_UNLOCKED(init_task.file_lock),
 };
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 1d1088f..af92100 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -75,12 +75,33 @@ static inline bool bdi_work_on_stack(struct bdi_work *work)
 	return test_bit(WS_ONSTACK_B, &work->state);
 }
 
-static inline void bdi_work_init(struct bdi_work *work,
-				 struct wb_writeback_args *args)
+static inline void __bdi_work_init(struct bdi_work *work,
+				   struct wb_writeback_args *args,
+				   int on_stack)
 {
-	INIT_RCU_HEAD(&work->rcu_head);
 	work->args = *args;
 	work->state = WS_USED;
+	if (on_stack) {
+		work->state |= WS_ONSTACK;
+		init_rcu_head_on_stack(&work->rcu_head);
+	}
+}
+
+static inline void bdi_work_init(struct bdi_work *work,
+				 struct wb_writeback_args *args)
+{
+	__bdi_work_init(work, args, false);
+}
+
+static inline void bdi_work_init_on_stack(struct bdi_work *work,
+					  struct wb_writeback_args *args)
+{
+	__bdi_work_init(work, args, true);
+}
+
+static inline void bdi_destroy_work_on_stack(struct bdi_work *work)
+{
+	destroy_rcu_head_on_stack(&work->rcu_head);
 }
 
 /**
@@ -233,11 +254,11 @@ static void bdi_sync_writeback(struct backing_dev_info *bdi,
 	};
 	struct bdi_work work;
 
-	bdi_work_init(&work, &args);
-	work.state |= WS_ONSTACK;
+	bdi_work_init_on_stack(&work, &args);
 
 	bdi_queue_work(bdi, &work);
 	bdi_wait_on_work_clear(&work);
+	bdi_destroy_work_on_stack(&work);
 }
 
 /**
diff --git a/fs/partitions/check.c b/fs/partitions/check.c
index 5dcd4b0..72c5265 100644
--- a/fs/partitions/check.c
+++ b/fs/partitions/check.c
@@ -459,7 +459,6 @@ struct hd_struct *add_partition(struct gendisk *disk, int partno,
 	}
 
 	/* everything is up and running, commence */
-	INIT_RCU_HEAD(&p->rcu_head);
 	rcu_assign_pointer(ptbl->part[partno], p);
 
 	/* suppress uevent if the disk supresses it */

Re: linux-next: manual merge of the tip tree with the block tree

[Jens Axboe]

On 2010-06-22 02:40, Paul E. McKenney wrote:
> On Tue, Jun 22, 2010 at 10:04:23AM +1000, Stephen Rothwell wrote:
>> Hi Paul,
>>
>> On Tue, 22 Jun 2010 09:40:33 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> On Mon, 21 Jun 2010 10:13:00 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>>>>
>>>> I took a look, and all of the changes from "fs: remove all rcu head
>>>> initializations, except on_stack initializations" are reflected in -next.
>>>
>>> Thanks for checking.
>>
>> Is there some way that this commit can be merged via the block tree?  Or
>> does later work in your tree depend on it?  There is considerable and
>> ongoing work in the block tree on the same areas as your commit changes.
>> Even today, this conflict is going to be much worse.
> 
> I have no problem with this patch being applied via the block tree, as
> long as it doesn't take too many minor releases for it to hit mainline.  ;-)
> 
> How would everyone like to proceed?

The stuff in the block tree is either destined for the current release
or the next one, the patches going into for-next are a merge of those
two parts.

Is this rcu patch for .35 or .36?

-- 
Jens Axboe

Re: linux-next: manual merge of the tip tree with the block tree

[Paul E. McKenney]

On Tue, Jun 22, 2010 at 10:04:23AM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Tue, 22 Jun 2010 09:40:33 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Mon, 21 Jun 2010 10:13:00 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > >
> > > I took a look, and all of the changes from "fs: remove all rcu head
> > > initializations, except on_stack initializations" are reflected in -next.
> > 
> > Thanks for checking.
> 
> Is there some way that this commit can be merged via the block tree?  Or
> does later work in your tree depend on it?  There is considerable and
> ongoing work in the block tree on the same areas as your commit changes.
> Even today, this conflict is going to be much worse.

I have no problem with this patch being applied via the block tree, as
long as it doesn't take too many minor releases for it to hit mainline.  ;-)

How would everyone like to proceed?

							Thanx, Paul

Re: linux-next: manual merge of the tip tree with the block tree

[Stephen Rothwell]

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

Hi Paul,

On Tue, 22 Jun 2010 09:40:33 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 21 Jun 2010 10:13:00 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > I took a look, and all of the changes from "fs: remove all rcu head
> > initializations, except on_stack initializations" are reflected in -next.
> 
> Thanks for checking.

Is there some way that this commit can be merged via the block tree?  Or
does later work in your tree depend on it?  There is considerable and
ongoing work in the block tree on the same areas as your commit changes.
Even today, this conflict is going to be much worse.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the tip tree with the block tree

[Stephen Rothwell]

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

Hi Paul,

On Mon, 21 Jun 2010 10:13:00 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> I took a look, and all of the changes from "fs: remove all rcu head
> initializations, except on_stack initializations" are reflected in -next.

Thanks for checking.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the tip tree with the block tree

[Paul E. McKenney]

On Mon, Jun 21, 2010 at 04:16:23PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in
> fs/fs-writeback.c between commits 7f0e7bed936a0c422641a046551829a01341dd80
> ("writeback: fix writeback completion notifications") and
> 3c4d716538f3eefb1c1f10961a047a6456a2b590 ("writeback: queue work on stack
> in writeback_inodes_sb") from the block tree and commit
> b97181f24212f4c29197890ce1b2b9100bcc184d ("fs: remove all rcu head
> initializations, except on_stack initializations") from the tip tree.
> 
> I fixed it up (I hope - see below) and can carry the fix as necessary.

I took a look, and all of the changes from "fs: remove all rcu head
initializations, except on_stack initializations" are reflected in -next.

							Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc fs/fs-writeback.c
> index 5455009,af92100..0000000
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@@ -63,16 -63,45 +63,37 @@@ struct bdi_work 
>   };
>   
>   enum {
>  -	WS_USED_B = 0,
>  -	WS_ONSTACK_B,
>  +	WS_INPROGRESS = 0,
>  +	WS_ONSTACK,
>   };
>   
> - static inline void bdi_work_init(struct bdi_work *work,
> - 				 struct wb_writeback_args *args)
>  -#define WS_USED (1 << WS_USED_B)
>  -#define WS_ONSTACK (1 << WS_ONSTACK_B)
>  -
>  -static inline bool bdi_work_on_stack(struct bdi_work *work)
>  -{
>  -	return test_bit(WS_ONSTACK_B, &work->state);
>  -}
>  -
> + static inline void __bdi_work_init(struct bdi_work *work,
> + 				   struct wb_writeback_args *args,
> + 				   int on_stack)
>   {
> - 	INIT_RCU_HEAD(&work->rcu_head);
>   	work->args = *args;
>  -	work->state = WS_USED;
>  +	__set_bit(WS_INPROGRESS, &work->state);
> + 	if (on_stack) {
>  -		work->state |= WS_ONSTACK;
> ++		__set_bit(WS_ONSTACK, &work->state);
> + 		init_rcu_head_on_stack(&work->rcu_head);
> + 	}
> + }
> + 
> + static inline void bdi_work_init(struct bdi_work *work,
> + 				 struct wb_writeback_args *args)
> + {
> + 	__bdi_work_init(work, args, false);
> + }
> + 
> + static inline void bdi_work_init_on_stack(struct bdi_work *work,
> + 					  struct wb_writeback_args *args)
> + {
> + 	__bdi_work_init(work, args, true);
> + }
> + 
> + static inline void bdi_destroy_work_on_stack(struct bdi_work *work)
> + {
> + 	destroy_rcu_head_on_stack(&work->rcu_head);
>   }
>   
>   /**
> @@@ -182,19 -239,26 +203,19 @@@ static void bdi_alloc_queue_work(struc
>    * @sb: write inodes from this super_block
>    *
>    * Description:
>  - *   This does WB_SYNC_ALL data integrity writeback and waits for the
>  - *   IO to complete. Callers must hold the sb s_umount semaphore for
>  + *   This function initiates writeback and waits for the operation to
>  + *   complete. Callers must hold the sb s_umount semaphore for
>    *   reading, to avoid having the super disappear before we are done.
>    */
>  -static void bdi_sync_writeback(struct backing_dev_info *bdi,
>  -			       struct super_block *sb)
>  +static void bdi_queue_work_onstack(struct wb_writeback_args *args)
>   {
>  -	struct wb_writeback_args args = {
>  -		.sb		= sb,
>  -		.sync_mode	= WB_SYNC_ALL,
>  -		.nr_pages	= LONG_MAX,
>  -		.range_cyclic	= 0,
>  -	};
>   	struct bdi_work work;
>   
> - 	bdi_work_init(&work, args);
> - 	__set_bit(WS_ONSTACK, &work.state);
>  -	bdi_work_init_on_stack(&work, &args);
> ++	bdi_work_init_on_stack(&work, args);
>   
>  -	bdi_queue_work(bdi, &work);
>  -	bdi_wait_on_work_clear(&work);
>  +	bdi_queue_work(args->sb->s_bdi, &work);
>  +	bdi_wait_on_work_done(&work);
> + 	bdi_destroy_work_on_stack(&work);
>   }
>   
>   /**
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the tip tree with the block tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
fs/fs-writeback.c between commits 7f0e7bed936a0c422641a046551829a01341dd80
("writeback: fix writeback completion notifications") and
3c4d716538f3eefb1c1f10961a047a6456a2b590 ("writeback: queue work on stack
in writeback_inodes_sb") from the block tree and commit
b97181f24212f4c29197890ce1b2b9100bcc184d ("fs: remove all rcu head
initializations, except on_stack initializations") from the tip tree.

I fixed it up (I hope - see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/fs-writeback.c
index 5455009,af92100..0000000
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@@ -63,16 -63,45 +63,37 @@@ struct bdi_work 
  };
  
  enum {
 -	WS_USED_B = 0,
 -	WS_ONSTACK_B,
 +	WS_INPROGRESS = 0,
 +	WS_ONSTACK,
  };
  
- static inline void bdi_work_init(struct bdi_work *work,
- 				 struct wb_writeback_args *args)
 -#define WS_USED (1 << WS_USED_B)
 -#define WS_ONSTACK (1 << WS_ONSTACK_B)
 -
 -static inline bool bdi_work_on_stack(struct bdi_work *work)
 -{
 -	return test_bit(WS_ONSTACK_B, &work->state);
 -}
 -
+ static inline void __bdi_work_init(struct bdi_work *work,
+ 				   struct wb_writeback_args *args,
+ 				   int on_stack)
  {
- 	INIT_RCU_HEAD(&work->rcu_head);
  	work->args = *args;
 -	work->state = WS_USED;
 +	__set_bit(WS_INPROGRESS, &work->state);
+ 	if (on_stack) {
 -		work->state |= WS_ONSTACK;
++		__set_bit(WS_ONSTACK, &work->state);
+ 		init_rcu_head_on_stack(&work->rcu_head);
+ 	}
+ }
+ 
+ static inline void bdi_work_init(struct bdi_work *work,
+ 				 struct wb_writeback_args *args)
+ {
+ 	__bdi_work_init(work, args, false);
+ }
+ 
+ static inline void bdi_work_init_on_stack(struct bdi_work *work,
+ 					  struct wb_writeback_args *args)
+ {
+ 	__bdi_work_init(work, args, true);
+ }
+ 
+ static inline void bdi_destroy_work_on_stack(struct bdi_work *work)
+ {
+ 	destroy_rcu_head_on_stack(&work->rcu_head);
  }
  
  /**
@@@ -182,19 -239,26 +203,19 @@@ static void bdi_alloc_queue_work(struc
   * @sb: write inodes from this super_block
   *
   * Description:
 - *   This does WB_SYNC_ALL data integrity writeback and waits for the
 - *   IO to complete. Callers must hold the sb s_umount semaphore for
 + *   This function initiates writeback and waits for the operation to
 + *   complete. Callers must hold the sb s_umount semaphore for
   *   reading, to avoid having the super disappear before we are done.
   */
 -static void bdi_sync_writeback(struct backing_dev_info *bdi,
 -			       struct super_block *sb)
 +static void bdi_queue_work_onstack(struct wb_writeback_args *args)
  {
 -	struct wb_writeback_args args = {
 -		.sb		= sb,
 -		.sync_mode	= WB_SYNC_ALL,
 -		.nr_pages	= LONG_MAX,
 -		.range_cyclic	= 0,
 -	};
  	struct bdi_work work;
  
- 	bdi_work_init(&work, args);
- 	__set_bit(WS_ONSTACK, &work.state);
 -	bdi_work_init_on_stack(&work, &args);
++	bdi_work_init_on_stack(&work, args);
  
 -	bdi_queue_work(bdi, &work);
 -	bdi_wait_on_work_clear(&work);
 +	bdi_queue_work(args->sb->s_bdi, &work);
 +	bdi_wait_on_work_done(&work);
+ 	bdi_destroy_work_on_stack(&work);
  }
  
  /**