linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2014-04-07  4:18 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2014-04-07  4:18 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got lots of conflicts
with Linus' tree.  I tried to fix things up, but it was a real mess and
in the end I have just dropped your patch series until you can clean out
what went to Linus.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2022-04-11  3:35 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2022-04-11  3:35 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Matthew Wilcox (Oracle),
	Linux Kernel Mailing List, Linux Next Mailing List, Miaohe Lin

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

Hi all,

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

  mm/migrate.c

between commits:

  ffe06786b540 ("mm/migrate: Use a folio in alloc_migration_target()")
  c185e494ae0c ("mm/migrate: Use a folio in migrate_misplaced_transhuge_page()")

from Linus' tree and commits:

  4ea144548e29 ("mm/migration: remove unneeded out label")
  fc5f5507f33b ("mm/migration: fix the confusing PageTransHuge check")

from the akpm-current tree.

I fixed it up (I used the former version) 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 --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2021-04-06 11:29 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2021-04-06 11:29 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Petr Mladek,
	Stephen Rothwell, Tejun Heo, Wang Qing

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

Hi all,

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

  kernel/watchdog.c

between commit:

  89e28ce60cb6 ("workqueue/watchdog: Make unbound workqueues aware of touch_softlockup_watchdog() 84;0;0c84;0;0c There are two workqueue-specific watchdog timestamps:")

(pity about that commit subject)

from Linus' tree and commit:

  3dd2b5b9c268 ("watchdog/softlockup: report the overall time of softlockups")

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 kernel/watchdog.c
index 107bc38b1945,090b6bc4de79..000000000000
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@@ -278,10 -290,9 +290,10 @@@ void touch_all_softlockup_watchdogs(voi
  	 * update as well, the only side effect might be a cycle delay for
  	 * the softlockup check.
  	 */
 -	for_each_cpu(cpu, &watchdog_allowed_mask)
 +	for_each_cpu(cpu, &watchdog_allowed_mask) {
- 		per_cpu(watchdog_touch_ts, cpu) = SOFTLOCKUP_RESET;
+ 		per_cpu(watchdog_report_ts, cpu) = SOFTLOCKUP_DELAY_REPORT;
 -	wq_watchdog_touch(-1);
 +		wq_watchdog_touch(cpu);
 +	}
  }
  
  void touch_softlockup_watchdog_sync(void)

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2021-02-08 12:10 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2021-02-08 12:10 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Shaokun Zhang, Thomas Gleixner, Yuqi Jin

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

Hi all,

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

  lib/cpumask.c

between commit:

  2452483d9546 ("Revert "lib: Restrict cpumask_local_spread to houskeeping CPUs"")

from Linus' tree and commits:

  9eca9bb9bd98 ("lib: optimize cpumask_local_spread()")
  a7ac26ba236f ("lib-optimize-cpumask_local_spread-v8")

from the akpm-current tree.

I fixed it up (it was sufficiently messy that I just dropped the 2
commits from the akpm-current tree for today) 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 --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2020-09-08  9:24 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2020-09-08  9:24 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Juergen Gross, Roger Pau Monne, Dan Williams,
	Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

  drivers/dax/device.c

between commit:

  4533d3aed857 ("memremap: rename MEMORY_DEVICE_DEVDAX to MEMORY_DEVICE_GENERIC")

