linux-next: manual merge of the akpm-current tree with the jc_docs tree

linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Stephen Rothwell]

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

Hi all,

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

  Documentation/features/vm/pte_special/arch-support.txt

between commit:

  2bef69a385b4 ("Documentation/features/vm: Remove arch support status file for 'pte_special'")

from the jc_docs tree and commit:

  1099dc900e93 ("mm: introduce ARCH_HAS_PTE_SPECIAL")

from the akpm-current tree.

I fixed it up (the former removed the file, so I did that) 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.

BTW, it would be nice if the the question "Why was this file removed?" was
answered by that jc_docs commit message ...  I actually wonder if this
file needs to return (I have no way of knowing).

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Andrea Parri]

On Wed, May 09, 2018 at 08:25:26PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   Documentation/features/vm/pte_special/arch-support.txt
> 
> between commit:
> 
>   2bef69a385b4 ("Documentation/features/vm: Remove arch support status file for 'pte_special'")
> 
> from the jc_docs tree and commit:
> 
>   1099dc900e93 ("mm: introduce ARCH_HAS_PTE_SPECIAL")
> 
> from the akpm-current tree.
> 
> I fixed it up (the former removed the file, so I did that) 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.
> 
> BTW, it would be nice if the the question "Why was this file removed?" was
> answered by that jc_docs commit message ...  I actually wonder if this
> file needs to return (I have no way of knowing).

My bad; thanks for pointing this out.

Mmh... "why" would have been something like "the feature has no Kconfig". ;-)

I defer to your (community) decision regarding "if this file needs to return"
(Cc-ing Ingo, who created the file and also suggested its removal); I remain
available for preparing the patch to restore (and refresh) this file, should
you agree with this approach.

  Andrea


> 
> -- 
> Cheers,
> Stephen Rothwell

Re: linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Andrea Parri]

Really Cc-ing Ingo:

On Wed, May 09, 2018 at 03:28:24PM +0200, Andrea Parri wrote:
> On Wed, May 09, 2018 at 08:25:26PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> > 
> >   Documentation/features/vm/pte_special/arch-support.txt
> > 
> > between commit:
> > 
> >   2bef69a385b4 ("Documentation/features/vm: Remove arch support status file for 'pte_special'")
> > 
> > from the jc_docs tree and commit:
> > 
> >   1099dc900e93 ("mm: introduce ARCH_HAS_PTE_SPECIAL")
> > 
> > from the akpm-current tree.
> > 
> > I fixed it up (the former removed the file, so I did that) 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.
> > 
> > BTW, it would be nice if the the question "Why was this file removed?" was
> > answered by that jc_docs commit message ...  I actually wonder if this
> > file needs to return (I have no way of knowing).
> 
> My bad; thanks for pointing this out.
> 
> Mmh... "why" would have been something like "the feature has no Kconfig". ;-)
> 
> I defer to your (community) decision regarding "if this file needs to return"
> (Cc-ing Ingo, who created the file and also suggested its removal); I remain
> available for preparing the patch to restore (and refresh) this file, should
> you agree with this approach.
> 
>   Andrea
> 
> 
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> 
> 

Re: linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Jonathan Corbet]

On Wed, 9 May 2018 15:28:24 +0200
Andrea Parri <andrea.parri@amarulasolutions.com> wrote:

> > BTW, it would be nice if the the question "Why was this file removed?" was
> > answered by that jc_docs commit message ...  I actually wonder if this
> > file needs to return (I have no way of knowing).  
> 
> My bad; thanks for pointing this out.
> 
> Mmh... "why" would have been something like "the feature has no Kconfig". ;-)
> 
> I defer to your (community) decision regarding "if this file needs to return"
> (Cc-ing Ingo, who created the file and also suggested its removal); I remain
> available for preparing the patch to restore (and refresh) this file, should
> you agree with this approach.

So I'll confess that I balked on the lack of a changelog, but then decided
to proceed with the patch (and the other removal as well) due to the lack
of the Kconfig option.

Now that I look a little closer, I think the real issue is that the
"features" documentation assumes that there's a Kconfig option for each,
but there isn't in this case.  The lack of a Kconfig option does not,
this time around, imply that the feature has gone away.

