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

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

[Stephen Rothwell]

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

Hi Josh,

Today's linux-next merge of the tiny tree got conflicts in
arch/x86/kernel/process_32.c and arch/x86/kernel/process_64.c between
commits dc56c0f9b870 ("x86, fpu: Shift "fpu_counter = 0" from
copy_thread() to arch_dup_task_struct()") and 6f46b3aef003 ("x86:
copy_thread: Don't nullify ->ptrace_bps twice") from the tip tree and
commits a1cf09f93e66 ("x86: process: Unify 32-bit and 64-bit
copy_thread I/O bitmap handling") and e4a191d1e05b ("x86: Support
compiling out userspace I/O (iopl and ioperm)") from the tiny 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 arch/x86/kernel/process_32.c
index 8f3ebfe710d0,e37f006fda6e..000000000000
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@@ -153,7 -153,9 +154,7 @@@ int copy_thread(unsigned long clone_fla
  		childregs->orig_ax = -1;
  		childregs->cs = __KERNEL_CS | get_kernel_rpl();
  		childregs->flags = X86_EFLAGS_IF | X86_EFLAGS_FIXED;
- 		p->thread.io_bitmap_ptr = NULL;
 -		p->thread.fpu_counter = 0;
+ 		clear_thread_io_bitmap(p);
 -		memset(p->thread.ptrace_bps, 0, sizeof(p->thread.ptrace_bps));
  		return 0;
  	}
  	*childregs = *current_pt_regs();
@@@ -164,22 -166,12 +165,9 @@@
  	p->thread.ip = (unsigned long) ret_from_fork;
  	task_user_gs(p) = get_user_gs(current_pt_regs());
  
- 	p->thread.io_bitmap_ptr = NULL;
 -	p->thread.fpu_counter = 0;
+ 	clear_thread_io_bitmap(p);
  	tsk = current;
- 	err = -ENOMEM;
- 
- 	if (unlikely(test_tsk_thread_flag(tsk, TIF_IO_BITMAP))) {
- 		p->thread.io_bitmap_ptr = kmemdup(tsk->thread.io_bitmap_ptr,
- 						IO_BITMAP_BYTES, GFP_KERNEL);
- 		if (!p->thread.io_bitmap_ptr) {
- 			p->thread.io_bitmap_max = 0;
- 			return -ENOMEM;
- 		}
- 		set_tsk_thread_flag(p, TIF_IO_BITMAP);
- 	}
- 
- 	err = 0;
  
 -	memset(p->thread.ptrace_bps, 0, sizeof(p->thread.ptrace_bps));
 -
  	/*
  	 * Set a new TLS for the child thread?
  	 */
diff --cc arch/x86/kernel/process_64.c
index 3ed4a68d4013,80f348659edd..000000000000
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@@ -163,7 -164,8 +164,7 @@@ int copy_thread(unsigned long clone_fla
  	p->thread.sp = (unsigned long) childregs;
  	p->thread.usersp = me->thread.usersp;
  	set_tsk_thread_flag(p, TIF_FORK);
- 	p->thread.io_bitmap_ptr = NULL;
 -	p->thread.fpu_counter = 0;
+ 	clear_thread_io_bitmap(p);
  
  	savesegment(gs, p->thread.gsindex);
  	p->thread.gs = p->thread.gsindex ? 0 : me->thread.gs;
@@@ -191,17 -193,8 +192,6 @@@
  	if (sp)
  		childregs->sp = sp;
  
- 	err = -ENOMEM;
- 	if (unlikely(test_tsk_thread_flag(me, TIF_IO_BITMAP))) {
- 		p->thread.io_bitmap_ptr = kmemdup(me->thread.io_bitmap_ptr,
- 						  IO_BITMAP_BYTES, GFP_KERNEL);
- 		if (!p->thread.io_bitmap_ptr) {
- 			p->thread.io_bitmap_max = 0;
- 			return -ENOMEM;
- 		}
- 		set_tsk_thread_flag(p, TIF_IO_BITMAP);
- 	}
 -	memset(p->thread.ptrace_bps, 0, sizeof(p->thread.ptrace_bps));
--
  	/*
  	 * Set a new TLS for the child thread?
  	 */

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

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

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Josh,
> 
> Today's linux-next merge of the tiny tree got conflicts in
> arch/x86/kernel/process_32.c and arch/x86/kernel/process_64.c between
> commits dc56c0f9b870 ("x86, fpu: Shift "fpu_counter = 0" from
> copy_thread() to arch_dup_task_struct()") and 6f46b3aef003 ("x86:
> copy_thread: Don't nullify ->ptrace_bps twice") from the tip tree and
> commits a1cf09f93e66 ("x86: process: Unify 32-bit and 64-bit
> copy_thread I/O bitmap handling") and e4a191d1e05b ("x86: Support
> compiling out userspace I/O (iopl and ioperm)") from the tiny tree.

Why are such changes in the 'tiny' tree? These are sensitive 
arch/x86 files, and any unification and compilation-out support 
patches need to go through the proper review channels and be 
merged upstream via the x86 tree if accepted...

In particular the graticious sprinking of #ifdef 
CONFIG_X86_IOPORTs around x86 code looks ugly.

Josh, don't do that, this route is really unacceptable. Please 
resubmit the latest patches and remove these from linux-next.

Thanks,

	Ingo

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

[Josh Triplett]

On Tue, Sep 23, 2014 at 07:43:28AM +0200, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Today's linux-next merge of the tiny tree got conflicts in
> > arch/x86/kernel/process_32.c and arch/x86/kernel/process_64.c between
> > commits dc56c0f9b870 ("x86, fpu: Shift "fpu_counter = 0" from
> > copy_thread() to arch_dup_task_struct()") and 6f46b3aef003 ("x86:
> > copy_thread: Don't nullify ->ptrace_bps twice") from the tip tree and
> > commits a1cf09f93e66 ("x86: process: Unify 32-bit and 64-bit
> > copy_thread I/O bitmap handling") and e4a191d1e05b ("x86: Support
> > compiling out userspace I/O (iopl and ioperm)") from the tiny tree.
> 
> Why are such changes in the 'tiny' tree? These are sensitive 
> arch/x86 files, and any unification and compilation-out support 
> patches need to go through the proper review channels and be 
> merged upstream via the x86 tree if accepted...
> 
> In particular the graticious sprinking of #ifdef 
> CONFIG_X86_IOPORTs around x86 code looks ugly.
> 
> Josh, don't do that, this route is really unacceptable. Please 
> resubmit the latest patches and remove these from linux-next.

I'd previously submitted these patches for review; the last round of
feedback seemed entirely positive (with some explicit acks) on the 32/64
unification patches, and generally positive on the last patch of the
series (apart from a misunderstanding about this being configurable but
still default y).  I CCed you on that submission, and hadn't seen any of
this feedback from you at that time (nor a suggestion of which tree this
should go through).  My intention with adding these patches to tiny/next
tree was purely for an integration check with -next, and I'd planned to
resend these by email shortly for an additional round of review with an
explicit question of what route they should take into the kernel.

I've dropped tiny/no-io from tiny/next; I'll poke at it further and
resubmit for the x86 tree later, likely not for the next merge window at
this point.

Thanks for the feedback on process; this is day 1 of having a
merge-window-bound tree in -next for the first time. :)

- Josh Triplett

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

[Ingo Molnar]

* Josh Triplett <josh@joshtriplett.org> wrote:

> On Tue, Sep 23, 2014 at 07:43:28AM +0200, Ingo Molnar wrote:
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > Today's linux-next merge of the tiny tree got conflicts in
> > > arch/x86/kernel/process_32.c and arch/x86/kernel/process_64.c between
> > > commits dc56c0f9b870 ("x86, fpu: Shift "fpu_counter = 0" from
> > > copy_thread() to arch_dup_task_struct()") and 6f46b3aef003 ("x86:
> > > copy_thread: Don't nullify ->ptrace_bps twice") from the tip tree and
> > > commits a1cf09f93e66 ("x86: process: Unify 32-bit and 64-bit
> > > copy_thread I/O bitmap handling") and e4a191d1e05b ("x86: Support
> > > compiling out userspace I/O (iopl and ioperm)") from the tiny tree.
> > 
> > Why are such changes in the 'tiny' tree? These are sensitive 
> > arch/x86 files, and any unification and compilation-out support 
> > patches need to go through the proper review channels and be 
> > merged upstream via the x86 tree if accepted...
> > 
> > In particular the graticious sprinking of #ifdef 
> > CONFIG_X86_IOPORTs around x86 code looks ugly.
> > 
> > Josh, don't do that, this route is really unacceptable. Please 
> > resubmit the latest patches and remove these from linux-next.
> 
> I'd previously submitted these patches for review; the last 
> round of feedback seemed entirely positive (with some explicit 
> acks) on the 32/64 unification patches, and generally positive 
> on the last patch of the series (apart from a misunderstanding 
> about this being configurable but still default y).  I CCed you 
> on that submission, and hadn't seen any of this feedback from 
> you at that time (nor a suggestion of which tree this should go 
> through).  My intention with adding these patches to tiny/next 
> tree was purely for an integration check with -next, and I'd 
> planned to resend these by email shortly for an additional 
> round of review with an explicit question of what route they 
> should take into the kernel.

That's perfectly fine, thanks!

> I've dropped tiny/no-io from tiny/next; I'll poke at it further 
> and resubmit for the x86 tree later, likely not for the next 
> merge window at this point.
> 
> Thanks for the feedback on process; this is day 1 of having a 
> merge-window-bound tree in -next for the first time. :)

Sorry about the harshness of my initial email - I was unsure 
about the background and we are close to the merge window. I have 
no objections against the -tiny tree in linux-next, it's a good 
effort.

I think we could cut down on the #ifdef uglies if we made the 
ioperm callback pointer unconditional. That's just a tiny amount 
of extra bloat, but should remove half of the #ifdefs or so? The 
rest of the patches look fine.

Usually hpa handles the x86 ioperm area, but he's swamped right 
now, so I'll look at picking them up once you have submitted the 
latest version. If you send it in the next day or two then they 
could make the v3.18 merge window.

Thanks,

	Ingo

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

[Josh Triplett]

On Tue, Sep 23, 2014 at 10:36:03AM +0200, Ingo Molnar wrote:
> * Josh Triplett <josh@joshtriplett.org> wrote:
> > I've dropped tiny/no-io from tiny/next; I'll poke at it further 
> > and resubmit for the x86 tree later, likely not for the next 
> > merge window at this point.
> > 
> > Thanks for the feedback on process; this is day 1 of having a 
> > merge-window-bound tree in -next for the first time. :)
> 
> Sorry about the harshness of my initial email - I was unsure 
> about the background and we are close to the merge window. I have 
> no objections against the -tiny tree in linux-next, it's a good 
> effort.
> 
> I think we could cut down on the #ifdef uglies if we made the 
> ioperm callback pointer unconditional. That's just a tiny amount 
> of extra bloat, but should remove half of the #ifdefs or so? The 
> rest of the patches look fine.

I've revised the patch to eliminate quite a few #ifdefs, and in
particular almost all of those in .c files, by adding a macro
INIT_SET_IOPL_MASK to use in place of the initializer for set_iopl_mask,
and using __maybe_unused rather than wrapping function definitions in
#ifdef.  I'll send a new version momentarily.

> Usually hpa handles the x86 ioperm area, but he's swamped right 
> now, so I'll look at picking them up once you have submitted the 
> latest version. If you send it in the next day or two then they 
> could make the v3.18 merge window.

Other things came up (LinuxCon / Plumbers), but hopefully the new
version can go into 3.19.

- Josh Triplett

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

[Stephen Rothwell]

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

Hi Josh,

Today's linux-next merge of the tiny tree got a conflict in
kernel/time/Makefile between commit fd866e2b116b ("time: Rename
udelay_test.c to test_udelay.c") from the tip tree and commit
d1f6d68d03ea ("kernel: time: Compile out NTP support") from the tiny
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/time/Makefile
index f622cf28628a,d07d4c9207b9..000000000000
--- a/kernel/time/Makefile
+++ b/kernel/time/Makefile
@@@ -13,7 -13,8 +13,8 @@@ obj-$(CONFIG_TICK_ONESHOT)			+= tick-on
  obj-$(CONFIG_TICK_ONESHOT)			+= tick-sched.o
  obj-$(CONFIG_TIMER_STATS)			+= timer_stats.o
  obj-$(CONFIG_DEBUG_FS)				+= timekeeping_debug.o
 -obj-$(CONFIG_TEST_UDELAY)			+= udelay_test.o
 +obj-$(CONFIG_TEST_UDELAY)			+= test_udelay.o
+ obj-$(CONFIG_NTP)				+= ntp.o
  
  $(obj)/time.o: $(obj)/timeconst.h
  

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

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

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Josh,
> 
> Today's linux-next merge of the tiny tree got a conflict in
> kernel/time/Makefile between commit fd866e2b116b ("time: Rename
> udelay_test.c to test_udelay.c") from the tip tree and commit
> d1f6d68d03ea ("kernel: time: Compile out NTP support") from the tiny
> tree.

So I think a timer subsystem commit d1f6d68d03ea with this 
magnitude of linecount increase:

 Signed-off-by: Catalina Mocanu <catalina.mocanu@gmail.com>
 [josh: Handle CONFIG_COMPAT=y.]
 Reviewed-by: Josh Triplett <josh@joshtriplett.org>
 Signed-off-by: Josh Triplett <josh@joshtriplett.org>
 ---
  drivers/pps/Kconfig        |  2 +-
  include/linux/timex.h      | 15 +++++++++++++--
  init/Kconfig               | 10 ++++++++++
  kernel/compat.c            |  8 ++++++--
  kernel/sys_ni.c            |  4 ++++
  kernel/time/Makefile       |  3 ++-
  kernel/time/ntp_internal.h | 28 ++++++++++++++++++++++++++++
  kernel/time/posix-timers.c |  2 ++
  kernel/time/time.c         |  2 ++
  kernel/time/timekeeping.c  |  2 ++
  10 files changed, 70 insertions(+), 6 deletions(-)

at minimum needs the ack of timer folks, before it can be 
committed to Git. Or is the tiny tree plan to submit all
patches to the appropriate subsystem or gather acks, before 
sending it upstream?

Thanks,

	Ingo

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

[John Stultz]

On Mon, Nov 24, 2014 at 10:16 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi Josh,
>>
>> Today's linux-next merge of the tiny tree got a conflict in
>> kernel/time/Makefile between commit fd866e2b116b ("time: Rename
>> udelay_test.c to test_udelay.c") from the tip tree and commit
>> d1f6d68d03ea ("kernel: time: Compile out NTP support") from the tiny
>> tree.
>
> So I think a timer subsystem commit d1f6d68d03ea with this
> magnitude of linecount increase:
>
>  Signed-off-by: Catalina Mocanu <catalina.mocanu@gmail.com>
>  [josh: Handle CONFIG_COMPAT=y.]
>  Reviewed-by: Josh Triplett <josh@joshtriplett.org>
>  Signed-off-by: Josh Triplett <josh@joshtriplett.org>
>  ---
>   drivers/pps/Kconfig        |  2 +-
>   include/linux/timex.h      | 15 +++++++++++++--
>   init/Kconfig               | 10 ++++++++++
>   kernel/compat.c            |  8 ++++++--
>   kernel/sys_ni.c            |  4 ++++
>   kernel/time/Makefile       |  3 ++-
>   kernel/time/ntp_internal.h | 28 ++++++++++++++++++++++++++++
>   kernel/time/posix-timers.c |  2 ++
>   kernel/time/time.c         |  2 ++
>   kernel/time/timekeeping.c  |  2 ++
>   10 files changed, 70 insertions(+), 6 deletions(-)
>
> at minimum needs the ack of timer folks, before it can be
> committed to Git. Or is the tiny tree plan to submit all
> patches to the appropriate subsystem or gather acks, before
> sending it upstream?

Yea.  From first glance d1f6d68d03ea looks fairly broken.

Returning 0 for ntp_tick_length() (which should be the current tick
length in NTP_SCALE_SHIFT shifted ns), seems like it would cause major
timekeeping problems.

thanks
-john

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

[Josh Triplett]

On Mon, Nov 24, 2014 at 10:30:10PM -0800, John Stultz wrote:
> On Mon, Nov 24, 2014 at 10:16 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >> Hi Josh,
> >>
> >> Today's linux-next merge of the tiny tree got a conflict in
> >> kernel/time/Makefile between commit fd866e2b116b ("time: Rename
> >> udelay_test.c to test_udelay.c") from the tip tree and commit
> >> d1f6d68d03ea ("kernel: time: Compile out NTP support") from the tiny
> >> tree.
> >
> > So I think a timer subsystem commit d1f6d68d03ea with this
> > magnitude of linecount increase:
> >
> >  Signed-off-by: Catalina Mocanu <catalina.mocanu@gmail.com>
> >  [josh: Handle CONFIG_COMPAT=y.]
> >  Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> >  Signed-off-by: Josh Triplett <josh@joshtriplett.org>
> >  ---
> >   drivers/pps/Kconfig        |  2 +-
> >   include/linux/timex.h      | 15 +++++++++++++--
> >   init/Kconfig               | 10 ++++++++++
> >   kernel/compat.c            |  8 ++++++--
> >   kernel/sys_ni.c            |  4 ++++
> >   kernel/time/Makefile       |  3 ++-
> >   kernel/time/ntp_internal.h | 28 ++++++++++++++++++++++++++++
> >   kernel/time/posix-timers.c |  2 ++
> >   kernel/time/time.c         |  2 ++
> >   kernel/time/timekeeping.c  |  2 ++
> >   10 files changed, 70 insertions(+), 6 deletions(-)
> >
> > at minimum needs the ack of timer folks, before it can be
> > committed to Git. Or is the tiny tree plan to submit all
> > patches to the appropriate subsystem or gather acks, before
> > sending it upstream?
> 
> Yea.  From first glance d1f6d68d03ea looks fairly broken.
> 
> Returning 0 for ntp_tick_length() (which should be the current tick
> length in NTP_SCALE_SHIFT shifted ns), seems like it would cause major
> timekeeping problems.

Ouch, yeah; I'm impressed the kernel successfully booted that way (which
I did test).

Computing the tick_length to return seems to require a div_u64; is it
safe to initialize a static const with the result of calling div_u64, or
does the intializer need manual constant-folding to make the expression
compile-time computable?

Going by the logic in ntp_update_frequency, it looks like the stub
ntp_tick_length needs to return:

tick_length_base = 0;
tick_usec = TICK_USEC;
second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ) << NTP_SCALE_SHIFT;
new_base = div_u64(second_length, NTP_INTERVAL_FREQ);
tick_length += new_base - tick_length_base;

(tick_length starts out 0, gets new_base - 0 added initially, and every
subsequent time gets 0 added since tick_length_base won't change.)

Substituting and simplifying:

tick_length = new_base
            = div_u64(second_length, NTP_INTERVAL_FREQ)
            = div_u64((TICK_USEC * NSEC_PER_USEC * USER_HZ) << NTP_SCALE_SHIFT, NTP_INTERVAL_FREQ)

The numerator there could potentially be simplified, but I don't see an
obvious way around the division by NTP_INTERVAL_FREQ (defined as HZ).

- Josh Triplett

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

[Josh Triplett]

On Tue, Nov 25, 2014 at 07:16:45AM +0100, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Josh,
> > 
> > Today's linux-next merge of the tiny tree got a conflict in
> > kernel/time/Makefile between commit fd866e2b116b ("time: Rename
> > udelay_test.c to test_udelay.c") from the tip tree and commit
> > d1f6d68d03ea ("kernel: time: Compile out NTP support") from the tiny
> > tree.
> 
> So I think a timer subsystem commit d1f6d68d03ea with this 
> magnitude of linecount increase:
> 
>  Signed-off-by: Catalina Mocanu <catalina.mocanu@gmail.com>
>  [josh: Handle CONFIG_COMPAT=y.]
>  Reviewed-by: Josh Triplett <josh@joshtriplett.org>
>  Signed-off-by: Josh Triplett <josh@joshtriplett.org>
>  ---
>   drivers/pps/Kconfig        |  2 +-
>   include/linux/timex.h      | 15 +++++++++++++--
>   init/Kconfig               | 10 ++++++++++
>   kernel/compat.c            |  8 ++++++--
>   kernel/sys_ni.c            |  4 ++++
>   kernel/time/Makefile       |  3 ++-
>   kernel/time/ntp_internal.h | 28 ++++++++++++++++++++++++++++
>   kernel/time/posix-timers.c |  2 ++
>   kernel/time/time.c         |  2 ++
>   kernel/time/timekeeping.c  |  2 ++
>   10 files changed, 70 insertions(+), 6 deletions(-)
> 
> at minimum needs the ack of timer folks, before it can be 
> committed to Git. Or is the tiny tree plan to submit all
> patches to the appropriate subsystem or gather acks, before 
> sending it upstream?

Yes, absolutely.  I planned to send out a tinification patch review
series later this week with all 10 current patches (both those reviewed
on LKML and those only reviewed elsewhere).

- Josh Triplett

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

[Ingo Molnar]

* Josh Triplett <josh@joshtriplett.org> wrote:

> On Tue, Nov 25, 2014 at 07:16:45AM +0100, Ingo Molnar wrote:
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > Hi Josh,
> > > 
> > > Today's linux-next merge of the tiny tree got a conflict in
> > > kernel/time/Makefile between commit fd866e2b116b ("time: Rename
> > > udelay_test.c to test_udelay.c") from the tip tree and commit
> > > d1f6d68d03ea ("kernel: time: Compile out NTP support") from the tiny
> > > tree.
> > 
> > So I think a timer subsystem commit d1f6d68d03ea with this 
> > magnitude of linecount increase:
> > 
> >  Signed-off-by: Catalina Mocanu <catalina.mocanu@gmail.com>
> >  [josh: Handle CONFIG_COMPAT=y.]
> >  Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> >  Signed-off-by: Josh Triplett <josh@joshtriplett.org>
> >  ---
> >   drivers/pps/Kconfig        |  2 +-
> >   include/linux/timex.h      | 15 +++++++++++++--
> >   init/Kconfig               | 10 ++++++++++
> >   kernel/compat.c            |  8 ++++++--
> >   kernel/sys_ni.c            |  4 ++++
> >   kernel/time/Makefile       |  3 ++-
> >   kernel/time/ntp_internal.h | 28 ++++++++++++++++++++++++++++
> >   kernel/time/posix-timers.c |  2 ++
> >   kernel/time/time.c         |  2 ++
> >   kernel/time/timekeeping.c  |  2 ++
> >   10 files changed, 70 insertions(+), 6 deletions(-)
> > 
> > at minimum needs the ack of timer folks, before it can be 
> > committed to Git. Or is the tiny tree plan to submit all
> > patches to the appropriate subsystem or gather acks, before 
> > sending it upstream?
> 
> Yes, absolutely.  I planned to send out a tinification patch 
> review series later this week with all 10 current patches (both 
> those reviewed on LKML and those only reviewed elsewhere).

But, but: _please_ don't push patches towards linux-next that 
haven't been acked by maintainers.

The point of linux-next is to expose subsystem trees that are 
likely to go upstream in the next release - generally because the 
maintainers themselves push it out, but sometimes also when 
there's acked patches (or features) from maintainers that get 
collected in other trees by developers (such as yours).

But unacked patches with clear problems, causing conflicts, is 
outside that scope. If you want coverage testing you can push it 
out to korg into your own tree, then Fengguang Wu's robot will 
pick it up and report problems with it.

In other words: pushing linux-tiny to linux-next is fine, but 
only for patches that got acked by maintainers and is lined up 
for the next release. For 'work in progress' patches, other 
venues such as korg should be used.

Thanks,

	Ingo

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

[josh]

On Tue, Nov 25, 2014 at 11:10:44AM +0100, Ingo Molnar wrote:
> * Josh Triplett <josh@joshtriplett.org> wrote:
> > On Tue, Nov 25, 2014 at 07:16:45AM +0100, Ingo Molnar wrote:
> > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > Hi Josh,
> > > > 
> > > > Today's linux-next merge of the tiny tree got a conflict in
> > > > kernel/time/Makefile between commit fd866e2b116b ("time: Rename
> > > > udelay_test.c to test_udelay.c") from the tip tree and commit
> > > > d1f6d68d03ea ("kernel: time: Compile out NTP support") from the tiny
> > > > tree.
> > > 
> > > So I think a timer subsystem commit d1f6d68d03ea with this 
> > > magnitude of linecount increase:
> > > 
> > >  Signed-off-by: Catalina Mocanu <catalina.mocanu@gmail.com>
> > >  [josh: Handle CONFIG_COMPAT=y.]
> > >  Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> > >  Signed-off-by: Josh Triplett <josh@joshtriplett.org>
> > >  ---
> > >   drivers/pps/Kconfig        |  2 +-
> > >   include/linux/timex.h      | 15 +++++++++++++--
> > >   init/Kconfig               | 10 ++++++++++
> > >   kernel/compat.c            |  8 ++++++--
> > >   kernel/sys_ni.c            |  4 ++++
> > >   kernel/time/Makefile       |  3 ++-
> > >   kernel/time/ntp_internal.h | 28 ++++++++++++++++++++++++++++
> > >   kernel/time/posix-timers.c |  2 ++
> > >   kernel/time/time.c         |  2 ++
> > >   kernel/time/timekeeping.c  |  2 ++
> > >   10 files changed, 70 insertions(+), 6 deletions(-)
> > > 
> > > at minimum needs the ack of timer folks, before it can be 
> > > committed to Git. Or is the tiny tree plan to submit all
> > > patches to the appropriate subsystem or gather acks, before 
> > > sending it upstream?
> > 
> > Yes, absolutely.  I planned to send out a tinification patch 
> > review series later this week with all 10 current patches (both 
> > those reviewed on LKML and those only reviewed elsewhere).
> 
> But, but: _please_ don't push patches towards linux-next that 
> haven't been acked by maintainers.
[...snip clear explanation of linux-next...]

Thanks for the clarification, Ingo!  Mind if I use your explanation as
the basis for additional documentation of linux-next?

I've moved the tiny/next branch of my tree to tiny/work, and I'll make
sure that tiny/next only gets patches that have gotten all the necessary
reviews.

- Josh Triplett

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

[Ingo Molnar]

* josh@joshtriplett.org <josh@joshtriplett.org> wrote:

> On Tue, Nov 25, 2014 at 11:10:44AM +0100, Ingo Molnar wrote:
> > * Josh Triplett <josh@joshtriplett.org> wrote:
> > > On Tue, Nov 25, 2014 at 07:16:45AM +0100, Ingo Molnar wrote:
> > > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > Hi Josh,
> > > > > 
> > > > > Today's linux-next merge of the tiny tree got a conflict in
> > > > > kernel/time/Makefile between commit fd866e2b116b ("time: Rename
> > > > > udelay_test.c to test_udelay.c") from the tip tree and commit
> > > > > d1f6d68d03ea ("kernel: time: Compile out NTP support") from the tiny
> > > > > tree.
> > > > 
> > > > So I think a timer subsystem commit d1f6d68d03ea with this 
> > > > magnitude of linecount increase:
> > > > 
> > > >  Signed-off-by: Catalina Mocanu <catalina.mocanu@gmail.com>
> > > >  [josh: Handle CONFIG_COMPAT=y.]
> > > >  Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> > > >  Signed-off-by: Josh Triplett <josh@joshtriplett.org>
> > > >  ---
> > > >   drivers/pps/Kconfig        |  2 +-
> > > >   include/linux/timex.h      | 15 +++++++++++++--
> > > >   init/Kconfig               | 10 ++++++++++
> > > >   kernel/compat.c            |  8 ++++++--
> > > >   kernel/sys_ni.c            |  4 ++++
> > > >   kernel/time/Makefile       |  3 ++-
> > > >   kernel/time/ntp_internal.h | 28 ++++++++++++++++++++++++++++
> > > >   kernel/time/posix-timers.c |  2 ++
> > > >   kernel/time/time.c         |  2 ++
> > > >   kernel/time/timekeeping.c  |  2 ++
> > > >   10 files changed, 70 insertions(+), 6 deletions(-)
> > > > 
> > > > at minimum needs the ack of timer folks, before it can be 
> > > > committed to Git. Or is the tiny tree plan to submit all
> > > > patches to the appropriate subsystem or gather acks, before 
> > > > sending it upstream?
> > > 
> > > Yes, absolutely.  I planned to send out a tinification patch 
> > > review series later this week with all 10 current patches (both 
> > > those reviewed on LKML and those only reviewed elsewhere).
> > 
> > But, but: _please_ don't push patches towards linux-next that 
> > haven't been acked by maintainers.
> [...snip clear explanation of linux-next...]
> 
> Thanks for the clarification, Ingo!  Mind if I use your explanation as
> the basis for additional documentation of linux-next?

Sure, feel free!

> I've moved the tiny/next branch of my tree to tiny/work, and 
> I'll make sure that tiny/next only gets patches that have 
> gotten all the necessary reviews.

That looks perfect.

Thanks,

	Ingo

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

[Stephen Rothwell]

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

Hi Josh,

Today's linux-next merge of the tiny tree got a conflict in
arch/x86/boot/compressed/Makefile between commit 84be880560fb ("Revert
"efi/x86: efistub: Move shared dependencies to <asm/efi.h>"") from the
tip tree and commit 9a1cb47112ef ("x86, boot: Use the usual -y -n
mechanism for objects in vmlinux") from the tiny 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 arch/x86/boot/compressed/Makefile
index 0fcd9133790c,20db5b3609de..000000000000
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@@ -32,11 -35,10 +35,9 @@@ vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) +
  
  $(obj)/eboot.o: KBUILD_CFLAGS += -fshort-wchar -mno-red-zone
  
- ifeq ($(CONFIG_EFI_STUB), y)
- 	VMLINUX_OBJS += $(obj)/eboot.o $(obj)/efi_stub_$(BITS).o
- endif
 -vmlinux-objs-$(CONFIG_EFI_STUB) += $(obj)/eboot.o $(obj)/efi_stub_$(BITS).o \
 -	$(objtree)/drivers/firmware/efi/libstub/lib.a
++vmlinux-objs-$(CONFIG_EFI_STUB) += $(obj)/eboot.o $(obj)/efi_stub_$(BITS).o
  
- $(obj)/vmlinux: $(VMLINUX_OBJS) FORCE
+ $(obj)/vmlinux: $(vmlinux-objs-y) FORCE
  	$(call if_changed,ld)
  	@:
  

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

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

[Stephen Rothwell]

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

Hi Josh,

Today's linux-next merge of the tiny tree got a conflict in
arch/x86/kernel/cpu/common.c between commit ce4b1b16502b ("x86/smpboot:
Initialize secondary CPU only if master CPU will wait for it") from the
tip tree and commit e4a191d1e05b ("x86: Support compiling out userspace
I/O (iopl and ioperm)") from the tiny 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 arch/x86/kernel/cpu/common.c
index 3d05d4699dbd,11e08cefdb6e..000000000000
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@@ -1294,10 -1281,7 +1294,9 @@@ void cpu_init(void
  	struct task_struct *me;
  	struct tss_struct *t;
  	unsigned long v;
 -	int cpu;
 +	int cpu = stack_smp_processor_id();
- 	int i;
 +
 +	wait_for_master_cpu(cpu);
  
  	/*
  	 * Load microcode on this cpu if a valid microcode is available.

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