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

[Stephen Rothwell]

Hi all,

On Mon, 18 Feb 2019 17:51:20 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   fs/binfmt_script.c
> 
> between commit:
> 
>   cb5b020a8d38 ("Revert "exec: load_script: don't blindly truncate shebang 
> string"")
> 
> from Linus' tree and commit:
> 
>   76b21f3b9c4d ("exec: load_script: allow interpreter argument truncation")
> 
> from the akpm-current tree.

Since Linus has applied something similar to his tree, I have dropped
that latter patch from the akpm-current tree from today.
-- 
Cheers,
Stephen Rothwell


pgpKVPyToWuw2.pgp
Description: OpenPGP digital signature

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

[Jerome Glisse]

On Fri, Jan 11, 2019 at 01:51:00PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   mm/rmap.c
> 
> between commit:
> 
>   ba422731316d ("mm/mmu_notifier: mm/rmap.c: Fix a mmu_notifier range bug in 
> try_to_unmap_one")
> 
> from Linus' tree and commit:
> 
>   f955d5dda846 ("mm/mmu_notifier: contextual information for event triggering 
> invalidation v2")
> 
> 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.

This looks good to me.

Thank you,
Jérôme

> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc mm/rmap.c
> index 0454ecc29537,62e47f3462cf..
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@@ -1371,9 -1372,10 +1372,10 @@@ static bool try_to_unmap_one(struct pag
>* Note that the page can not be free in this function as call of
>* try_to_unmap() must hold a reference on the page.
>*/
>  -mmu_notifier_range_init(, vma->vm_mm, vma->vm_start,
>  -min(vma->vm_end, vma->vm_start +
>  +mmu_notifier_range_init(, vma->vm_mm, address,
>  +min(vma->vm_end, address +
> - (PAGE_SIZE << compound_order(page;
> + (PAGE_SIZE << compound_order(page))),
> + MMU_NOTIFY_CLEAR);
>   if (PageHuge(page)) {
>   /*
>* If sharing is possible, start and end will be adjusted

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

[Mel Gorman]

On Mon, Apr 24, 2017 at 05:25:02PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   mm/page_alloc.c
> 
> between commit:
> 
>   d34b0733b452 ("Revert "mm, page_alloc: only use per-cpu allocator for 
> irq-safe requests"")
> 
> from Linus' tree and commit:
> 
>   f4881295a79e ("mm, page_alloc: re-enable softirq use of per-cpu page 
> allocator")
>   e2f499864da5 
> ("mm-page_alloc-re-enable-softirq-use-of-per-cpu-page-allocator-checkpatch-fixes")
>   24612e65dd01 ("mm: delete NR_PAGES_SCANNED and pgdat_reclaimable()")
> 
> from the akpm-current tree.
> 

This should partially be a transient problem. The revert in Linus' tree is
now the primary patch with f4881295a79e and e2f499864da5 going away. Not
sure about 24612e65dd01

-- 
Mel Gorman
SUSE Labs

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

[Mel Gorman]

On Mon, Apr 24, 2017 at 05:25:02PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   mm/page_alloc.c
> 
> between commit:
> 
>   d34b0733b452 ("Revert "mm, page_alloc: only use per-cpu allocator for 
> irq-safe requests"")
> 
> from Linus' tree and commit:
> 
>   f4881295a79e ("mm, page_alloc: re-enable softirq use of per-cpu page 
> allocator")
>   e2f499864da5 
> ("mm-page_alloc-re-enable-softirq-use-of-per-cpu-page-allocator-checkpatch-fixes")
>   24612e65dd01 ("mm: delete NR_PAGES_SCANNED and pgdat_reclaimable()")
> 
> from the akpm-current tree.
> 

This should partially be a transient problem. The revert in Linus' tree is
now the primary patch with f4881295a79e and e2f499864da5 going away. Not
sure about 24612e65dd01

-- 
Mel Gorman
SUSE Labs

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

[Stephen Rothwell]

Hi Michal,

On Mon, 5 Dec 2016 06:56:56 +0100 Michal Hocko  wrote:
>
> FWIW this resolution is correct

Thanks, good to know.

> > 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.  
> 
> Sorry about that, I haven't noticed the conflict.

No worries, that is what I am here for :-)

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Michal,

On Mon, 5 Dec 2016 06:56:56 +0100 Michal Hocko  wrote:
>
> FWIW this resolution is correct

Thanks, good to know.

> > 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.  
> 
> Sorry about that, I haven't noticed the conflict.

No worries, that is what I am here for :-)

-- 
Cheers,
Stephen Rothwell

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

[Michal Hocko]

On Mon 05-12-16 16:38:08, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   mm/workingset.c
> 
> between commit:
> 
>   20ab67a563f5 ("mm: workingset: fix NULL ptr in count_shadow_nodes")
> 
> from Linus' tree and commit:
> 
>   8b6983cf8ca6 ("mm: workingset: update shadow limit to reflect bigger active 
> list")
> 
> 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,

FWIW this resolution is correct

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

Sorry about that, I haven't noticed the conflict.
 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc mm/workingset.c
> index fb1f9183d89a,02ab8746abde..
> --- a/mm/workingset.c
> +++ b/mm/workingset.c
> @@@ -366,16 -394,22 +394,22 @@@ static unsigned long count_shadow_nodes
>*
>* On 64-bit with 7 radix_tree_nodes per page and 64 slots
>* each, this will reclaim shadow entries when they consume
> -  * ~2% of available memory:
> +  * ~1.8% of available memory:
>*
> -  * PAGE_SIZE / radix_tree_nodes / node_entries / PAGE_SIZE
> +  * PAGE_SIZE / radix_tree_nodes / node_entries * 8 / PAGE_SIZE
>*/
> - max_nodes = pages >> (1 + RADIX_TREE_MAP_SHIFT - 3);
>  -if (memcg_kmem_enabled()) {
> ++if (sc->memcg) {
> + cache = mem_cgroup_node_nr_lru_pages(sc->memcg, sc->nid,
> +  LRU_ALL_FILE);
> + } else {
> + cache = node_page_state(NODE_DATA(sc->nid), NR_ACTIVE_FILE) +
> + node_page_state(NODE_DATA(sc->nid), NR_INACTIVE_FILE);
> + }
> + max_nodes = cache >> (RADIX_TREE_MAP_SHIFT - 3);
>   
> - if (shadow_nodes <= max_nodes)
> + if (nodes <= max_nodes)
>   return 0;
> - 
> - return shadow_nodes - max_nodes;
> + return nodes - max_nodes;
>   }
>   
>   static enum lru_status shadow_lru_isolate(struct list_head *item,

-- 
Michal Hocko
SUSE Labs

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

[Michal Hocko]

On Mon 05-12-16 16:38:08, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   mm/workingset.c
> 
> between commit:
> 
>   20ab67a563f5 ("mm: workingset: fix NULL ptr in count_shadow_nodes")
> 
> from Linus' tree and commit:
> 
>   8b6983cf8ca6 ("mm: workingset: update shadow limit to reflect bigger active 
> list")
> 
> 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,

FWIW this resolution is correct

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

Sorry about that, I haven't noticed the conflict.
 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc mm/workingset.c
> index fb1f9183d89a,02ab8746abde..
> --- a/mm/workingset.c
> +++ b/mm/workingset.c
> @@@ -366,16 -394,22 +394,22 @@@ static unsigned long count_shadow_nodes
>*
>* On 64-bit with 7 radix_tree_nodes per page and 64 slots
>* each, this will reclaim shadow entries when they consume
> -  * ~2% of available memory:
> +  * ~1.8% of available memory:
>*
> -  * PAGE_SIZE / radix_tree_nodes / node_entries / PAGE_SIZE
> +  * PAGE_SIZE / radix_tree_nodes / node_entries * 8 / PAGE_SIZE
>*/
> - max_nodes = pages >> (1 + RADIX_TREE_MAP_SHIFT - 3);
>  -if (memcg_kmem_enabled()) {
> ++if (sc->memcg) {
> + cache = mem_cgroup_node_nr_lru_pages(sc->memcg, sc->nid,
> +  LRU_ALL_FILE);
> + } else {
> + cache = node_page_state(NODE_DATA(sc->nid), NR_ACTIVE_FILE) +
> + node_page_state(NODE_DATA(sc->nid), NR_INACTIVE_FILE);
> + }
> + max_nodes = cache >> (RADIX_TREE_MAP_SHIFT - 3);
>   
> - if (shadow_nodes <= max_nodes)
> + if (nodes <= max_nodes)
>   return 0;
> - 
> - return shadow_nodes - max_nodes;
> + return nodes - max_nodes;
>   }
>   
>   static enum lru_status shadow_lru_isolate(struct list_head *item,

-- 
Michal Hocko
SUSE Labs

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

[Richard Weinberger]

Am Montag, 2. Dezember 2013, 23:31:31 schrieb Andrew Morton:
> On Tue, 03 Dec 2013 08:16:04 +0100 Richard Weinberger  
wrote:
> > Andrew,
> > 
> > Am Dienstag, 3. Dezember 2013, 12:52:19 schrieb Stephen Rothwell:
> > > Hi Andrew,
> > > 
> > > Today's linux-next merge of the akpm-current tree got a conflict in
> > > arch/um/kernel/sysrq.c between commit 8ed12fcc194d ("um: Rename
> > > print_stack_trace to do_stack_trace") from Linus' tree and commit
> > > ce89e7878311 ("arch/um/kernel/sysrq.c: rename print_stack_trace()") from
> > > the akpm-current tree.
> > > 
> > > I fixed it up (I used the version fro, Linus' tree) and can carry the
> > > fix
> > > as necessary (no action is required).
> > 
> > How comes that this patch landed in your tree, I didn't receive a mail
> > from
> > your bot?
> 
> Coz after I wrote it I carefully added cc:ric...@nod.at ;)

I see, time to add a few more alias to my MTA. ;-)

Thanks,
//richard
--
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 Linus' tree

[Andrew Morton]

On Tue, 03 Dec 2013 08:16:04 +0100 Richard Weinberger  wrote:

> Andrew,
> 
> Am Dienstag, 3. Dezember 2013, 12:52:19 schrieb Stephen Rothwell:
> > Hi Andrew,
> > 
> > Today's linux-next merge of the akpm-current tree got a conflict in
> > arch/um/kernel/sysrq.c between commit 8ed12fcc194d ("um: Rename
> > print_stack_trace to do_stack_trace") from Linus' tree and commit
> > ce89e7878311 ("arch/um/kernel/sysrq.c: rename print_stack_trace()") from
> > the akpm-current tree.
> > 
> > I fixed it up (I used the version fro, Linus' tree) and can carry the fix
> > as necessary (no action is required).
> 
> How comes that this patch landed in your tree, I didn't receive a mail from 
> your bot?

Coz after I wrote it I carefully added cc:ric...@nod.at ;)

--
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 Linus' tree

[Richard Weinberger]

Andrew,

Am Dienstag, 3. Dezember 2013, 12:52:19 schrieb Stephen Rothwell:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in
> arch/um/kernel/sysrq.c between commit 8ed12fcc194d ("um: Rename
> print_stack_trace to do_stack_trace") from Linus' tree and commit
> ce89e7878311 ("arch/um/kernel/sysrq.c: rename print_stack_trace()") from
> the akpm-current tree.
> 
> I fixed it up (I used the version fro, Linus' tree) and can carry the fix
> as necessary (no action is required).

How comes that this patch landed in your tree, I didn't receive a mail from 
your bot?
Anyway, it found it's way into Linus' tree using my UML tree.

Thanks,
//richard
--
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 Linus' tree

[Richard Weinberger]

Andrew,

Am Dienstag, 3. Dezember 2013, 12:52:19 schrieb Stephen Rothwell:
 Hi Andrew,
 
 Today's linux-next merge of the akpm-current tree got a conflict in
 arch/um/kernel/sysrq.c between commit 8ed12fcc194d (um: Rename
 print_stack_trace to do_stack_trace) from Linus' tree and commit
 ce89e7878311 (arch/um/kernel/sysrq.c: rename print_stack_trace()) from
 the akpm-current tree.
 
 I fixed it up (I used the version fro, Linus' tree) and can carry the fix
 as necessary (no action is required).

How comes that this patch landed in your tree, I didn't receive a mail from 
your bot?
Anyway, it found it's way into Linus' tree using my UML tree.

Thanks,
//richard
--
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 Linus' tree

[Andrew Morton]

On Tue, 03 Dec 2013 08:16:04 +0100 Richard Weinberger rich...@nod.at wrote:

 Andrew,
 
 Am Dienstag, 3. Dezember 2013, 12:52:19 schrieb Stephen Rothwell:
  Hi Andrew,
  
  Today's linux-next merge of the akpm-current tree got a conflict in
  arch/um/kernel/sysrq.c between commit 8ed12fcc194d (um: Rename
  print_stack_trace to do_stack_trace) from Linus' tree and commit
  ce89e7878311 (arch/um/kernel/sysrq.c: rename print_stack_trace()) from
  the akpm-current tree.
  
  I fixed it up (I used the version fro, Linus' tree) and can carry the fix
  as necessary (no action is required).
 
 How comes that this patch landed in your tree, I didn't receive a mail from 
 your bot?

Coz after I wrote it I carefully added cc:ric...@nod.at ;)

--
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 Linus' tree

[Richard Weinberger]

Am Montag, 2. Dezember 2013, 23:31:31 schrieb Andrew Morton:
 On Tue, 03 Dec 2013 08:16:04 +0100 Richard Weinberger rich...@nod.at 
wrote:
  Andrew,
  
  Am Dienstag, 3. Dezember 2013, 12:52:19 schrieb Stephen Rothwell:
   Hi Andrew,
   
   Today's linux-next merge of the akpm-current tree got a conflict in
   arch/um/kernel/sysrq.c between commit 8ed12fcc194d (um: Rename
   print_stack_trace to do_stack_trace) from Linus' tree and commit
   ce89e7878311 (arch/um/kernel/sysrq.c: rename print_stack_trace()) from
   the akpm-current tree.
   
   I fixed it up (I used the version fro, Linus' tree) and can carry the
   fix
   as necessary (no action is required).
  
  How comes that this patch landed in your tree, I didn't receive a mail
  from
  your bot?
 
 Coz after I wrote it I carefully added cc:ric...@nod.at ;)

I see, time to add a few more alias to my MTA. ;-)

Thanks,
//richard
--
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/