I think that I should probably revert this patch in the short term.
Longer-term, it would be good to have an alternative syntax for "variable
set in the arch headers" to describe situations like this.

Make sense?

Thanks,

jon

Re: linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Andrea Parri]

On Wed, May 09, 2018 at 08:59:20AM -0600, Jonathan Corbet wrote:
> On Wed, 9 May 2018 15:28:24 +0200
> Andrea Parri <andrea.parri@amarulasolutions.com> wrote:
> 
> > > BTW, it would be nice if the the question "Why was this file removed?" was
> > > answered by that jc_docs commit message ...  I actually wonder if this
> > > file needs to return (I have no way of knowing).  
> > 
> > My bad; thanks for pointing this out.
> > 
> > Mmh... "why" would have been something like "the feature has no Kconfig". ;-)
> > 
> > I defer to your (community) decision regarding "if this file needs to return"
> > (Cc-ing Ingo, who created the file and also suggested its removal); I remain
> > available for preparing the patch to restore (and refresh) this file, should
> > you agree with this approach.
> 
> So I'll confess that I balked on the lack of a changelog, but then decided
> to proceed with the patch (and the other removal as well) due to the lack
> of the Kconfig option.
> 
> Now that I look a little closer, I think the real issue is that the
> "features" documentation assumes that there's a Kconfig option for each,
> but there isn't in this case.  The lack of a Kconfig option does not,
> this time around, imply that the feature has gone away.
> 
> I think that I should probably revert this patch in the short term.
> Longer-term, it would be good to have an alternative syntax for "variable
> set in the arch headers" to describe situations like this.

Both matters were discussed during v1:

  http://lkml.kernel.org/r/1522774551-9503-1-git-send-email-andrea.parri@amarulasolutions.com

... (and the glory details are documented in features-refresh.sh ;-) ).

As I suggested above, simply reverting this patch will leave this file,
(and only this file!) out-of-date (and won't resolve the conflict with
Laurent's patch ...).

  Andrea


> 
> Make sense?
> 
> Thanks,
> 
> jon

Re: linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Jonathan Corbet]

On Wed, 9 May 2018 18:53:28 +0200
Andrea Parri <andrea.parri@amarulasolutions.com> wrote:

> > Now that I look a little closer, I think the real issue is that the
> > "features" documentation assumes that there's a Kconfig option for each,
> > but there isn't in this case.  The lack of a Kconfig option does not,
> > this time around, imply that the feature has gone away.
> > 
> > I think that I should probably revert this patch in the short term.
> > Longer-term, it would be good to have an alternative syntax for "variable
> > set in the arch headers" to describe situations like this.  
> 
> Both matters were discussed during v1:
> 
>   http://lkml.kernel.org/r/1522774551-9503-1-git-send-email-andrea.parri@amarulasolutions.com
> 
> ... (and the glory details are documented in features-refresh.sh ;-) ).

So I'll admit to being confused, since I don't see discussion of the
actual topic at hand.

> As I suggested above, simply reverting this patch will leave this file,
> (and only this file!) out-of-date (and won't resolve the conflict with
> Laurent's patch ...).

Reverting this patch retains the updates from earlier in the series, and
does indeed make the conflict go away, so I'm still confused.  What am I
missing?

Thanks,

jon

Re: linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Andrea Parri]

On Wed, May 09, 2018 at 11:11:36AM -0600, Jonathan Corbet wrote:
> On Wed, 9 May 2018 18:53:28 +0200
> Andrea Parri <andrea.parri@amarulasolutions.com> wrote:
> 
> > > Now that I look a little closer, I think the real issue is that the
> > > "features" documentation assumes that there's a Kconfig option for each,
> > > but there isn't in this case.  The lack of a Kconfig option does not,
> > > this time around, imply that the feature has gone away.
> > > 
> > > I think that I should probably revert this patch in the short term.
> > > Longer-term, it would be good to have an alternative syntax for "variable
> > > set in the arch headers" to describe situations like this.  
> > 
> > Both matters were discussed during v1:
> > 
> >   http://lkml.kernel.org/r/1522774551-9503-1-git-send-email-andrea.parri@amarulasolutions.com
> > 
> > ... (and the glory details are documented in features-refresh.sh ;-) ).
> 
> So I'll admit to being confused, since I don't see discussion of the
> actual topic at hand.

