linux-next: manual merge of the luto-misc tree with the tip tree

linux-next: manual merge of the luto-misc tree with the tip tree

[Stephen Rothwell]

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

Hi Andy,

Today's linux-next merge of the luto-misc tree got a conflict in
arch/x86/kernel/cpu/mcheck/mce.c between commit 83737691e586 ("x86,
mce: Fix sparse errors") from the tip tree and commit d4812e169de4
("x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks") from
the luto-misc tree.

I fixed it up (the latter removed some of the code changed by the
former) and can carry the fix as necessary (no action is required).

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

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

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

[Borislav Petkov]

On Mon, Jan 19, 2015 at 05:08:39PM +1100, Stephen Rothwell wrote:
> Hi Andy,
> 
> Today's linux-next merge of the luto-misc tree got a conflict in
> arch/x86/kernel/cpu/mcheck/mce.c between commit 83737691e586 ("x86,
> mce: Fix sparse errors") from the tip tree and commit d4812e169de4
> ("x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks") from
> the luto-misc tree.
> 
> I fixed it up (the latter removed some of the code changed by the
> former) and can carry the fix as necessary (no action is required).

That must be the piece of the hunk touching mce_info. Yes, the correct
solution is to follow what d4812e169de4 does.

Thanks Stephen :)

---
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 800d423f1e92..d23179900755 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1004,51 +1004,6 @@ static void mce_clear_state(unsigned long *toclear)
 }
 
 /*
- * Need to save faulting physical address associated with a process
- * in the machine check handler some place where we can grab it back
- * later in mce_notify_process()
- */
-#define        MCE_INFO_MAX    16
-
-struct mce_info {
-       atomic_t                inuse;
-       struct task_struct      *t;
-       __u64                   paddr;
-       int                     restartable;
-} mce_info[MCE_INFO_MAX];

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Fwd: linux-next: manual merge of the luto-misc tree with the tip tree

[Andy Lutomirski]

Hi Ingo and Thomas-

There's a trivial conflict in the pull request I sent last week.

--Andy


---------- Forwarded message ----------
From: Borislav Petkov <bp@suse.de>
Date: Mon, Jan 19, 2015 at 1:35 AM
Subject: Re: linux-next: manual merge of the luto-misc tree with the tip tree
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Andy Lutomirski <luto@amacapital.net>, "Luck, Tony"
<tony.luck@intel.com>, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org


On Mon, Jan 19, 2015 at 05:08:39PM +1100, Stephen Rothwell wrote:
> Hi Andy,
>
> Today's linux-next merge of the luto-misc tree got a conflict in
> arch/x86/kernel/cpu/mcheck/mce.c between commit 83737691e586 ("x86,
> mce: Fix sparse errors") from the tip tree and commit d4812e169de4
> ("x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks") from
> the luto-misc tree.
>
> I fixed it up (the latter removed some of the code changed by the
> former) and can carry the fix as necessary (no action is required).

That must be the piece of the hunk touching mce_info. Yes, the correct
solution is to follow what d4812e169de4 does.

Thanks Stephen :)

---
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 800d423f1e92..d23179900755 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1004,51 +1004,6 @@ static void mce_clear_state(unsigned long *toclear)
 }

 /*
- * Need to save faulting physical address associated with a process
- * in the machine check handler some place where we can grab it back
- * later in mce_notify_process()
- */
-#define        MCE_INFO_MAX    16
-
-struct mce_info {
-       atomic_t                inuse;
-       struct task_struct      *t;
-       __u64                   paddr;
-       int                     restartable;
-} mce_info[MCE_INFO_MAX];

--
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--


-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree

[Ingo Molnar]

* Andy Lutomirski <luto@amacapital.net> wrote:

> Hi Ingo and Thomas-
> 
> There's a trivial conflict in the pull request I sent last week.

This is your x86 entry code rework pull request, right? The -tip 
tree now has the RCU commit it depends on, so could you please 
rebase it on top of tip:core/rcu so I can pull it? I'll resolve 
any remaining conflicts with the rest of -tip.

Thanks,

	Ingo

Re: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree

[Andy Lutomirski]

On Tue, Jan 20, 2015 at 9:34 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Andy Lutomirski <luto@amacapital.net> wrote:
>
>> Hi Ingo and Thomas-
>>
>> There's a trivial conflict in the pull request I sent last week.
>
> This is your x86 entry code rework pull request, right? The -tip
> tree now has the RCU commit it depends on, so could you please
> rebase it on top of tip:core/rcu so I can pull it? I'll resolve
> any remaining conflicts with the rest of -tip.
>

Sure, I can do that in the morning.  The pull request merges cleanly
with tip:core/rcu, though, so is the rebase needed?

--Andy

Re: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree

[Andy Lutomirski]

