linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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) pgpNfDytUTY0s.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 pgpiRbcFM8cSa.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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); pgpiCJMaJuhMI.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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' pgp6Sw1H0hc06.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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 pgpI8vs8FvWWb.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 pgpmxN1UbhEnC.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the akpm-current tree with Linus' tree
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
linux-next: manual merge of the akpm-current tree with Linus' tree
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 pgp7GznpF5oCc.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the akpm-current tree with Linus' tree
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(&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
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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 pgpBXmhUBegOj.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 pgpt4lRricZt6.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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 pgph3ASQM891B.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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; pgpw2PMrYI7s9.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 pgpk9bBQ_v7M9.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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; pgpx94IIfqTpX.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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; } pgpgmsmmRQ0kf.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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;
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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");
Re: linux-next: manual merge of the akpm-current tree with Linus' tree
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
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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);
Re: linux-next: manual merge of the akpm-current tree with Linus' tree
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
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
linux-next: manual merge of the akpm-current tree with Linus' tree
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.. --- 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,
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au diff --cc arch/mips/include/uapi/asm/unistd.h index cfabadb135d9,d0bdfaa13ee9.. --- 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_Linux4000 - #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_syscalls318 -#define __NR_64_Linux_syscalls317 ++#define __NR_64_Linux_syscalls319 #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_Linux6000 - #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.. --- 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.. --- 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.. --- 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
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au diff --cc arch/x86/Kconfig index 6c80c03d8e90,d9a83b54d86a.. --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au diff --cc kernel/watchdog.c index 506edcc500c4,93ef2bad457c.. --- 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; } pgpk_CcD0ZVUQ.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au diff --cc net/batman-adv/fragmentation.c index 022d18ab27a6,16dd40910c65.. --- 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; signature.asc Description: PGP signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au diff --cc kernel/kexec.c index 28c57069ef68,bf0b929e7f94.. --- 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(); } signature.asc Description: PGP signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au diff --cc mm/vmacache.c index 1037a3bab505,61c38ae9f54b.. --- 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; pgpRbXIX5O7gk.pgp Description: PGP signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au pgpPMW2p5Q_1I.pgp Description: PGP signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au pgp33dT7TVtQU.pgp Description: PGP signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au diff --cc fs/afs/proc.c index bddc5120ed40,276cb6ed0b93.. --- 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; pgpGgBgU8u0Ry.pgp Description: PGP signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au diff --cc include/linux/mm.h index bf362d053ce1,1f232229a451.. --- 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.. --- 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; pgpyTEPfX9vOe.pgp Description: PGP signature
Re: linux-next: manual merge of the akpm-current tree with Linus' tree
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
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
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/
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au pgpPng6LcvNVo.pgp Description: PGP signature
linux-next: manual merge of the akpm-current tree with Linus' tree
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 Rothwells...@canb.auug.org.au diff --cc kernel/smp.c index 69f38bd,bb92c52..000 --- 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 }; pgpzCl8jWhe9K.pgp Description: PGP signature