A couple of clicks on "next in thread"  :-)

  https://marc.info/?l=linux-kernel&m=152284705204400&w=2
  https://marc.info/?l=linux-kernel&m=152294150600751&w=2


> 
> > As I suggested above, simply reverting this patch will leave this file,
> > (and only this file!) out-of-date (and won't resolve the conflict with
> > Laurent's patch ...).
> 
> Reverting this patch retains the updates from earlier in the series, and
> does indeed make the conflict go away, so I'm still confused.  What am I
> missing?

The updates from earlier added "TODO" rows for nds32 and riscv, but missed
the "TODO -> ok" update for riscv.

  Andrea


> 
> Thanks,
> 
> jon

linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Stephen Rothwell]

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

Hi all,

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

  Documentation/filesystems/proc.rst

between commit:

  059db4341303 ("Documentation/filesystems/proc.rst: copy-editing cleanup")

from the jc_docs tree and commit:

  7079aa70a489 ("doc, mm: clarify /proc/<pid>/oom_score value range")

from the akpm-current 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 Documentation/filesystems/proc.rst
index e024a9efffd8,78a0dec323a3..000000000000
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@@ -1680,7 -1673,10 +1672,10 @@@ requires CAP_SYS_RESOURCE
  3.2 /proc/<pid>/oom_score - Display current oom-killer score
  -------------------------------------------------------------
  
+ Please note that the exported value includes oom_score_adj so it is effectively
+ in range [0,2000].
+ 
 -This file can be used to check the current score used by the oom-killer is for
 +This file can be used to check the current score used by the oom-killer for
  any given <pid>. Use it together with /proc/<pid>/oom_score_adj to tune which
  process should be killed in an out-of-memory situation.
  

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

linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Stephen Rothwell]

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

Hi all,

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

  include/linux/printk.h

between commit:

  90c165f0de3a ("docs: pr_*() kerneldocs and basic printk docs")

from the jc_docs tree and commit:

  2023be154f91 ("dynamic_debug: add an option to enable dynamic debug for modules only")

from the akpm-current tree.

I fixed it up (I just used the latter version - though the comment
for pr_debug now probably wants expanding) 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 akpm-current tree with the jc_docs tree

[Stephen Rothwell]

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

Hi all,

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

  Documentation/process/deprecated.rst

between commit:

  d8401f504b49 ("docs: deprecated.rst: Add %p to the list")
  76136e028d3b ("docs: deprecated.rst: Clean up fall-through details")
  7929b9836ed0 ("docs: Remove :c:func: from process/deprecated.rst")

from the jc_docs tree and commit:

  eacc9a8c9c2d ("Documentation/checkpatch: prefer stracpy/strscpy over strcpy/strlcpy/strncpy.")

from the akpm-current 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 Documentation/process/deprecated.rst
index e924d3197761,a0ffdc8daef3..000000000000
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@@ -93,44 -93,22 +93,44 @@@ will be NUL terminated. This can lead t
  and other misbehavior due to the missing termination. It also NUL-pads the
  destination buffer if the source contents are shorter than the destination
  buffer size, which may be a needless performance penalty for callers using