On Tue, Jan 20, 2015 at 9:48 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, Jan 20, 2015 at 9:34 PM, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * Andy Lutomirski <luto@amacapital.net> wrote:
>>
>>> Hi Ingo and Thomas-
>>>
>>> There's a trivial conflict in the pull request I sent last week.
>>
>> This is your x86 entry code rework pull request, right? The -tip
>> tree now has the RCU commit it depends on, so could you please
>> rebase it on top of tip:core/rcu so I can pull it? I'll resolve
>> any remaining conflicts with the rest of -tip.
>>
>
> Sure, I can do that in the morning.  The pull request merges cleanly
> with tip:core/rcu, though, so is the rebase needed?

The rebase was trivial.  If you prefer it:

The following changes since commit f49028292c13b958fdf4f36c8cc8119d0dde187b:

  Merge branch 'for-mingo' of
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into
core/rcu (2015-01-21 06:12:21 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git
tags/pr-20150120-x86-entry

for you to fetch changes up to 0e5c6d1b97b194aa5cbb79ea3a73236a9de8811c:

  x86: entry_64.S: fold SAVE_ARGS_IRQ macro into its sole user
(2015-01-20 21:49:15 -0800)

----------------------------------------------------------------
[This is identical to pr-20150114-x86-entry, except rebased to tip:core/rcu]

This is my accumulated x86 entry work, part 1, for 3.20.  The meat
of this is an IST rework.  When an IST exception interrupts user
space, we will handle it on the per-thread kernel stack instead of
on the IST stack.  This sounds messy, but it actually simplifies the
IST entry/exit code, because it eliminates some ugly games we used
to play in order to handle rescheduling, signal delivery, etc on the
way out of an IST exception.

The IST rework introduces proper context tracking to IST exception
handlers.  I haven't seen any bug reports, but the old code could
have incorrectly treated an IST exception handler as an RCU extended
quiescent state.

The memory failure change (included in this pull request with
Borislav and Tony's permission) eliminates a bunch of code that
is no longer needed now that user memory failure handlers are
called in process context.

Finally, this includes a few on Denys' uncontroversial and Obviously
Correct (tm) cleanups.

The IST and memory failure changes have been in -next for a while.

LKML references:

IST rework:
http://lkml.kernel.org/r/cover.1416604491.git.luto@amacapital.net

Memory failure change:
http://lkml.kernel.org/r/54ab2ffa301102cd6e@agluck-desk.sc.intel.com

Denys' cleanups:
http://lkml.kernel.org/r/1420927210-19738-1-git-send-email-dvlasenk@redhat.com

----------------------------------------------------------------
Andy Lutomirski (4):
      x86, entry: Switch stacks on a paranoid entry from userspace
      x86, traps: Track entry into and exit from IST context
      x86: Clean up current_stack_pointer
      x86, traps: Add ist_begin_non_atomic and ist_end_non_atomic

Denys Vlasenko (3):
      x86: entry_64.S: delete unused code
      x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET
      x86: entry_64.S: fold SAVE_ARGS_IRQ macro into its sole user

Tony Luck (1):
      x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks

 Documentation/x86/entry_64.txt         |  18 ++-
 Documentation/x86/x86_64/kernel-stacks |   8 +-
 arch/x86/ia32/ia32entry.S              |   4 +-
 arch/x86/include/asm/calling.h         |   1 -
 arch/x86/include/asm/mce.h             |   1 -
 arch/x86/include/asm/thread_info.h     |  15 ++-
 arch/x86/include/asm/traps.h           |   6 +
 arch/x86/kernel/cpu/mcheck/mce.c       | 114 +++++-------------
 arch/x86/kernel/cpu/mcheck/p5.c        |   6 +
 arch/x86/kernel/cpu/mcheck/winchip.c   |   5 +
 arch/x86/kernel/entry_64.S             | 208 ++++++++++++++-------------------
 arch/x86/kernel/irq_32.c               |  13 +--
 arch/x86/kernel/signal.c               |   6 -
 arch/x86/kernel/traps.c                | 108 +++++++++++++----
 14 files changed, 252 insertions(+), 261 deletions(-)

--Andy

Re: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree

[Ingo Molnar]

* Andy Lutomirski <luto@amacapital.net> wrote:

> On Tue, Jan 20, 2015 at 9:34 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Andy Lutomirski <luto@amacapital.net> wrote:
> >
> >> Hi Ingo and Thomas-
> >>
> >> There's a trivial conflict in the pull request I sent last week.
> >
> > This is your x86 entry code rework pull request, right? The -tip
> > tree now has the RCU commit it depends on, so could you please
> > rebase it on top of tip:core/rcu so I can pull it? I'll resolve
> > any remaining conflicts with the rest of -tip.
> >
> 
> Sure, I can do that in the morning.  The pull request merges cleanly
> with tip:core/rcu, though, so is the rebase needed?

Yes, because your changes rely on the RCU change (semantically), 
so if anyone bisects into your commits it might result in a 
subtly broken kernel, right?

Thanks,

	Ingo

Re: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree

[Andy Lutomirski]

On Tue, Jan 20, 2015 at 9:55 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Andy Lutomirski <luto@amacapital.net> wrote:
>
>> On Tue, Jan 20, 2015 at 9:34 PM, Ingo Molnar <mingo@kernel.org> wrote:
>> >
>> > * Andy Lutomirski <luto@amacapital.net> wrote:
>> >
>> >> Hi Ingo and Thomas-
>> >>
>> >> There's a trivial conflict in the pull request I sent last week.
>> >
>> > This is your x86 entry code rework pull request, right? The -tip
>> > tree now has the RCU commit it depends on, so could you please
>> > rebase it on top of tip:core/rcu so I can pull it? I'll resolve
>> > any remaining conflicts with the rest of -tip.
>> >
>>
>> Sure, I can do that in the morning.  The pull request merges cleanly
>> with tip:core/rcu, though, so is the rebase needed?
>
> Yes, because your changes rely on the RCU change (semantically),
> so if anyone bisects into your commits it might result in a
> subtly broken kernel, right?
>

Almost.  The parent of my original pull request is the RCU change that
my entry changes semantically depend on, so bisection should be fine.

--Andy

Re: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree

[Ingo Molnar]

* Andy Lutomirski <luto@amacapital.net> wrote:

> On Tue, Jan 20, 2015 at 9:55 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Andy Lutomirski <luto@amacapital.net> wrote:
> >
> >> On Tue, Jan 20, 2015 at 9:34 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >> >
> >> > * Andy Lutomirski <luto@amacapital.net> wrote:
> >> >
> >> >> Hi Ingo and Thomas-
> >> >>
> >> >> There's a trivial conflict in the pull request I sent last week.
> >> >
> >> > This is your x86 entry code rework pull request, right? The -tip
> >> > tree now has the RCU commit it depends on, so could you please
> >> > rebase it on top of tip:core/rcu so I can pull it? I'll resolve
> >> > any remaining conflicts with the rest of -tip.
> >> >
> >>
> >> Sure, I can do that in the morning.  The pull request merges cleanly
> >> with tip:core/rcu, though, so is the rebase needed?
> >
> > Yes, because your changes rely on the RCU change (semantically),
> > so if anyone bisects into your commits it might result in a
> > subtly broken kernel, right?
> 
> Almost.  The parent of my original pull request is the RCU 
> change that my entry changes semantically depend on, so 
> bisection should be fine.

Okay, that's good - so now I can pull your bits, because the RCU 
commit is final, no need to rebase. (Because you already based 
your bits on the RCU change that later on ended up in -tip.)

Thanks,

	Ingo

Re: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree

[Andy Lutomirski]

On Tue, Jan 20, 2015 at 10:16 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Andy Lutomirski <luto@amacapital.net> wrote:
>
>> On Tue, Jan 20, 2015 at 9:55 PM, Ingo Molnar <mingo@kernel.org> wrote:
>> >
>> > * Andy Lutomirski <luto@amacapital.net> wrote:
>> >
>> >> On Tue, Jan 20, 2015 at 9:34 PM, Ingo Molnar <mingo@kernel.org> wrote:
>> >> >
>> >> > * Andy Lutomirski <luto@amacapital.net> wrote:
>> >> >
>> >> >> Hi Ingo and Thomas-
>> >> >>
>> >> >> There's a trivial conflict in the pull request I sent last week.
>> >> >
>> >> > This is your x86 entry code rework pull request, right? The -tip
>> >> > tree now has the RCU commit it depends on, so could you please
>> >> > rebase it on top of tip:core/rcu so I can pull it? I'll resolve
>> >> > any remaining conflicts with the rest of -tip.
>> >> >
>> >>
>> >> Sure, I can do that in the morning.  The pull request merges cleanly
>> >> with tip:core/rcu, though, so is the rebase needed?
>> >
>> > Yes, because your changes rely on the RCU change (semantically),
>> > so if anyone bisects into your commits it might result in a
>> > subtly broken kernel, right?
>>
>> Almost.  The parent of my original pull request is the RCU
>> change that my entry changes semantically depend on, so
>> bisection should be fine.
>
> Okay, that's good - so now I can pull your bits, because the RCU
> commit is final, no need to rebase. (Because you already based
> your bits on the RCU change that later on ended up in -tip.)
>

Are you planning on pulling that version?  In the mean time, I removed
it from -next so that there won't be a pointless conflict depending on
which version you pull.

Thanks,
Andy

> Thanks,
>
>         Ingo



-- 
Andy Lutomirski
AMA Capital Management, LLC