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

[Stephen Rothwell]

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//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..
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@@ -1680,7 -1673,10 +1672,10 @@@ requires CAP_SYS_RESOURCE
  3.2 /proc//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 . Use it together with /proc//oom_score_adj to tune which
  process should be killed in an out-of-memory situation.
  


pgpfEDKrLJdop.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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..
--- 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


pgpcl4rBMJ8TZ.pgp
Description: OpenPGP digital signature

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  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.pa...@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=152284705204400=2
  https://marc.info/?l=linux-kernel=152294150600751=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

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  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.pa...@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=152284705204400=2
  https://marc.info/?l=linux-kernel=152294150600751=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

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  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.pa...@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

[Jonathan Corbet]

On Wed, 9 May 2018 18:53:28 +0200
Andrea Parri  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.pa...@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 08:59:20AM -0600, Jonathan Corbet wrote:
> On Wed, 9 May 2018 15:28:24 +0200
> Andrea Parri  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.pa...@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

[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  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.pa...@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 15:28:24 +0200
Andrea Parri  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

[Jonathan Corbet]

On Wed, 9 May 2018 15:28:24 +0200
Andrea Parri  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]

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

[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

[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]

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

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

[Stephen Rothwell]

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


pgpzIliutogYp.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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


pgpzIliutogYp.pgp
Description: OpenPGP digital signature

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

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:s...@canb.auug.org.au]
> Sent: Thursday, December 31, 2015 4:43 AM
> To: Andrew Morton ; Jonathan Corbet
> 
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Elliott, Robert (Persistent Memory) ; Taku Izumi
> 
> 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 Rothwells...@canb.auug.org.au
> 
> diff --cc Documentation/kernel-parameters.txt
> index adf540032a9d,2cfb638d138b..
> --- 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...


--
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 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 Rothwells...@canb.auug.org.au

diff --cc mm/page_alloc.c
index 13cf824f6d23,72218a4adab9..
--- 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 < 0x10) {
+   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
--
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 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 Rothwells...@canb.auug.org.au

diff --cc Documentation/kernel-parameters.txt
index adf540032a9d,2cfb638d138b..
--- 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
--
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 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 Rothwells...@canb.auug.org.au

diff --cc mm/page_alloc.c
index 13cf824f6d23,72218a4adab9..
--- 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 < 0x10) {
+   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
--
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 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 Rothwells...@canb.auug.org.au

diff --cc Documentation/kernel-parameters.txt
index adf540032a9d,2cfb638d138b..
--- 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
--
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 akpm-current tree with the jc_docs tree

[Elliott, Robert (Persistent Memory)]

> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: Thursday, December 31, 2015 4:43 AM
> To: Andrew Morton <a...@linux-foundation.org>; Jonathan Corbet
> <cor...@lwn.net>
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Elliott, Robert (Persistent Memory) <elli...@hpe.com>; Taku Izumi
> <izumi.t...@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 Rothwells...@canb.auug.org.au
> 
> diff --cc Documentation/kernel-parameters.txt
> index adf540032a9d,2cfb638d138b..
> --- 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...


--
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/