from Linus' tree and commit:

  ceb1b473719c ("device-dax: make pgmap optional for instance creation")

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 drivers/dax/device.c
index 1e89513f3c59,cc1f4ce185bf..000000000000
--- a/drivers/dax/device.c
+++ b/drivers/dax/device.c
@@@ -420,17 -396,37 +396,37 @@@ int dev_dax_probe(struct dev_dax *dev_d
  	struct inode *inode;
  	struct cdev *cdev;
  	void *addr;
- 	int rc;
+ 	int rc, i;
  
- 	/* 1:1 map region resource range to device-dax instance range */
- 	if (!devm_request_mem_region(dev, res->start, resource_size(res),
- 				dev_name(dev))) {
- 		dev_warn(dev, "could not reserve region %pR\n", res);
- 		return -EBUSY;
+ 	pgmap = dev_dax->pgmap;
+ 	if (dev_WARN_ONCE(dev, pgmap && dev_dax->nr_range > 1,
+ 			"static pgmap / multi-range device conflict\n"))
+ 		return -EINVAL;
+ 
+ 	if (!pgmap) {
+ 		pgmap = devm_kzalloc(dev, sizeof(*pgmap) + sizeof(struct range)
+ 				* (dev_dax->nr_range - 1), GFP_KERNEL);
+ 		if (!pgmap)
+ 			return -ENOMEM;
+ 		pgmap->nr_range = dev_dax->nr_range;
+ 	}
+ 
+ 	for (i = 0; i < dev_dax->nr_range; i++) {
+ 		struct range *range = &dev_dax->ranges[i].range;
+ 
+ 		if (!devm_request_mem_region(dev, range->start,
+ 					range_len(range), dev_name(dev))) {
+ 			dev_warn(dev, "mapping%d: %#llx-%#llx could not reserve range\n",
+ 					i, range->start, range->end);
+ 			return -EBUSY;
+ 		}
+ 		/* don't update the range for static pgmap */
+ 		if (!dev_dax->pgmap)
+ 			pgmap->ranges[i] = *range;
  	}
  
- 	dev_dax->pgmap.type = MEMORY_DEVICE_GENERIC;
- 	addr = devm_memremap_pages(dev, &dev_dax->pgmap);
 -	pgmap->type = MEMORY_DEVICE_DEVDAX;
++	pgmap->type = MEMORY_DEVICE_GENERIC;
+ 	addr = devm_memremap_pages(dev, pgmap);
  	if (IS_ERR(addr))
  		return PTR_ERR(addr);
  

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2020-09-08  9:17 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2020-09-08  9:17 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Miguel Ojeda, Mike Rapoport, Linux Next Mailing List,
	Linux Kernel Mailing List

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

Hi all,

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

  .clang-format

between commit:

  4e4bb894467c ("clang-format: Update with the latest for_each macro list")

from Linus' tree and commits:

  7008a2f408a3 ("memblock: implement for_each_reserved_mem_region() using __next_mem_region()")
  203287621da3 ("memblock: use separate iterators for memory and reserved regions")

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 .clang-format
index badfc1ba440a,a118fdde25c1..000000000000
--- a/.clang-format
+++ b/.clang-format
@@@ -269,8 -267,7 +271,9 @@@ ForEachMacros
    - 'for_each_process_thread'
    - 'for_each_property_of_node'
    - 'for_each_registered_fb'
 +  - 'for_each_requested_gpio'
 +  - 'for_each_requested_gpio_in_range'
+   - 'for_each_reserved_mem_range'
    - 'for_each_reserved_mem_region'
    - 'for_each_rtd_codec_dais'
    - 'for_each_rtd_codec_dais_rollback'

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2020-06-03  8:07 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2020-06-03  8:07 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Linus Torvalds, John Hubbard

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

Hi all,

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

  mm/gup.c

between commit:

  17839856fd58 ("gup: document and work around "COW can break either way" issue")

from Linus' tree and (at least) commits:

  d7f76db8e4ad ("mm/gup: move __get_user_pages_fast() down a few lines in gup.c")
  6a5f74c81019 ("mm/gup: refactor and de-duplicate gup_fast() code")

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 mm/gup.c
index 3edf740a3897,fb28e7aecd35..000000000000
--- a/mm/gup.c
+++ b/mm/gup.c
@@@ -2814,17 -2743,21 +2758,33 @@@ static int internal_get_user_pages_fast
  		return -EFAULT;
  
  	/*
+ 	 * Disable interrupts. The nested form is used, in order to allow full,
+ 	 * general purpose use of this routine.
+ 	 *
+ 	 * With interrupts disabled, we block page table pages from being
+ 	 * freed from under us. See struct mmu_table_batch comments in
+ 	 * include/asm-generic/tlb.h for more details.
+ 	 *
+ 	 * We do not adopt an rcu_read_lock(.) here as we also want to
+ 	 * block IPIs that come from THPs splitting.
++	 *
++	 * NOTE! We allow read-only gup_fast() here, but you'd better be
++	 * careful about possible COW pages. You'll get _a_ COW page, but
++	 * not necessarily the one you intended to get depending on what
++	 * COW event happens after this. COW may break the page copy in a
++	 * random direction.
++	 *
 +	 * The FAST_GUP case requires FOLL_WRITE even for pure reads,
 +	 * because get_user_pages() may need to cause an early COW in
 +	 * order to avoid confusing the normal COW routines. So only
 +	 * targets that are already writable are safe to do by just
 +	 * looking at the page tables.
  	 */
  	if (IS_ENABLED(CONFIG_HAVE_FAST_GUP) &&
  	    gup_fast_permitted(start, end)) {
- 		local_irq_disable();
+ 		local_irq_save(flags);
 -		gup_pgd_range(addr, end, gup_flags, pages, &nr_pinned);
 +		gup_pgd_range(addr, end, gup_flags | FOLL_WRITE, pages, &nr_pinned);
- 		local_irq_enable();
+ 		local_irq_restore(flags);
  		ret = nr_pinned;
  	}
  
@@@ -2848,6 -2781,46 +2808,50 @@@
  	return ret;
  }
  
+ /*
+  * Like get_user_pages_fast() except it's IRQ-safe in that it won't fall back to
+  * the regular GUP.
+  * Note a difference with get_user_pages_fast: this always returns the
+  * number of pages pinned, 0 if no pages were pinned.
+  *
+  * If the architecture does not support this function, simply return with no
+  * pages pinned.
++ *
++ * Careful, careful! COW breaking can go either way, so a non-write
++ * access can get ambiguous page results. If you call this function without
++ * 'write' set, you'd better be sure that you're ok with that ambiguity.
+  */
+ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
+ 			  struct page **pages)
+ {
+ 	int nr_pinned;
+ 	/*
+ 	 * Internally (within mm/gup.c), gup fast variants must set FOLL_GET,
+ 	 * because gup fast is always a "pin with a +1 page refcount" request.
+ 	 *
+ 	 * FOLL_FAST_ONLY is required in order to match the API description of
+ 	 * this routine: no fall back to regular ("slow") GUP.
+ 	 */
+ 	unsigned int gup_flags = FOLL_GET | FOLL_FAST_ONLY;
+ 
+ 	if (write)
+ 		gup_flags |= FOLL_WRITE;
+ 
+ 	nr_pinned = internal_get_user_pages_fast(start, nr_pages, gup_flags,
+ 						 pages);
+ 	/*
+ 	 * As specified in the API description above, this routine is not
+ 	 * allowed to return negative values. However, the common core
+ 	 * routine internal_get_user_pages_fast() *can* return -errno.
+ 	 * Therefore, correct for that here:
+ 	 */
+ 	if (nr_pinned < 0)
+ 		nr_pinned = 0;
+ 
+ 	return nr_pinned;
+ }
+ EXPORT_SYMBOL_GPL(__get_user_pages_fast);
+ 
  /**
   * get_user_pages_fast() - pin user pages in memory
   * @start:      starting user address

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2020-06-03  7:53 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2020-06-03  7:53 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Linus Torvalds, John Hubbard

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

Hi all,

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

  drivers/gpu/drm/i915/gem/i915_gem_userptr.c

between commit:

  17839856fd58 ("gup: document and work around "COW can break either way" issue")

from Linus' tree and commit:

  bca3ecd3b92c ("drm/i915: convert get_user_pages() --> pin_user_pages()")

from the akpm-current tree.

I fixed it up (I just used the akpm-current version for now) 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 --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with Linus' tree
  2019-02-18  6:51 Stephen Rothwell
@ 2019-02-20  1:00 ` Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2019-02-20  1:00 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Kees Cook

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

Hi all,

On Mon, 18 Feb 2019 17:51:20 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2019-02-18  6:51 Stephen Rothwell
  2019-02-20  1:00 ` Stephen Rothwell
  0 siblings, 1 reply; 43+ messages in thread
From: Stephen Rothwell @ 2019-02-18  6:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Kees Cook

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

Hi all,

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.

I fixed it up (I just used the latter version) 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 --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with Linus' tree
  2019-01-11  2:51 Stephen Rothwell
@ 2019-01-11 15:08 ` Jerome Glisse
  0 siblings, 0 replies; 43+ messages in thread
From: Jerome Glisse @ 2019-01-11 15:08 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Sean Christopherson

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..000000000000
> --- 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(&range, vma->vm_mm, vma->vm_start,
>  -				min(vma->vm_end, vma->vm_start +
>  +	mmu_notifier_range_init(&range, 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



^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2019-01-11  2:51 Stephen Rothwell
  2019-01-11 15:08 ` Jerome Glisse
  0 siblings, 1 reply; 43+ messages in thread
From: Stephen Rothwell @ 2019-01-11  2:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Sean Christopherson, Jérôme Glisse

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

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.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/rmap.c
index 0454ecc29537,62e47f3462cf..000000000000
--- 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(&range, vma->vm_mm, vma->vm_start,
 -				min(vma->vm_end, vma->vm_start +
 +	mmu_notifier_range_init(&range, 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

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2019-01-07  2:16 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2019-01-07  2:16 UTC (permalink / raw)
  To: Andrew Morton, Linus Torvalds
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Huang Ying

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

Hi all,

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

  mm/mincore.c

between commit:

  574823bfab82 ("Change mincore() to count "mapped" pages rather than "cached" pages")

from Linus' tree and commit:

  86ee23ad82b6 ("mm: fix race between swapoff and mincore")

from the akpm-current tree.

I fixed it up (the former removed the code modified by the latter) 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 --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2018-08-15  8:05 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2018-08-15  8:05 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andi Kleen,
	Thomas Gleixner, Jiri Kosina, Luis R. Rodriguez

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

Hi all,

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

  include/asm-generic/pgtable.h

between commits:

  42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")
  6c26fcd2abfe ("x86/speculation/l1tf: Unbreak !__HAVE_ARCH_PFN_MODIFY_ALLOWED architectures")

from Linus' tree and commit:

  c235da45bb89 ("mm: provide a fallback for PAGE_KERNEL_RO for architectures")

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 include/asm-generic/pgtable.h
index a75cb371cd19,81371468ed5a..000000000000
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@@ -1083,18 -1083,24 +1083,36 @@@ int phys_mem_access_prot_allowed(struc
  static inline void init_espfix_bsp(void) { }
  #endif
  
 +#ifndef __HAVE_ARCH_PFN_MODIFY_ALLOWED
 +static inline bool pfn_modify_allowed(unsigned long pfn, pgprot_t prot)
 +{
 +	return true;
 +}
 +
 +static inline bool arch_has_pfn_modify_check(void)
 +{
 +	return false;
 +}
 +#endif /* !_HAVE_ARCH_PFN_MODIFY_ALLOWED */
 +