- only NUL-terminated strings. The safe replacement is strscpy().
- (Users of strscpy() still needing NUL-padding should instead
- use strscpy_pad().)
+ only NUL-terminated strings. In this case, the safe replacement is
+ stracpy() or strscpy(). If, however, the destination buffer still needs
+ NUL-padding, the safe replacement is stracpy_pad().
  
 -If a caller is using non-NUL-terminated strings, :c:func:`strncpy()` can
 +If a caller is using non-NUL-terminated strings, strncpy()() can
  still be used, but destinations should be marked with the `__nonstring
  <https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_
  attribute to avoid future compiler warnings.
  
  strlcpy()
  ---------
 -:c:func:`strlcpy` reads the entire source buffer first, possibly exceeding
 +strlcpy() reads the entire source buffer first, possibly exceeding
  the given limit of bytes to copy. This is inefficient and can lead to
  linear read overflows if a source string is not NUL-terminated. The
- safe replacement is strscpy().
+ safe replacement is stracpy() or strscpy().
  
 +%p format specifier
 +-------------------
 +Traditionally, using "%p" in format strings would lead to regular address
 +exposure flaws in dmesg, proc, sysfs, etc. Instead of leaving these to
 +be exploitable, all "%p" uses in the kernel are being printed as a hashed
 +value, rendering them unusable for addressing. New uses of "%p" should not
 +be added to the kernel. For text addresses, using "%pS" is likely better,
 +as it produces the more useful symbol name instead. For nearly everything
 +else, just do not add "%p" at all.
 +
 +Paraphrasing Linus's current `guidance <https://lore.kernel.org/lkml/CA+55aFwQEd_d40g4mUCSsVRZzrFPUJt74vc6PPpb675hYNXcKw@mail.gmail.com/>`_:
 +
 +- If the hashed "%p" value is pointless, ask yourself whether the pointer
 +  itself is important. Maybe it should be removed entirely?
 +- If you really think the true pointer value is important, why is some
 +  system state or user privilege level considered "special"? If you think
 +  you can justify it (in comments and commit log) well enough to stand
 +  up to Linus's scrutiny, maybe you can use "%px", along with making sure
 +  you have sensible permissions.
 +
 +And finally, know that a toggle for "%p" hashing will `not be accepted <https://lore.kernel.org/lkml/CA+55aFwieC1-nAs+NFq9RTwaR8ef9hWa4MjNBWL41F-8wM49eA@mail.gmail.com/>`_.
 +
  Variable Length Arrays (VLAs)
  -----------------------------
  Using stack VLAs produces much worse machine code than statically

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

linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Stephen Rothwell]

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

Hi all,

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

  Documentation/admin-guide/cgroup-v2.rst

between commit:

  6ee0fac199e1 ("docs: fix memory.low description in cgroup-v2.rst")

from the jc_docs tree and commit:

  3968bb6dec48 ("mm, memcg: proportional memory.{low,min} reclaim")

from the akpm-current 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 Documentation/admin-guide/cgroup-v2.rst
index 26d1cde6b34a,5361ebec3361..000000000000
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@@ -1117,8 -1120,11 +1120,11 @@@ PAGE_SIZE multiple when read back
  
  	Best-effort memory protection.  If the memory usage of a
  	cgroup is within its effective low boundary, the cgroup's
 -	memory won't be reclaimed unless memory can be reclaimed
 -	from unprotected cgroups.  Above the effective low boundary (or
 -	effective min boundary if it is higher), pages are reclaimed
 -	proportionally to the overage, reducing reclaim pressure for
 -	smaller overages.
 +	memory won't be reclaimed unless there is no reclaimable
- 	memory available in unprotected cgroups.
++	memory available in unprotected cgroups.  Above the effective
++	low boundary (or effective min boundary if it is higher), pages
++	are reclaimed proportionally to the overage, reducing reclaim
++	pressure for smaller overages.
  
  	Effective low boundary is limited by memory.low values of
  	all ancestor cgroups. If there is memory.low overcommitment

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

linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Stephen Rothwell]

Hi Andrew,

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

  lib/Kconfig.debug

between commit:

  63d0977c0e85 ("lib/Kconfig.debug: correct documentation paths")

from the jc_docs tree and commit:

  2c81218d9f29 ("Kconfig: lib/Kconfig.debug: fix references to Documenation")

from the akpm-current tree.

I fixed it up (I just used the version from the jc_docs tree) 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 akpm-current tree with the jc_docs tree

[Elliott, Robert (Persistent Memory)]

> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Sent: Thursday, December 31, 2015 4:43 AM
> To: Andrew Morton <akpm@linux-foundation.org>; Jonathan Corbet
> <corbet@lwn.net>
> Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org;
> Elliott, Robert (Persistent Memory) <elliott@hpe.com>; Taku Izumi
> <izumi.taku@jp.fujitsu.com>
> Subject: linux-next: manual merge of the akpm-current tree with the
> jc_docs tree
> 
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   Documentation/kernel-parameters.txt
> 
> between commit:
> 
>   9daacf51b428 ("Documentation/kernel-parameters: update KMG units")
> 
> from the jc_docs tree and commit:
> 
>   f0a906868be1 ("mm/page_alloc.c: introduce kernelcore=mirror
> option")
> 
> from the akpm-current 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 Documentation/kernel-parameters.txt
> index adf540032a9d,2cfb638d138b..000000000000
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@@ -1710,7 -1696,8 +1714,8 @@@ Such letter suffixes can also be
> entire
> 
>   	keepinitrd	[HW,ARM]
> 
> - 	kernelcore=nn[KMGTPE]	[KNL,X86,IA-64,PPC] This parameter
>  -	kernelcore=	Format: nn[KMG] | "mirror"
> ++	kernelcore=	Format: nn[KMGTPE] | "mirror"
> + 			[KNL,X86,IA-64,PPC] This parameter
>   			specifies the amount of memory usable by the
> kernel
>   			for non-movable allocations.  The requested
> amount is
>   			spread evenly throughout all nodes in the system.
> The

There's a pretty strong convention that the [KNL,X86,IA-64,PPC] line
stay on the first line for grep, which seems more important than
keeping the format on that line. So, it might be better to resolve
using three lines like this:

	kernelcore=  [KNL,X86,IA-64,PPC] 
	Format: nn[KMGPTE] | "mirror"  
	This parameter specifies...

linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Stephen Rothwell]

Hi Andrew,

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

  mm/page_alloc.c

between commit:

  9daacf51b428 ("Documentation/kernel-parameters: update KMG units")

from the jc_docs tree and commit:

  f0a906868be1 ("mm/page_alloc.c: introduce kernelcore=mirror option")

from the akpm-current 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 mm/page_alloc.c
index 13cf824f6d23,72218a4adab9..000000000000
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@@ -5500,7 -5718,37 +5718,37 @@@ static void __init find_zone_movable_pf
  	}
  
  	/*
+ 	 * If kernelcore=mirror is specified, ignore movablecore option
+ 	 */
+ 	if (mirrored_kernelcore) {
+ 		bool mem_below_4gb_not_mirrored = false;
+ 
+ 		for_each_memblock(memory, r) {
+ 			if (memblock_is_mirror(r))
+ 				continue;
+ 
+ 			nid = r->nid;
+ 
+ 			usable_startpfn = memblock_region_memory_base_pfn(r);
+ 
+ 			if (usable_startpfn < 0x100000) {
+ 				mem_below_4gb_not_mirrored = true;
+ 				continue;
+ 			}
+ 
+ 			zone_movable_pfn[nid] = zone_movable_pfn[nid] ?
+ 				min(usable_startpfn, zone_movable_pfn[nid]) :
+ 				usable_startpfn;
+ 		}
+ 
+ 		if (mem_below_4gb_not_mirrored)
+ 			pr_warn("This configuration results in unmirrored kernel memory.");
+ 
+ 		goto out2;
+ 	}
+ 
+ 	/*
 -	 * If movablecore=nn[KMG] was specified, calculate what size of
 +	 * If movablecore=nn[KMGTPE] was specified, calculate what size of
  	 * kernelcore that corresponds so that memory usable for
  	 * any allocation type is evenly spread. If both kernelcore
  	 * and movablecore are specified, then the value of kernelcore

linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Stephen Rothwell]

Hi Andrew,

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

  Documentation/kernel-parameters.txt

between commit:

  9daacf51b428 ("Documentation/kernel-parameters: update KMG units")

from the jc_docs tree and commit:

  f0a906868be1 ("mm/page_alloc.c: introduce kernelcore=mirror option")

from the akpm-current 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 Documentation/kernel-parameters.txt
index adf540032a9d,2cfb638d138b..000000000000
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@@ -1710,7 -1696,8 +1714,8 @@@ Such letter suffixes can also be entire
  
  	keepinitrd	[HW,ARM]
  
- 	kernelcore=nn[KMGTPE]	[KNL,X86,IA-64,PPC] This parameter
 -	kernelcore=	Format: nn[KMG] | "mirror"
++	kernelcore=	Format: nn[KMGTPE] | "mirror"
+ 			[KNL,X86,IA-64,PPC] This parameter
  			specifies the amount of memory usable by the kernel
  			for non-movable allocations.  The requested amount is
  			spread evenly throughout all nodes in the system. The