Re: linux-next: manual merge of the tiny tree with the tip tree
* j...@joshtriplett.org wrote:
> On Tue, Nov 25, 2014 at 11:10:44AM +0100, Ingo Molnar wrote:
> > * Josh Triplett wrote:
> > > On Tue, Nov 25, 2014 at 07:16:45AM +0100, Ingo Molnar wrote:
> > > > * Stephen Rothwell 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
> > > > [josh: Handle CONFIG_COMPAT=y.]
> > > > Reviewed-by: Josh Triplett
> > > > Signed-off-by: Josh Triplett
> > > > ---
> > > > 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
--
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 tiny tree with the tip tree
On Tue, Nov 25, 2014 at 11:10:44AM +0100, Ingo Molnar wrote:
> * Josh Triplett wrote:
> > On Tue, Nov 25, 2014 at 07:16:45AM +0100, Ingo Molnar wrote:
> > > * Stephen Rothwell 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
> > > [josh: Handle CONFIG_COMPAT=y.]
> > > Reviewed-by: Josh Triplett
> > > Signed-off-by: Josh Triplett
> > > ---
> > > 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
--
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 tiny tree with the tip tree
* Josh Triplett wrote:
> On Tue, Nov 25, 2014 at 07:16:45AM +0100, Ingo Molnar wrote:
> > * Stephen Rothwell 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
> > [josh: Handle CONFIG_COMPAT=y.]
> > Reviewed-by: Josh Triplett
> > Signed-off-by: Josh Triplett
> > ---
> > 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
--
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 tiny tree with the tip tree
On Mon, Nov 24, 2014 at 10:30:10PM -0800, John Stultz wrote:
> On Mon, Nov 24, 2014 at 10:16 PM, Ingo Molnar wrote:
> >
> > * Stephen Rothwell 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
> > [josh: Handle CONFIG_COMPAT=y.]
> > Reviewed-by: Josh Triplett
> > Signed-off-by: Josh Triplett
> > ---
> > 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
--
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 tiny tree with the tip tree
On Tue, Nov 25, 2014 at 07:16:45AM +0100, Ingo Molnar wrote:
> * Stephen Rothwell 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
> [josh: Handle CONFIG_COMPAT=y.]
> Reviewed-by: Josh Triplett
> Signed-off-by: Josh Triplett
> ---
> 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
--
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 tiny tree with the tip tree
On Mon, Nov 24, 2014 at 10:16 PM, Ingo Molnar wrote:
>
> * Stephen Rothwell 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
> [josh: Handle CONFIG_COMPAT=y.]
> Reviewed-by: Josh Triplett
> Signed-off-by: Josh Triplett
> ---
> 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
--
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 tiny tree with the tip tree
* Stephen Rothwell 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
[josh: Handle CONFIG_COMPAT=y.]
Reviewed-by: Josh Triplett
Signed-off-by: Josh Triplett
---
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
--
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/
linux-next: manual merge of the tiny tree with the tip tree
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 Rothwells...@canb.auug.org.au
diff --cc kernel/time/Makefile
index f622cf28628a,d07d4c9207b9..
--- 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
pgp0IVsb_DjQW.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the tiny tree with the tip tree
On Tue, Sep 23, 2014 at 10:36:03AM +0200, Ingo Molnar wrote: > * Josh Triplett 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 -- 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/
linux-next: manual merge of the tiny tree with the tip tree
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 "") 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 Rothwells...@canb.auug.org.au
diff --cc arch/x86/boot/compressed/Makefile
index 0fcd9133790c,20db5b3609de..
--- 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)
@:
signature.asc
Description: PGP signature
Re: linux-next: manual merge of the tiny tree with the tip tree
* Josh Triplett wrote:
> On Tue, Sep 23, 2014 at 07:43:28AM +0200, Ingo Molnar wrote:
> > * Stephen Rothwell 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
--
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 tiny tree with the tip tree
On Tue, Sep 23, 2014 at 07:43:28AM +0200, Ingo Molnar wrote:
> * Stephen Rothwell 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
--
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 tiny tree with the tip tree
* Stephen Rothwell 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
--
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/
linux-next: manual merge of the tiny tree with the tip tree
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 Rothwells...@canb.auug.org.au
diff --cc arch/x86/kernel/process_32.c
index 8f3ebfe710d0,e37f006fda6e..
--- 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..
--- 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?
*/
signature.asc
Description: PGP signature
linux-next: manual merge of the tiny tree with the tip tree
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 Rothwells...@canb.auug.org.au
diff --cc arch/x86/kernel/cpu/common.c
index 3d05d4699dbd,11e08cefdb6e..
--- 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.
signature.asc
Description: PGP signature