+ /*
+  * Architecture PAGE_KERNEL_* fallbacks
+  *
+  * Some architectures don't define certain PAGE_KERNEL_* flags. This is either
+  * because they really don't support them, or the port needs to be updated to
+  * reflect the required functionality. Below are a set of relatively safe
+  * fallbacks, as best effort, which we can count on in lieu of the architectures
+  * not defining them on their own yet.
+  */
+ 
+ #ifndef PAGE_KERNEL_RO
+ # define PAGE_KERNEL_RO PAGE_KERNEL
+ #endif
+ 
+ #ifndef PAGE_KERNEL_EXEC
+ # define PAGE_KERNEL_EXEC PAGE_KERNEL
+ #endif
+ 
  #endif /* !__ASSEMBLY__ */
  
  #ifndef io_remap_pfn_range

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2018-07-23  8:00 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2018-07-23  8:00 UTC (permalink / raw)
  To: Andrew Morton, Linus Torvalds
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kirill A. Shutemov

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

Hi all,

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

  mm/mmap.c

between commit:

  490fc053865c ("mm: make vm_area_alloc() initialize core fields")

from Linus' tree and commit:

  97478b56e246 ("mm: Fix vma_is_anonymous() false-positives")

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 mm/mmap.c
index ff1944d8d458,b9636fa18f3c..000000000000
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@@ -2983,6 -3001,9 +2994,7 @@@ static int do_brk_flags(unsigned long a
  		return -ENOMEM;
  	}
  
 -	INIT_LIST_HEAD(&vma->anon_vma_chain);
 -	vma->vm_mm = mm;
+ 	vma->vm_ops = &anon_vm_ops;
  	vma->vm_start = addr;
  	vma->vm_end = addr + len;
  	vma->vm_pgoff = pgoff;

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2018-06-14  1:43 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2018-06-14  1:43 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kees Cook,
	Guozhonghua

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

Hi Andrew,

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

  fs/ocfs2/journal.c

between commit:

  6396bb221514 ("treewide: kzalloc() -> kcalloc()")

from Linus' tree and commits:

  18dc5b7810ff ("ocfs2: without quota support, avoid calling quota recovery")
  aa935a9c155b ("ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery-checkpatch-fixes")

from the akpm-current tree.

I fixed it up (the latter akpm-current commit also did the kzalloc to
kcalloc conversion, so I just used that version) 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 --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2018-06-14  1:36 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2018-06-14  1:36 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Alexey Dobriyan, Kees Cook

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

Hi Andrew,

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

  fs/binfmt_elf.c

between commit:

  42bc47b35320 ("treewide: Use array_size() in vmalloc()")

from Linus' tree and commit:

  1d5239111f52 ("coredump: fix spam with zero VMA process")

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 fs/binfmt_elf.c
index 070b6184642d,8676bb01b5a9..000000000000
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@@ -2294,8 -2294,8 +2294,8 @@@ static int elf_core_dump(struct coredum
  
  	if (segs - 1 > ULONG_MAX / sizeof(*vma_filesz))
  		goto end_coredump;
- 	vma_filesz = vmalloc(array_size(sizeof(*vma_filesz), (segs - 1)));
- 	if (!vma_filesz)
 -	vma_filesz = kvmalloc((segs - 1) * sizeof(*vma_filesz), GFP_KERNEL);
++	vma_filesz = kvmalloc(array_size(sizeof(*vma_filesz), (segs - 1)), GFP_KERNEL);
+ 	if (ZERO_OR_NULL_PTR(vma_filesz))
  		goto end_coredump;
  
  	for (i = 0, vma = first_vma(current, gate_vma); vma != NULL;

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2018-03-16  5:56 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2018-03-16  5:56 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Ard Biesheuvel

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

Hi Andrew,

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

  mm/page_alloc.c

between commit:

  3e04040df6d4 ("Revert "mm/page_alloc: fix memmap_init_zone pageblock alignment"")

from Linus' tree and commit:

  45251b0909dc ("mm: remove unused arg from memblock_next_valid_pfn()")

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 mm/page_alloc.c
index b32488f10a46,3f9cb47974ed..000000000000
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@@ -5361,9 -5487,14 +5489,9 @@@ void __meminit memmap_init_zone(unsigne
  			/*
  			 * Skip to the pfn preceding the next valid one (or
  			 * end_pfn), such that we hit a valid pfn (or end_pfn)
 -			 * on our next iteration of the loop. Note that it needs
 -			 * to be pageblock aligned even when the region itself
 -			 * is not. move_freepages_block() can shift ahead of
 -			 * the valid region but still depends on correct page
 -			 * metadata.
 +			 * on our next iteration of the loop.
  			 */
- 			pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
 -			pfn = (memblock_next_valid_pfn(pfn) &
 -					~(pageblock_nr_pages-1)) - 1;
++			pfn = memblock_next_valid_pfn(pfn) - 1;
  #endif
  			continue;
  		}

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2017-11-02  8:10 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2017-11-02  8:10 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Eric Dumazet,
	David S. Miller, Sasha Levin

Hi Andrew,

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

  net/ipv4/tcp_input.c

between commit:

  c92e8c02fe66 ("tcp/dccp: fix ireq->opt races")

from Linus' tree and commit:

  8a3e1a11b8af ("kmemcheck: remove annotations")

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 net/ipv4/tcp_input.c
index e7a426ceafca,4d2e31273a25..000000000000
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@@ -6179,8 -6195,7 +6179,7 @@@ struct request_sock *inet_reqsk_alloc(c
  	if (req) {
  		struct inet_request_sock *ireq = inet_rsk(req);
  
- 		kmemcheck_annotate_bitfield(ireq, flags);
 -		ireq->opt = NULL;
 +		ireq->ireq_opt = NULL;
  #if IS_ENABLED(CONFIG_IPV6)
  		ireq->pktopts = NULL;
  #endif

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2017-11-02  7:37 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2017-11-02  7:37 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mel Gorman,
	Jakub Kicinski, David S. Miller

Hi Andrew,

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

  drivers/net/ethernet/netronome/nfp/nfp_net_common.c

between commit:

  5f0ca2fb71e2 ("nfp: handle page allocation failures")

from Linus' tree and commit:

  0432d14c45bb ("mm: remove __GFP_COLD")

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 drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index eddf850a6a7f,6364c9a7a372..000000000000
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@@ -1180,14 -1180,10 +1180,14 @@@ static void *nfp_net_rx_alloc_one(struc
  {
  	void *frag;
  
 -	if (!dp->xdp_prog)
 +	if (!dp->xdp_prog) {
  		frag = netdev_alloc_frag(dp->fl_bufsz);
 -	else
 -		frag = page_address(alloc_page(GFP_KERNEL));
 +	} else {
 +		struct page *page;
 +
- 		page = alloc_page(GFP_KERNEL | __GFP_COLD);
++		page = alloc_page(GFP_KERNEL);
 +		frag = page ? page_address(page) : NULL;
 +	}
  	if (!frag) {
  		nn_dp_warn(dp, "Failed to alloc receive page frag\n");
  		return NULL;
@@@ -1207,14 -1203,10 +1207,14 @@@ static void *nfp_net_napi_alloc_one(str
  {
  	void *frag;
  
 -	if (!dp->xdp_prog)
 +	if (!dp->xdp_prog) {
  		frag = napi_alloc_frag(dp->fl_bufsz);
 -	else
 -		frag = page_address(alloc_page(GFP_ATOMIC));
 +	} else {
 +		struct page *page;
 +
- 		page = alloc_page(GFP_ATOMIC | __GFP_COLD);
++		page = alloc_page(GFP_ATOMIC);
 +		frag = page ? page_address(page) : NULL;
 +	}
  	if (!frag) {
  		nn_dp_warn(dp, "Failed to alloc receive page frag\n");
  		return NULL;

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2017-05-08  3:48 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2017-05-08  3:48 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Stafford Horne, Daniel Thompson

Hi Andrew,

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

  init/initramfs.c

between commit:

  17a9be317475 ("initramfs: Always do fput() and load modules after rootfs populate")

from Linus' tree and commit:

  c25cfb52513b ("initramfs: provide a way to ignore image provided by bootloader")

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 init/initramfs.c
index 8daf7ac6c7e2,a5b686696535..000000000000
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@@ -612,8 -611,7 +612,8 @@@ static int __init populate_rootfs(void
  	char *err = unpack_to_rootfs(__initramfs_start, __initramfs_size);
  	if (err)
  		panic("%s", err); /* Failed to decompress INTERNAL initramfs */
 +	/* If available load the bootloader supplied initrd */
- 	if (initrd_start) {
+ 	if (initrd_start && !IS_ENABLED(CONFIG_INITRAMFS_FORCE)) {
  #ifdef CONFIG_BLK_DEV_RAM
  		int fd;
  		printk(KERN_INFO "Trying to unpack rootfs image as initramfs...\n");

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with Linus' tree
  2017-04-24  7:25 Stephen Rothwell
@ 2017-04-24  9:11 ` Mel Gorman
  0 siblings, 0 replies; 43+ messages in thread
From: Mel Gorman @ 2017-04-24  9:11 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List, Johannes Weiner,
	Jesper Dangaard Brouer

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2017-04-24  7:25 Stephen Rothwell
  2017-04-24  9:11 ` Mel Gorman
  0 siblings, 1 reply; 43+ messages in thread
From: Stephen Rothwell @ 2017-04-24  7:25 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mel Gorman,
	Johannes Weiner, Jesper Dangaard Brouer

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.

Given the comments in the former revert, I effectively reverted
f4881295a79e and e2f499864da5 and fixed the rest up (hopefully).

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 mm/page_alloc.c
index d431a46b4139,3c1a977b7d21..000000000000
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@@ -1091,15 -1090,11 +1091,10 @@@ static void free_pcppages_bulk(struct z
  {
  	int migratetype = 0;
  	int batch_free = 0;
- 	unsigned long nr_scanned;
 -	unsigned long flags;
  	bool isolated_pageblocks;
  
 -	spin_lock_irqsave(&zone->lock, flags);
 +	spin_lock(&zone->lock);
  	isolated_pageblocks = has_isolate_pageblock(zone);
- 	nr_scanned = node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED);
- 	if (nr_scanned)
- 		__mod_node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED, -nr_scanned);
- 
  	while (count) {
  		struct page *page;
  		struct list_head *list;
@@@ -1151,12 -1146,10 +1146,8 @@@ static void free_one_page(struct zone *
  				unsigned int order,
  				int migratetype)
  {
- 	unsigned long nr_scanned;
 -	unsigned long flags;
 -
 -	spin_lock_irqsave(&zone->lock, flags);
 +	spin_lock(&zone->lock);
- 	nr_scanned = node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED);
- 	if (nr_scanned)
- 		__mod_node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED, -nr_scanned);
- 
+ 	__count_vm_events(PGFREE, 1 << order);
  	if (unlikely(has_isolate_pageblock(zone) ||
  		is_migrate_isolate(migratetype))) {
  		migratetype = get_pfnblock_migratetype(page, pfn);

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with Linus' tree
  2016-12-05  5:56 ` Michal Hocko
@ 2016-12-05  6:08   ` Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2016-12-05  6:08 UTC (permalink / raw)
  To: Michal Hocko; +Cc: Andrew Morton, linux-next, linux-kernel, Johannes Weiner

Hi Michal,

On Mon, 5 Dec 2016 06:56:56 +0100 Michal Hocko <mhocko@kernel.org> 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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with Linus' tree
  2016-12-05  5:38 Stephen Rothwell
@ 2016-12-05  5:56 ` Michal Hocko
  2016-12-05  6:08   ` Stephen Rothwell
  0 siblings, 1 reply; 43+ messages in thread
From: Michal Hocko @ 2016-12-05  5:56 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Johannes Weiner

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2016-12-05  5:38 Stephen Rothwell
  2016-12-05  5:56 ` Michal Hocko
  0 siblings, 1 reply; 43+ messages in thread
From: Stephen Rothwell @ 2016-12-05  5:38 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Michal Hocko, Johannes Weiner

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, 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 mm/workingset.c
index fb1f9183d89a,02ab8746abde..000000000000
--- 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,

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2016-01-18  3:22 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2016-01-18  3:22 UTC (permalink / raw)
  To: Andrew Morton, Linus Torvalds
  Cc: linux-next, linux-kernel, Kirill A. Shutemov

Hi Andrew,

Today's linux-next merge of the akpm-current tree got lost of conflicts in:

  mm/huge_memory.c

between various commits in Linus' tree and the same or similar patches
in the akpm-current tree along with further changes to this file.

I can't possibly fix it up, so I just dropped the akpm-current tree
for today.

I do wish that you would publish your patch set for me just as you intend
to send it to Linus. :-(  I also wonder at how much exposure and testing
the subset that you have sent to Linus has had on it own given that the
version I have is from Jan 12.

Sorry, but I seem to end up in this mess almost every merge window.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2015-12-18  5:09 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2015-12-18  5:09 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Dan Williams

Hi Andrew,

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

  arch/arm/mm/dma-mapping.c
  drivers/iommu/intel-iommu.c
  drivers/staging/android/ion/ion_chunk_heap.c

between commit:

  3e6110fd5480 ("Revert "scatterlist: use sg_phys()"")

from Linus' tree and commit:

  0504b8687491 ("scatterlist: fix sg_phys() masking")

from the akpm-current tree.

I fixed it up (I use the Linus' tree version for now, effectively removing
the whole of the akpm-current tree patch) and can carry the fix as
necessary (no action is required).

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2015-10-06  5:46 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2015-10-06  5:46 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Eric B Munson, Ralf Baechle

Hi Andrew,

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

  arch/mips/include/uapi/asm/unistd.h
  arch/mips/kernel/scall32-o32.S
  arch/mips/kernel/scall64-n32.S
  arch/mips/kernel/scall64-64.S
  arch/mips/kernel/scall64-o32.S

between commit:

  96fc7a9cee67 ("MIPS: Wire up userfaultfd and membarrier syscalls.")

from Linus' tree and commit:

  4f9b011b10e7 ("mips: add entry for new mlock2 syscall")

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 arch/mips/include/uapi/asm/unistd.h
index cfabadb135d9,d0bdfaa13ee9..000000000000
--- a/arch/mips/include/uapi/asm/unistd.h
+++ b/arch/mips/include/uapi/asm/unistd.h
@@@ -377,18 -377,17 +377,19 @@@
  #define __NR_memfd_create		(__NR_Linux + 354)
  #define __NR_bpf			(__NR_Linux + 355)
  #define __NR_execveat			(__NR_Linux + 356)
 -#define __NR_mlock2			(__NR_Linux + 357)
 +#define __NR_userfaultfd		(__NR_Linux + 357)
 +#define __NR_membarrier			(__NR_Linux + 358)
++#define __NR_mlock2			(__NR_Linux + 359)
  
  /*
   * Offset of the last Linux o32 flavoured syscall
   */
- #define __NR_Linux_syscalls		358
 -#define __NR_Linux_syscalls		357
++#define __NR_Linux_syscalls		359
  
  #endif /* _MIPS_SIM == _MIPS_SIM_ABI32 */
  
  #define __NR_O32_Linux			4000
- #define __NR_O32_Linux_syscalls		358
 -#define __NR_O32_Linux_syscalls		357
++#define __NR_O32_Linux_syscalls		359
  
  #if _MIPS_SIM == _MIPS_SIM_ABI64
  
@@@ -713,18 -712,17 +714,19 @@@
  #define __NR_memfd_create		(__NR_Linux + 314)
  #define __NR_bpf			(__NR_Linux + 315)
  #define __NR_execveat			(__NR_Linux + 316)
 -#define __NR_mlock2			(__NR_Linux + 317)
 +#define __NR_userfaultfd		(__NR_Linux + 317)
 +#define __NR_membarrier			(__NR_Linux + 318)
++#define __NR_mlock2			(__NR_Linux + 319)
  
  /*
   * Offset of the last Linux 64-bit flavoured syscall
   */
- #define __NR_Linux_syscalls		318
 -#define __NR_Linux_syscalls		317
++#define __NR_Linux_syscalls		319
  
  #endif /* _MIPS_SIM == _MIPS_SIM_ABI64 */
  
  #define __NR_64_Linux			5000
- #define __NR_64_Linux_syscalls		318
 -#define __NR_64_Linux_syscalls		317
++#define __NR_64_Linux_syscalls		319
  
  #if _MIPS_SIM == _MIPS_SIM_NABI32
  
@@@ -1053,17 -1051,16 +1055,18 @@@
  #define __NR_memfd_create		(__NR_Linux + 318)
  #define __NR_bpf			(__NR_Linux + 319)
  #define __NR_execveat			(__NR_Linux + 320)
 -#define __NR_mlock2			(__NR_Linux + 321)
 +#define __NR_userfaultfd		(__NR_Linux + 321)
 +#define __NR_membarrier			(__NR_Linux + 322)
++#define __NR_mlock2			(__NR_Linux + 323)
  
  /*
   * Offset of the last N32 flavoured syscall
   */
- #define __NR_Linux_syscalls		322
 -#define __NR_Linux_syscalls		321
++#define __NR_Linux_syscalls		323
  
  #endif /* _MIPS_SIM == _MIPS_SIM_NABI32 */
  
  #define __NR_N32_Linux			6000
- #define __NR_N32_Linux_syscalls		322
 -#define __NR_N32_Linux_syscalls		321
++#define __NR_N32_Linux_syscalls		323
  
  #endif /* _UAPI_ASM_UNISTD_H */
diff --cc arch/mips/kernel/scall32-o32.S
index 65a74e4f0f45,b0b377aa1d5d..000000000000
--- a/arch/mips/kernel/scall32-o32.S
+++ b/arch/mips/kernel/scall32-o32.S
@@@ -592,5 -599,4 +592,6 @@@ EXPORT(sys_call_table
  	PTR	sys_memfd_create
  	PTR	sys_bpf				/* 4355 */
  	PTR	sys_execveat
 +	PTR	sys_userfaultfd
 +	PTR	sys_membarrier
+ 	PTR	sys_mlock2
diff --cc arch/mips/kernel/scall64-64.S
index e732981cf99f,f12eb03c0961..000000000000
--- a/arch/mips/kernel/scall64-64.S
+++ b/arch/mips/kernel/scall64-64.S
@@@ -430,6 -436,5 +430,7 @@@ EXPORT(sys_call_table
  	PTR	sys_memfd_create
  	PTR	sys_bpf				/* 5315 */
  	PTR	sys_execveat
 +	PTR	sys_userfaultfd
 +	PTR	sys_membarrier
+ 	PTR	sys_mlock2
  	.size	sys_call_table,.-sys_call_table
diff --cc arch/mips/kernel/scall64-n32.S
index c79484397584,ecdd65a2b02c..000000000000
--- a/arch/mips/kernel/scall64-n32.S
+++ b/arch/mips/kernel/scall64-n32.S
@@@ -420,6 -429,5 +420,7 @@@ EXPORT(sysn32_call_table
  	PTR	sys_memfd_create
  	PTR	sys_bpf
  	PTR	compat_sys_execveat		/* 6320 */
 +	PTR	sys_userfaultfd
 +	PTR	sys_membarrier
+ 	PTR	sys_mlock2
  	.size	sysn32_call_table,.-sysn32_call_table
diff --cc arch/mips/kernel/scall64-o32.S
index 6369cfd390c6,7a8b2dff16d3..000000000000
--- a/arch/mips/kernel/scall64-o32.S
+++ b/arch/mips/kernel/scall64-o32.S
@@@ -575,6 -584,5 +575,7 @@@ EXPORT(sys32_call_table
  	PTR	sys_memfd_create
  	PTR	sys_bpf				/* 4355 */
  	PTR	compat_sys_execveat
 +	PTR	sys_userfaultfd
 +	PTR	sys_membarrier
+ 	PTR	sys_mlock2
  	.size	sys32_call_table,.-sys32_call_table

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2015-07-20  3:54 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2015-07-20  3:54 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Ingo Molnar, Mel Gorman

Hi Andrew,

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

  arch/x86/Kconfig

between commit:

  5aaeb5c01c5b ("x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86")

from Linus' tree and commit:

  caf50fadb4de ("mm: send one IPI per CPU to TLB flush all entries after unmapping pages")

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 arch/x86/Kconfig
index 6c80c03d8e90,d9a83b54d86a..000000000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -41,7 -41,7 +41,8 @@@ config X8
  	select ARCH_USE_CMPXCHG_LOCKREF		if X86_64
  	select ARCH_USE_QUEUED_RWLOCKS
  	select ARCH_USE_QUEUED_SPINLOCKS
 +	select ARCH_WANTS_DYNAMIC_TASK_STRUCT
+ 	select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH if SMP
  	select ARCH_WANT_FRAME_POINTERS
  	select ARCH_WANT_IPC_PARSE_VERSION	if X86_32
  	select ARCH_WANT_OPTIONAL_GPIOLIB

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2015-05-19  6:40 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2015-05-19  6:40 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Peter Zijlstra, Ulrich Obergfell, Don Zickus

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
kernel/watchdog.c between commit ab992dc38f9a ("watchdog: Fix merge
'conflict'") from Linus' tree and commit fbfec4606e07
("kernel/watchdog.c: fix watchdog_nmi_enable_all()") from the
akpm-current tree.

I fixed it up (the latter is a subset of the former, so I used that -
see below) and can carry the fix as necessary (no action is required).

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

diff --cc kernel/watchdog.c
index 506edcc500c4,93ef2bad457c..000000000000
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@@ -610,36 -615,26 +617,36 @@@ void watchdog_nmi_enable_all(void
  {
  	int cpu;
  
 +	mutex_lock(&watchdog_proc_mutex);
 +
  	if (!(watchdog_enabled & NMI_WATCHDOG_ENABLED))
 -		return;
 +		goto unlock;
  
  	get_online_cpus();
- 	for_each_online_cpu(cpu)
+ 	for_each_watchdog_cpu(cpu)
  		watchdog_nmi_enable(cpu);
  	put_online_cpus();
 +
 +unlock:
 +	mutex_lock(&watchdog_proc_mutex);
  }
  
  void watchdog_nmi_disable_all(void)
  {
  	int cpu;
  
 +	mutex_lock(&watchdog_proc_mutex);
 +
  	if (!watchdog_running)
 -		return;
 +		goto unlock;
  
  	get_online_cpus();
- 	for_each_online_cpu(cpu)
+ 	for_each_watchdog_cpu(cpu)
  		watchdog_nmi_disable(cpu);
  	put_online_cpus();
 +
 +unlock:
 +	mutex_unlock(&watchdog_proc_mutex);
  }
  #else
  static int watchdog_nmi_enable(unsigned int cpu) { return 0; }

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2014-08-08  5:46 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2014-08-08  5:46 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Johannes Weiner

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
mm/memcontrol.c between commit 61e02c745721 ("mm: memcontrol: clean up
reclaim size variable use in try_charge()") from Linus' tree and
various commits from the akpm-current tree.

I fixed it up (I think) and can carry the fix as necessary (no action
is required).

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

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2014-08-07  6:51 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2014-08-07  6:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Sven Eckelmann, Antonio Quartulli,
	Marek Lindner, Ken Helias

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
net/batman-adv/fragmentation.c between commit d9124268d84a
("batman-adv: Fix out-of-order fragmentation support") from Linus' tree
and commit ffe04af00b27 ("list: fix order of arguments for
hlist_add_after(_rcu)") 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 net/batman-adv/fragmentation.c
index 022d18ab27a6,16dd40910c65..000000000000
--- a/net/batman-adv/fragmentation.c
+++ b/net/batman-adv/fragmentation.c
@@@ -181,14 -180,11 +181,14 @@@ static bool batadv_frag_insert_packet(s
  			ret = true;
  			goto out;
  		}
 +
 +		/* store current entry because it could be the last in list */
 +		frag_entry_last = frag_entry_curr;
  	}
  
 -	/* Reached the end of the list, so insert after 'frag_entry_curr'. */
 -	if (likely(frag_entry_curr)) {
 -		hlist_add_behind(&frag_entry_new->list, &frag_entry_curr->list);
 +	/* Reached the end of the list, so insert after 'frag_entry_last'. */
 +	if (likely(frag_entry_last)) {
- 		hlist_add_after(&frag_entry_last->list, &frag_entry_new->list);
++		hlist_add_behind(&frag_entry_new->list, &frag_entry_last->list);
  		chain->size += skb->len - hdr_size;
  		chain->timestamp = jiffies;
  		ret = true;

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2014-05-29  9:08 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2014-05-29  9:08 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Srivatsa S. Bhat,
	Benjamin Herrenschmidt, Fabian Frederick

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
kernel/kexec.c between commit 011e4b02f1da ("powerpc, kexec: Fix
"Processor X is stuck" issue during kexec from ST mode") from Linus'
tree and commit 51950fcb6d27 ("kernel/kexec.c: convert printk to
pr_foo()") 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 kernel/kexec.c
index 28c57069ef68,bf0b929e7f94..000000000000
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@@ -1683,15 -1679,7 +1679,15 @@@ int kernel_kexec(void
  		kexec_in_progress = true;
  		kernel_restart_prepare(NULL);
  		migrate_to_reboot_cpu();
 +
 +		/*
 +		 * migrate_to_reboot_cpu() disables CPU hotplug assuming that
 +		 * no further code needs to use CPU hotplug (which is true in
 +		 * the reboot case). However, the kexec path depends on using
 +		 * CPU hotplug again; so re-enable it here.
 +		 */
 +		cpu_hotplug_enable();
- 		printk(KERN_EMERG "Starting new kernel\n");
+ 		pr_emerg("Starting new kernel\n");
  		machine_shutdown();
  	}
  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2014-04-29  4:47 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2014-04-29  4:47 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Davidlohr Bueso, Linus

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
mm/vmacache.c between commit 50f5aa8a9b24 ("mm: don't pointlessly use
BUG_ON() for sanity check") from Linus' tree and commit 8beba5473820
("mm,vmacache: add debug data") 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/vmacache.c
index 1037a3bab505,61c38ae9f54b..000000000000
--- a/mm/vmacache.c
+++ b/mm/vmacache.c
@@@ -81,12 -93,11 +93,14 @@@ struct vm_area_struct *vmacache_find(st
  	for (i = 0; i < VMACACHE_SIZE; i++) {
  		struct vm_area_struct *vma = current->vmacache[i];
  
 -		if (vma && vma->vm_start <= addr && vma->vm_end > addr) {
 -			BUG_ON(vma->vm_mm != mm);
 +		if (!vma)
 +			continue;
 +		if (WARN_ON_ONCE(vma->vm_mm != mm))
 +			break;
- 		if (vma->vm_start <= addr && vma->vm_end > addr)
++		if (vma->vm_start <= addr && vma->vm_end > addr) {
+ 			count_vm_vmacache_event(VMACACHE_FIND_HITS);
  			return vma;
+ 		}
  	}
  
  	return NULL;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2014-04-24  5:38 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2014-04-24  5:38 UTC (permalink / raw)
  To: Andrew Morton, Linus Torvalds
  Cc: linux-next, linux-kernel, Kirill A. Shutemov

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
mm/memory.c between commit 1b17844b29ae ("mm: make fixup_user_fault()
check the vma access rights too") from Linus' tree and commit
0d84be787c23 ("mm: move get_user_pages()-related code to separate file")
from the akpm-current tree.

I fixed it up (I applied Linus' patch to the new file) and can carry the
fix as necessary (no action is required).

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2014-01-29  3:46 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2014-01-29  3:46 UTC (permalink / raw)
  To: Andrew Morton, Al Viro
  Cc: linux-next, linux-kernel, Linus, "Pali Rohár"

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
fs/afs/proc.c between commit b42d570c9fbe ("afs: get rid of junk in
fs/afs/proc.c") from Linus' tree and commit 1a3459681f5c ("afs: proc
cells and rootcell are writeable") 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 fs/afs/proc.c
index bddc5120ed40,276cb6ed0b93..000000000000
--- a/fs/afs/proc.c
+++ b/fs/afs/proc.c
@@@ -130,9 -147,13 +130,9 @@@ int afs_proc_init(void
  	if (!proc_afs)
  		goto error_dir;
  
- 	if (!proc_create("cells", 0, proc_afs, &afs_proc_cells_fops) ||
- 	    !proc_create("rootcell", 0, proc_afs, &afs_proc_rootcell_fops))
 -	p = proc_create("cells", S_IFREG | S_IRUGO | S_IWUSR, proc_afs, &afs_proc_cells_fops);
 -	if (!p)
 -		goto error_cells;
 -
 -	p = proc_create("rootcell", S_IFREG | S_IRUGO | S_IWUSR, proc_afs, &afs_proc_rootcell_fops);
 -	if (!p)
 -		goto error_rootcell;
++	if (!proc_create("cells", S_IFREG | S_IRUGO | S_IWUSR, proc_afs, &afs_proc_cells_fops) ||
++	    !proc_create("rootcell", S_IFREG | S_IRUGO | S_IWUSR, proc_afs, &afs_proc_rootcell_fops))
 +		goto error_tree;
  
  	_leave(" = 0");
  	return 0;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2013-12-23  3:58 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2013-12-23  3:58 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Kirill A. Shutemov

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got conflicts in
include/linux/mm.h and mm/memory.c between commit 597d795a2a78 ("mm: do
not allocate page->ptl dynamically, if spinlock_t fits to long") from
the  tree and commit 489bd4be2d70 ("mm: create a separate slab for
page->ptl allocation") 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 include/linux/mm.h
index bf362d053ce1,1f232229a451..000000000000
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@@ -1317,7 -1355,8 +1355,8 @@@ static inline pmd_t *pmd_alloc(struct m
  #endif /* CONFIG_MMU && !__ARCH_HAS_4LEVEL_HACK */
  
  #if USE_SPLIT_PTE_PTLOCKS
 -#if BLOATED_SPINLOCKS
 +#if ALLOC_SPLIT_PTLOCKS
+ void __init ptlock_cache_init(void);
  extern bool ptlock_alloc(struct page *page);
  extern void ptlock_free(struct page *page);
  
@@@ -1325,7 -1364,8 +1364,8 @@@ static inline spinlock_t *ptlock_ptr(st
  {
  	return page->ptl;
  }
 -#else /* BLOATED_SPINLOCKS */
 +#else /* ALLOC_SPLIT_PTLOCKS */
+ static inline void ptlock_cache_init(void) {}
  static inline bool ptlock_alloc(struct page *page)
  {
  	return true;
diff --cc mm/memory.c
index 6768ce9e57d2,cf6098c10084..000000000000
--- a/mm/memory.c
+++ b/mm/memory.c
@@@ -4271,7 -4271,14 +4271,14 @@@ void copy_user_huge_page(struct page *d
  }
  #endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_HUGETLBFS */
  
 -#if USE_SPLIT_PTE_PTLOCKS && BLOATED_SPINLOCKS
 +#if USE_SPLIT_PTE_PTLOCKS && ALLOC_SPLIT_PTLOCKS
+ static struct kmem_cache *page_ptl_cachep;
+ void __init ptlock_cache_init(void)
+ {
+ 	page_ptl_cachep = kmem_cache_create("page->ptl", sizeof(spinlock_t), 0,
+ 			SLAB_PANIC, NULL);
+ }
+ 
  bool ptlock_alloc(struct page *page)
  {
  	spinlock_t *ptl;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with Linus' tree
  2013-12-03  7:31   ` Andrew Morton
@ 2013-12-03  7:36     ` Richard Weinberger
  0 siblings, 0 replies; 43+ messages in thread
From: Richard Weinberger @ 2013-12-03  7:36 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Stephen Rothwell, linux-next, linux-kernel

Am Montag, 2. Dezember 2013, 23:31:31 schrieb Andrew Morton:
> On Tue, 03 Dec 2013 08:16:04 +0100 Richard Weinberger <richard@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:richrd@nod.at ;)

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

Thanks,
//richard

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with Linus' tree
  2013-12-03  7:16 ` Richard Weinberger
@ 2013-12-03  7:31   ` Andrew Morton
  2013-12-03  7:36     ` Richard Weinberger
  0 siblings, 1 reply; 43+ messages in thread
From: Andrew Morton @ 2013-12-03  7:31 UTC (permalink / raw)
  To: Richard Weinberger; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Tue, 03 Dec 2013 08:16:04 +0100 Richard Weinberger <richard@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:richrd@nod.at ;)


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with Linus' tree
  2013-12-03  1:52 Stephen Rothwell
@ 2013-12-03  7:16 ` Richard Weinberger
  2013-12-03  7:31   ` Andrew Morton
  0 siblings, 1 reply; 43+ messages in thread
From: Richard Weinberger @ 2013-12-03  7:16 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2013-12-03  1:52 Stephen Rothwell
  2013-12-03  7:16 ` Richard Weinberger
  0 siblings, 1 reply; 43+ messages in thread
From: Stephen Rothwell @ 2013-12-03  1:52 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Richard Weinberger

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

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* linux-next: manual merge of the akpm-current tree with Linus' tree
@ 2013-02-02 12:55 Stephen Rothwell
  0 siblings, 0 replies; 43+ messages in thread
From: Stephen Rothwell @ 2013-02-02 12:55 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Shaohua Li, Wang YanQing, Ingo Molnar

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
kernel/smp.c between commit f44310b98ddb ("smp: Fix SMP function call
empty cpu mask race") from Linus' tree and commit "smp: make
smp_call_function_many() use logic similar to smp_call_function_single()"
from the akpm-current tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

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

diff --cc kernel/smp.c
index 69f38bd,bb92c52..0000000
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@@ -57,9 -47,11 +47,15 @@@ hotplug_cfd(struct notifier_block *nfb
  		if (!zalloc_cpumask_var_node(&cfd->cpumask, GFP_KERNEL,
  				cpu_to_node(cpu)))
  			return notifier_from_errno(-ENOMEM);
 +		if (!zalloc_cpumask_var_node(&cfd->cpumask_ipi, GFP_KERNEL,
 +				cpu_to_node(cpu)))
 +			return notifier_from_errno(-ENOMEM);
+ 		cfd->csd = alloc_percpu(struct call_single_data);
+ 		if (!cfd->csd) {
++			free_cpumask_var(cfd->cpumask_ipi);
+ 			free_cpumask_var(cfd->cpumask);
+ 			return notifier_from_errno(-ENOMEM);
+ 		}
  		break;
  
  #ifdef CONFIG_HOTPLUG_CPU
@@@ -69,7 -61,7 +65,8 @@@
  	case CPU_DEAD:
  	case CPU_DEAD_FROZEN:
  		free_cpumask_var(cfd->cpumask);
 +		free_cpumask_var(cfd->cpumask_ipi);
+ 		free_percpu(cfd->csd);
  		break;
  #endif
  	};

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

end of thread, other threads:[~2022-04-11  3:36 UTC | newest]

Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-07  4:18 linux-next: manual merge of the akpm-current tree with Linus' tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2022-04-11  3:35 Stephen Rothwell
2021-04-06 11:29 Stephen Rothwell
2021-02-08 12:10 Stephen Rothwell
2020-09-08  9:24 Stephen Rothwell
2020-09-08  9:17 Stephen Rothwell
2020-06-03  8:07 Stephen Rothwell
2020-06-03  7:53 Stephen Rothwell
2019-02-18  6:51 Stephen Rothwell
2019-02-20  1:00 ` Stephen Rothwell
2019-01-11  2:51 Stephen Rothwell
2019-01-11 15:08 ` Jerome Glisse
2019-01-07  2:16 Stephen Rothwell
2018-08-15  8:05 Stephen Rothwell
2018-07-23  8:00 Stephen Rothwell
2018-06-14  1:43 Stephen Rothwell
2018-06-14  1:36 Stephen Rothwell
2018-03-16  5:56 Stephen Rothwell
2017-11-02  8:10 Stephen Rothwell
2017-11-02  7:37 Stephen Rothwell
2017-05-08  3:48 Stephen Rothwell
2017-04-24  7:25 Stephen Rothwell
2017-04-24  9:11 ` Mel Gorman
2016-12-05  5:38 Stephen Rothwell
2016-12-05  5:56 ` Michal Hocko
2016-12-05  6:08   ` Stephen Rothwell
2016-01-18  3:22 Stephen Rothwell
2015-12-18  5:09 Stephen Rothwell
2015-10-06  5:46 Stephen Rothwell
2015-07-20  3:54 Stephen Rothwell
2015-05-19  6:40 Stephen Rothwell
2014-08-08  5:46 Stephen Rothwell
2014-08-07  6:51 Stephen Rothwell
2014-05-29  9:08 Stephen Rothwell
2014-04-29  4:47 Stephen Rothwell
2014-04-24  5:38 Stephen Rothwell
2014-01-29  3:46 Stephen Rothwell
2013-12-23  3:58 Stephen Rothwell
2013-12-03  1:52 Stephen Rothwell
2013-12-03  7:16 ` Richard Weinberger
2013-12-03  7:31   ` Andrew Morton
2013-12-03  7:36     ` Richard Weinberger
2013-02-02 12:55 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).