Re: [RFC 13/20] mm/tlb: introduce tlb_start_ptes() and tlb_end_ptes()

[Damian Tometzki]

On Sat, 30. Jan 16:11, Nadav Amit wrote:
> From: Nadav Amit 
> 
> Introduce tlb_start_ptes() and tlb_end_ptes() which would be called
> before and after PTEs are updated and TLB flushes are deferred. This
> will be later be used for fine granualrity deferred TLB flushing
> detection.
> 
> In the meanwhile, move flush_tlb_batched_pending() into
> tlb_start_ptes(). It was not called from mapping_dirty_helpers by
> wp_pte() and clean_record_pte(), which might be a bug.
> 
> No additional functional change is intended.
> 
> Signed-off-by: Nadav Amit 
> Cc: Andrea Arcangeli 
> Cc: Andrew Morton 
> Cc: Andy Lutomirski 
> Cc: Dave Hansen 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: Will Deacon 
> Cc: Yu Zhao 
> Cc: Nick Piggin 
> Cc: x...@kernel.org
> ---
>  fs/proc/task_mmu.c |  2 ++
>  include/asm-generic/tlb.h  | 18 ++
>  mm/madvise.c   |  6 --
>  mm/mapping_dirty_helpers.c | 15 +--
>  mm/memory.c|  2 ++
>  mm/mprotect.c  |  3 ++-
>  6 files changed, 41 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 4cd048ffa0f6..d0cce961fa5c 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1168,6 +1168,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned 
> long addr,
>   return 0;
>  
>   pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, );
> + tlb_start_ptes(>tlb);
>   for (; addr != end; pte++, addr += PAGE_SIZE) {
>   ptent = *pte;
>  
> @@ -1190,6 +1191,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned 
> long addr,
>   tlb_flush_pte_range(>tlb, addr, PAGE_SIZE);
>   ClearPageReferenced(page);
>   }
> + tlb_end_ptes(>tlb);
>   pte_unmap_unlock(pte - 1, ptl);
>   cond_resched();
>   return 0;
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index 041be2ef4426..10690763090a 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -58,6 +58,11 @@
>   *Defaults to flushing at tlb_end_vma() to reset the range; helps when
>   *there's large holes between the VMAs.
>   *
> + *  - tlb_start_ptes() / tlb_end_ptes; makr the start / end of PTEs change.

Hello Nadav,

short nid makr/mark

Damian

> + *
> + *Does internal accounting to allow fine(r) granularity checks for
> + *pte_accessible() on certain configuration.
> + *
>   *  - tlb_remove_table()
>   *
>   *tlb_remove_table() is the basic primitive to free page-table 
> directories
> @@ -373,6 +378,10 @@ static inline void tlb_flush(struct mmu_gather *tlb)
>   flush_tlb_range(tlb->vma, tlb->start, tlb->end);
>   }
>  }
> +#endif
> +
> +#if __is_defined(tlb_flush) ||   
> \
> + IS_ENABLED(CONFIG_ARCH_WANT_AGGRESSIVE_TLB_FLUSH_BATCHING)
>  
>  static inline void
>  tlb_update_vma(struct mmu_gather *tlb, struct vm_area_struct *vma)
> @@ -523,6 +532,15 @@ static inline void mark_mm_tlb_gen_done(struct mm_struct 
> *mm, u64 gen)
>  
>  #endif /* CONFIG_ARCH_HAS_TLB_GENERATIONS */
>  
> +#define tlb_start_ptes(tlb)  \
> + do {\
> + struct mmu_gather *_tlb = (tlb);\
> + \
> + flush_tlb_batched_pending(_tlb->mm);\
> + } while (0)
> +
> +static inline void tlb_end_ptes(struct mmu_gather *tlb) { }
> +
>  /*
>   * tlb_flush_{pte|pmd|pud|p4d}_range() adjust the tlb->start and tlb->end,
>   * and set corresponding cleared_*.
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 0938fd3ad228..932c1c2eb9a3 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -392,7 +392,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  #endif
>   tlb_change_page_size(tlb, PAGE_SIZE);
>   orig_pte = pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, );
> - flush_tlb_batched_pending(mm);
> + tlb_start_ptes(tlb);
>   arch_enter_lazy_mmu_mode();
>   for (; addr < end; pte++, addr += PAGE_SIZE) {
>   ptent = *pte;
> @@ -468,6 +468,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>   }
>  
>   arch_leave_lazy_mmu_mode();
> + tlb_end_ptes(tlb);
>   pte_unmap_unlock(orig_pte, ptl);
>   if (pageout)
>   reclaim_pages(_list);
> @@ -588,7 +589,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned 
> long addr,
>  
>   tlb_change_page_size(tlb, PAGE_SIZE);
>   orig_pte = pte = pte_offset_map_lock(mm, pmd, addr, );
> - flush_tlb_batched_pending(mm);
> + tlb_start_ptes(tlb);
>   arch_enter_lazy_mmu_mode();
>   for (; addr != end; pte++, addr += PAGE_SIZE) {
>   ptent = *pte;
> @@ -692,6 +693,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned 
> long addr,
>   

Re: [RFC 13/20] mm/tlb: introduce tlb_start_ptes() and tlb_end_ptes()

[Damian Tometzki]

On Sat, 30. Jan 16:11, Nadav Amit wrote:
> From: Nadav Amit 
> 
> Introduce tlb_start_ptes() and tlb_end_ptes() which would be called
> before and after PTEs are updated and TLB flushes are deferred. This
> will be later be used for fine granualrity deferred TLB flushing
> detection.
> 
> In the meanwhile, move flush_tlb_batched_pending() into
> tlb_start_ptes(). It was not called from mapping_dirty_helpers by
> wp_pte() and clean_record_pte(), which might be a bug.
> 
> No additional functional change is intended.
> 
> Signed-off-by: Nadav Amit 
> Cc: Andrea Arcangeli 
> Cc: Andrew Morton 
> Cc: Andy Lutomirski 
> Cc: Dave Hansen 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: Will Deacon 
> Cc: Yu Zhao 
> Cc: Nick Piggin 
> Cc: x...@kernel.org
> ---
>  fs/proc/task_mmu.c |  2 ++
>  include/asm-generic/tlb.h  | 18 ++
>  mm/madvise.c   |  6 --
>  mm/mapping_dirty_helpers.c | 15 +--
>  mm/memory.c|  2 ++
>  mm/mprotect.c  |  3 ++-
>  6 files changed, 41 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 4cd048ffa0f6..d0cce961fa5c 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1168,6 +1168,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned 
> long addr,
>   return 0;
>  
>   pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, );
> + tlb_start_ptes(>tlb);
>   for (; addr != end; pte++, addr += PAGE_SIZE) {
>   ptent = *pte;
>  
> @@ -1190,6 +1191,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned 
> long addr,
>   tlb_flush_pte_range(>tlb, addr, PAGE_SIZE);
>   ClearPageReferenced(page);
>   }
> + tlb_end_ptes(>tlb);
>   pte_unmap_unlock(pte - 1, ptl);
>   cond_resched();
>   return 0;
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index 041be2ef4426..10690763090a 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -58,6 +58,11 @@
>   *Defaults to flushing at tlb_end_vma() to reset the range; helps when
>   *there's large holes between the VMAs.
>   *
> + *  - tlb_start_ptes() / tlb_end_ptes; makr the start / end of PTEs change.
Hello Nadav,

short nid makr/mark

Damian

 
> + *
> + *Does internal accounting to allow fine(r) granularity checks for
> + *pte_accessible() on certain configuration.
> + *
>   *  - tlb_remove_table()
>   *
>   *tlb_remove_table() is the basic primitive to free page-table 
> directories
> @@ -373,6 +378,10 @@ static inline void tlb_flush(struct mmu_gather *tlb)
>   flush_tlb_range(tlb->vma, tlb->start, tlb->end);
>   }
>  }
> +#endif
> +
> +#if __is_defined(tlb_flush) ||   
> \
> + IS_ENABLED(CONFIG_ARCH_WANT_AGGRESSIVE_TLB_FLUSH_BATCHING)
>  
>  static inline void
>  tlb_update_vma(struct mmu_gather *tlb, struct vm_area_struct *vma)
> @@ -523,6 +532,15 @@ static inline void mark_mm_tlb_gen_done(struct mm_struct 
> *mm, u64 gen)
>  
>  #endif /* CONFIG_ARCH_HAS_TLB_GENERATIONS */
>  
> +#define tlb_start_ptes(tlb)  \
> + do {\
> + struct mmu_gather *_tlb = (tlb);\
> + \
> + flush_tlb_batched_pending(_tlb->mm);\
> + } while (0)
> +
> +static inline void tlb_end_ptes(struct mmu_gather *tlb) { }
> +
>  /*
>   * tlb_flush_{pte|pmd|pud|p4d}_range() adjust the tlb->start and tlb->end,
>   * and set corresponding cleared_*.
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 0938fd3ad228..932c1c2eb9a3 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -392,7 +392,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  #endif
>   tlb_change_page_size(tlb, PAGE_SIZE);
>   orig_pte = pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, );
> - flush_tlb_batched_pending(mm);
> + tlb_start_ptes(tlb);
>   arch_enter_lazy_mmu_mode();
>   for (; addr < end; pte++, addr += PAGE_SIZE) {
>   ptent = *pte;
> @@ -468,6 +468,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>   }
>  
>   arch_leave_lazy_mmu_mode();
> + tlb_end_ptes(tlb);
>   pte_unmap_unlock(orig_pte, ptl);
>   if (pageout)
>   reclaim_pages(_list);
> @@ -588,7 +589,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned 
> long addr,
>  
>   tlb_change_page_size(tlb, PAGE_SIZE);
>   orig_pte = pte = pte_offset_map_lock(mm, pmd, addr, );
> - flush_tlb_batched_pending(mm);
> + tlb_start_ptes(tlb);
>   arch_enter_lazy_mmu_mode();
>   for (; addr != end; pte++, addr += PAGE_SIZE) {
>   ptent = *pte;
> @@ -692,6 +693,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned 
> long addr,
>   

Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting

[Damian Tometzki]

On Sun, 27. Dec 11:38, Linus Torvalds wrote:
> On Sat, Dec 26, 2020 at 6:38 PM Hugh Dickins  wrote:
> >
> > This patch (like its antecedents) moves the pte_unmap_unlock() from
> > after do_fault_around()'s "check if the page fault is solved" into
> > filemap_map_pages() itself (which apparently does not NULLify vmf->pte
> > after unmapping it, which is poor, but good for revealing this issue).
> > That looks cleaner, but of course there was a very good reason for its
> > original positioning.
> 
> Good catch.
> 
> > Maybe you want to change the ->map_pages prototype, to pass down the
> > requested address too, so that it can report whether the requested
> > address was resolved or not.  Or it could be left to __do_fault(),
> > or even to a repeated fault; but those would be less efficient.
> 
> Let's keep the old really odd "let's unlock in the caller" for now,
> and minimize the changes.
> 
> Adding a big big comment at the end of filemap_map_pages() to note the
> odd delayed page table unlocking.
> 
> Here's an updated patch that combines Kirill's original patch, his
> additional incremental patch, and the fix for the pte lock oddity into
> one thing.
> 
> Does this finally pass your testing?
> 
>Linus
Hello together,

when i try to build this patch, i got the following error:

 CC  arch/x86/kernel/cpu/mce/threshold.o
mm/memory.c:3716:19: error: static declaration of ‘do_set_pmd’ follows 
non-static declaration
 static vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page)
   ^~
In file included from mm/memory.c:43:
./include/linux/mm.h:984:12: note: previous declaration of ‘do_set_pmd’ was here
 vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page);
^~
make[3]: *** [scripts/Makefile.build:279: mm/memory.o] Error 1
make[2]: *** [Makefile:1805: mm] Error 2
make[2]: *** Waiting for unfinished jobs
  CC  arch/x86/kernel/cpu/mce/therm_throt.o

Best regards
Damian

> From 4d221d934d112aa40c3f4978460be098fc9ce831 Mon Sep 17 00:00:00 2001
> From: "Kirill A. Shutemov" 
> Date: Sat, 19 Dec 2020 15:19:23 +0300
> Subject: [PATCH] mm: Cleanup faultaround and finish_fault() codepaths
> 
> alloc_set_pte() has two users with different requirements: in the
> faultaround code, it called from an atomic context and PTE page table
> has to be preallocated. finish_fault() can sleep and allocate page table
> as needed.
> 
> PTL locking rules are also strange, hard to follow and overkill for
> finish_fault().
> 
> Let's untangle the mess. alloc_set_pte() has gone now. All locking is
> explicit.
> 
> The price is some code duplication to handle huge pages in faultaround
> path, but it should be fine, having overall improvement in readability.
> 
> Signed-off-by: Kirill A. Shutemov 
> Signed-off-by: Linus Torvalds 
> ---
>  include/linux/mm.h  |   8 +-
>  include/linux/pgtable.h |  11 +++
>  mm/filemap.c| 168 ++--
>  mm/memory.c | 161 +++---
>  4 files changed, 192 insertions(+), 156 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5299b90a6c40..c0643a0ad5ff 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -535,8 +535,8 @@ struct vm_fault {
>* is not NULL, otherwise pmd.
>*/
>   pgtable_t prealloc_pte; /* Pre-allocated pte page table.
> -  * vm_ops->map_pages() calls
> -  * alloc_set_pte() from atomic context.
> +  * vm_ops->map_pages() sets up a page
> +  * table from from atomic context.
>* do_fault_around() pre-allocates
>* page table to avoid allocation from
>* atomic context.
> @@ -981,7 +981,9 @@ static inline pte_t maybe_mkwrite(pte_t pte, struct 
> vm_area_struct *vma)
>   return pte;
>  }
>  
> -vm_fault_t alloc_set_pte(struct vm_fault *vmf, struct page *page);
> +vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page);
> +void do_set_pte(struct vm_fault *vmf, struct page *page);
> +
>  vm_fault_t finish_fault(struct vm_fault *vmf);
>  vm_fault_t finish_mkwrite_fault(struct vm_fault *vmf);
>  #endif
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 8fcdfa52eb4b..36eb748f3c97 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -1314,6 +1314,17 @@ static inline int pmd_trans_unstable(pmd_t *pmd)
>  #endif
>  }
>  
> +/*
> + * the ordering of these checks is important for pmds with _page_devmap set.
> + * if we check pmd_trans_unstable() first we will trip the bad_pmd() check
> + * inside of pmd_none_or_trans_huge_or_clear_bad(). this will end up 
> correctly
> + * returning 1 but not 

Re: [PATCH v6 01/10] mm/memunmap: Don't access uninitialized memmap in memunmap_pages()

[Damian Tometzki]

Hello David,

patch 05/10 is missing in the patch series. 


On Sun, 06. Oct 10:56, David Hildenbrand wrote:
> From: "Aneesh Kumar K.V" 
> 
> With an altmap, the memmap falling into the reserved altmap space are
> not initialized and, therefore, contain a garbage NID and a garbage
> zone. Make sure to read the NID/zone from a memmap that was initialzed.
> 
> This fixes a kernel crash that is observed when destroying a namespace:
> 
> [   81.356173] kernel BUG at include/linux/mm.h:1107!
> cpu 0x1: Vector: 700 (Program Check) at [c00274087890]
> pc: c04b9728: memunmap_pages+0x238/0x340
> lr: c04b9724: memunmap_pages+0x234/0x340
> ...
> pid   = 3669, comm = ndctl
> kernel BUG at include/linux/mm.h:1107!
> [c00274087ba0] c09e3500 devm_action_release+0x30/0x50
> [c00274087bc0] c09e4758 release_nodes+0x268/0x2d0
> [c00274087c30] c09dd144 device_release_driver_internal+0x174/0x240
> [c00274087c70] c09d9dfc unbind_store+0x13c/0x190
> [c00274087cb0] c09d8a24 drv_attr_store+0x44/0x60
> [c00274087cd0] c05a7470 sysfs_kf_write+0x70/0xa0
> [c00274087d10] c05a5cac kernfs_fop_write+0x1ac/0x290
> [c00274087d60] c04be45c __vfs_write+0x3c/0x70
> [c00274087d80] c04c26e4 vfs_write+0xe4/0x200
> [c00274087dd0] c04c2a6c ksys_write+0x7c/0x140
> [c00274087e20] c000bbd0 system_call+0x5c/0x68
> 
> Cc: Dan Williams 
> Cc: Andrew Morton 
> Cc: Jason Gunthorpe 
> Cc: Logan Gunthorpe 
> Cc: Ira Weiny 
> Signed-off-by: Aneesh Kumar K.V 
> [ minimze code changes, rephrase description ]
> Signed-off-by: David Hildenbrand 
> ---
>  mm/memremap.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/memremap.c b/mm/memremap.c
> index 557e53c6fb46..8c2fb44c3b4d 100644
> --- a/mm/memremap.c
> +++ b/mm/memremap.c
> @@ -123,6 +123,7 @@ static void dev_pagemap_cleanup(struct dev_pagemap *pgmap)
>  void memunmap_pages(struct dev_pagemap *pgmap)
>  {
>   struct resource *res = >res;
> + struct page *first_page;
>   unsigned long pfn;
>   int nid;
>  
> @@ -131,14 +132,16 @@ void memunmap_pages(struct dev_pagemap *pgmap)
>   put_page(pfn_to_page(pfn));
>   dev_pagemap_cleanup(pgmap);
>  
> + /* make sure to access a memmap that was actually initialized */
> + first_page = pfn_to_page(pfn_first(pgmap));
> +
>   /* pages are dead and unused, undo the arch mapping */
> - nid = page_to_nid(pfn_to_page(PHYS_PFN(res->start)));
> + nid = page_to_nid(first_page);

Why we need 'nid = page_to_nid(first_page)' we didnt use it anymore in this 
function ?

>  
>   mem_hotplug_begin();
>   if (pgmap->type == MEMORY_DEVICE_PRIVATE) {
> - pfn = PHYS_PFN(res->start);
> - __remove_pages(page_zone(pfn_to_page(pfn)), pfn,
> -  PHYS_PFN(resource_size(res)), NULL);
> + __remove_pages(page_zone(first_page), PHYS_PFN(res->start),
> +PHYS_PFN(resource_size(res)), NULL);
>   } else {
>   arch_remove_memory(nid, res->start, resource_size(res),
>   pgmap_altmap(pgmap));
> -- 
> 2.21.0
>
Best regards
Damian
 

linux

[Damian Tometzki]

linux

test

[Damian Tometzki]

test

tt

[Damian Tometzki]

tt

Re: [PATCH v4 06/10] x86/alternative: use temporary mm for text poking

[Damian Tometzki]

On Sa, 10. Nov 15:17, Nadav Amit wrote:
> text_poke() can potentially compromise the security as it sets temporary
> PTEs in the fixmap. These PTEs might be used to rewrite the kernel code
> from other cores accidentally or maliciously, if an attacker gains the
> ability to write onto kernel memory.
> 
> Moreover, since remote TLBs are not flushed after the temporary PTEs are
> removed, the time-window in which the code is writable is not limited if
> the fixmap PTEs - maliciously or accidentally - are cached in the TLB.
> To address these potential security hazards, we use a temporary mm for
> patching the code.
> 
> Finally, text_poke() is also not conservative enough when mapping pages,
> as it always tries to map 2 pages, even when a single one is sufficient.
> So try to be more conservative, and do not map more than needed.
> 
> Cc: Andy Lutomirski 
> Cc: Kees Cook 
> Cc: Peter Zijlstra 
> Cc: Dave Hansen 
> Cc: Masami Hiramatsu 
> Signed-off-by: Nadav Amit 
> ---
>  arch/x86/include/asm/fixmap.h |   2 -
>  arch/x86/kernel/alternative.c | 112 +++---
>  2 files changed, 89 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
> index 50ba74a34a37..9da8cccdf3fb 100644
> --- a/arch/x86/include/asm/fixmap.h
> +++ b/arch/x86/include/asm/fixmap.h
> @@ -103,8 +103,6 @@ enum fixed_addresses {
>  #ifdef CONFIG_PARAVIRT
>   FIX_PARAVIRT_BOOTMAP,
>  #endif

Hello Nadav,

with the remove of FIX_TEXT_POKE1 and FIX_TEXT_POKE0 i get the following
build error:

/home/damian/kernel/linux/arch/x86/xen/mmu_pv.c:2321:7: Fehler: 
»FIX_TEXT_POKE0« nicht deklariert (erstmalige Verwendung in dieser Funktion); 
meinten Sie »FIX_TBOOT_BASE«?
  case FIX_TEXT_POKE0:
   ^~
   FIX_TBOOT_BASE
/home/damian/kernel/linux/arch/x86/xen/mmu_pv.c:2321:7: Anmerkung: jeder nicht 
deklarierte Bezeichner wird nur einmal für jede Funktion, in der er vorkommt, 
gemeldet
/home/damian/kernel/linux/arch/x86/xen/mmu_pv.c:2322:7: Fehler: 
»FIX_TEXT_POKE1« nicht deklariert (erstmalige Verwendung in dieser Funktion); 
meinten Sie »FIX_TBOOT_BASE«?
  case FIX_TEXT_POKE1:
   ^~
   FIX_TBOOT_BASE

Best regards
Damian

> - FIX_TEXT_POKE1, /* reserve 2 pages for text_poke() */
> - FIX_TEXT_POKE0, /* first page is last, because allocation is backward */
>  #ifdef   CONFIG_X86_INTEL_MID
>   FIX_LNW_VRTC,
>  #endif
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index d3ae5c26e5a0..96607ef285c3 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -683,43 +684,108 @@ __ro_after_init unsigned long poking_addr;
>  
>  static int __text_poke(void *addr, const void *opcode, size_t len)
>  {
> + bool cross_page_boundary = offset_in_page(addr) + len > PAGE_SIZE;
> + temporary_mm_state_t prev;
> + struct page *pages[2] = {NULL};
>   unsigned long flags;
> - char *vaddr;
> - struct page *pages[2];
> - int i, r = 0;
> + pte_t pte, *ptep;
> + spinlock_t *ptl;
> + int r = 0;
>  
>   /*
> -  * While boot memory allocator is runnig we cannot use struct
> -  * pages as they are not yet initialized.
> +  * While boot memory allocator is running we cannot use struct pages as
> +  * they are not yet initialized.
>*/
>   BUG_ON(!after_bootmem);
>  
>   if (!core_kernel_text((unsigned long)addr)) {
>   pages[0] = vmalloc_to_page(addr);
> - pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
> + if (cross_page_boundary)
> + pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
>   } else {
>   pages[0] = virt_to_page(addr);
>   WARN_ON(!PageReserved(pages[0]));
> - pages[1] = virt_to_page(addr + PAGE_SIZE);
> + if (cross_page_boundary)
> + pages[1] = virt_to_page(addr + PAGE_SIZE);
>   }
> - if (!pages[0])
> +
> + if (!pages[0] || (cross_page_boundary && !pages[1]))
>   return -EFAULT;
> +
>   local_irq_save(flags);
> - set_fixmap(FIX_TEXT_POKE0, page_to_phys(pages[0]));
> - if (pages[1])
> - set_fixmap(FIX_TEXT_POKE1, page_to_phys(pages[1]));
> - vaddr = (char *)fix_to_virt(FIX_TEXT_POKE0);
> - memcpy([(unsigned long)addr & ~PAGE_MASK], opcode, len);
> - clear_fixmap(FIX_TEXT_POKE0);
> - if (pages[1])
> - clear_fixmap(FIX_TEXT_POKE1);
> - local_flush_tlb();
> - sync_core();
> - /* Could also do a CLFLUSH here to speed up CPU recovery; but
> -that causes hangs on some VIA CPUs. */
> - for (i = 0; i < len; i++)
> - if (((char *)addr)[i] != ((char *)opcode)[i])
> - r = -EFAULT;
> +
> + /*
> +  * The lock is not really needed, but this allows 

Re: [PATCH v4 06/10] x86/alternative: use temporary mm for text poking

[Damian Tometzki]

On Sa, 10. Nov 15:17, Nadav Amit wrote:
> text_poke() can potentially compromise the security as it sets temporary
> PTEs in the fixmap. These PTEs might be used to rewrite the kernel code
> from other cores accidentally or maliciously, if an attacker gains the
> ability to write onto kernel memory.
> 
> Moreover, since remote TLBs are not flushed after the temporary PTEs are
> removed, the time-window in which the code is writable is not limited if
> the fixmap PTEs - maliciously or accidentally - are cached in the TLB.
> To address these potential security hazards, we use a temporary mm for
> patching the code.
> 
> Finally, text_poke() is also not conservative enough when mapping pages,
> as it always tries to map 2 pages, even when a single one is sufficient.
> So try to be more conservative, and do not map more than needed.
> 
> Cc: Andy Lutomirski 
> Cc: Kees Cook 
> Cc: Peter Zijlstra 
> Cc: Dave Hansen 
> Cc: Masami Hiramatsu 
> Signed-off-by: Nadav Amit 
> ---
>  arch/x86/include/asm/fixmap.h |   2 -
>  arch/x86/kernel/alternative.c | 112 +++---
>  2 files changed, 89 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
> index 50ba74a34a37..9da8cccdf3fb 100644
> --- a/arch/x86/include/asm/fixmap.h
> +++ b/arch/x86/include/asm/fixmap.h
> @@ -103,8 +103,6 @@ enum fixed_addresses {
>  #ifdef CONFIG_PARAVIRT
>   FIX_PARAVIRT_BOOTMAP,
>  #endif

Hello Nadav,

with the remove of FIX_TEXT_POKE1 and FIX_TEXT_POKE0 i get the following
build error:

/home/damian/kernel/linux/arch/x86/xen/mmu_pv.c:2321:7: Fehler: 
»FIX_TEXT_POKE0« nicht deklariert (erstmalige Verwendung in dieser Funktion); 
meinten Sie »FIX_TBOOT_BASE«?
  case FIX_TEXT_POKE0:
   ^~
   FIX_TBOOT_BASE
/home/damian/kernel/linux/arch/x86/xen/mmu_pv.c:2321:7: Anmerkung: jeder nicht 
deklarierte Bezeichner wird nur einmal für jede Funktion, in der er vorkommt, 
gemeldet
/home/damian/kernel/linux/arch/x86/xen/mmu_pv.c:2322:7: Fehler: 
»FIX_TEXT_POKE1« nicht deklariert (erstmalige Verwendung in dieser Funktion); 
meinten Sie »FIX_TBOOT_BASE«?
  case FIX_TEXT_POKE1:
   ^~
   FIX_TBOOT_BASE

Best regards
Damian

> - FIX_TEXT_POKE1, /* reserve 2 pages for text_poke() */
> - FIX_TEXT_POKE0, /* first page is last, because allocation is backward */
>  #ifdef   CONFIG_X86_INTEL_MID
>   FIX_LNW_VRTC,
>  #endif
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index d3ae5c26e5a0..96607ef285c3 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -683,43 +684,108 @@ __ro_after_init unsigned long poking_addr;
>  
>  static int __text_poke(void *addr, const void *opcode, size_t len)
>  {
> + bool cross_page_boundary = offset_in_page(addr) + len > PAGE_SIZE;
> + temporary_mm_state_t prev;
> + struct page *pages[2] = {NULL};
>   unsigned long flags;
> - char *vaddr;
> - struct page *pages[2];
> - int i, r = 0;
> + pte_t pte, *ptep;
> + spinlock_t *ptl;
> + int r = 0;
>  
>   /*
> -  * While boot memory allocator is runnig we cannot use struct
> -  * pages as they are not yet initialized.
> +  * While boot memory allocator is running we cannot use struct pages as
> +  * they are not yet initialized.
>*/
>   BUG_ON(!after_bootmem);
>  
>   if (!core_kernel_text((unsigned long)addr)) {
>   pages[0] = vmalloc_to_page(addr);
> - pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
> + if (cross_page_boundary)
> + pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
>   } else {
>   pages[0] = virt_to_page(addr);
>   WARN_ON(!PageReserved(pages[0]));
> - pages[1] = virt_to_page(addr + PAGE_SIZE);
> + if (cross_page_boundary)
> + pages[1] = virt_to_page(addr + PAGE_SIZE);
>   }
> - if (!pages[0])
> +
> + if (!pages[0] || (cross_page_boundary && !pages[1]))
>   return -EFAULT;
> +
>   local_irq_save(flags);
> - set_fixmap(FIX_TEXT_POKE0, page_to_phys(pages[0]));
> - if (pages[1])
> - set_fixmap(FIX_TEXT_POKE1, page_to_phys(pages[1]));
> - vaddr = (char *)fix_to_virt(FIX_TEXT_POKE0);
> - memcpy([(unsigned long)addr & ~PAGE_MASK], opcode, len);
> - clear_fixmap(FIX_TEXT_POKE0);
> - if (pages[1])
> - clear_fixmap(FIX_TEXT_POKE1);
> - local_flush_tlb();
> - sync_core();
> - /* Could also do a CLFLUSH here to speed up CPU recovery; but
> -that causes hangs on some VIA CPUs. */
> - for (i = 0; i < len; i++)
> - if (((char *)addr)[i] != ((char *)opcode)[i])
> - r = -EFAULT;
> +
> + /*
> +  * The lock is not really needed, but this allows 

Re: [tip:locking/core 5/6] /bin/bash: scripts/atomic/check-atomics.sh: No such file or directory

[Damian Tometzki]

Hello Mark,

i got now the error:
/bin/bash: scripts/atomic/check-atomics.sh: No such file or directory
make[2]: *** [/home/damian/kernel/linux/./Kbuild:86: old-atomics] Fehler 127
make[1]: *** [/home/damian/kernel/linux/Makefile:1112: prepare0] Fehler 2

Best regards
Damian




On Do, 01. Nov 11:29, Mark Rutland wrote:
> On Thu, Nov 01, 2018 at 06:16:22PM +0800, kbuild test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> > locking/core
> > head:   30bc7baa9de81efc0584b9290ce8040a1130f156
> > commit: 85f8507192fbfb4ad2ac01de879cb50045f4247f [5/6] locking/atomics: 
> > Check generated headers are up-to-date
> > config: i386-tinyconfig (attached as .config)
> > compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> > reproduce:
> > git checkout 85f8507192fbfb4ad2ac01de879cb50045f4247f
> > # save the attached .config to linux build tree
> > make ARCH=i386 
> > 
> > All errors (new ones prefixed by >>):
> > 
> > >> /bin/bash: scripts/atomic/check-atomics.sh: No such file or directory
> >make[2]: *** [old-atomics] Error 127
> >make[2]: Target '__build' not remade because of errors.
> >make[1]: *** [prepare0] Error 2
> >make[1]: Target 'prepare' not remade because of errors.
> >make: *** [sub-make] Error 2
> 
> It looks like we accidentally dropped execute permissions from the
> scripts when picking them from the list. Locally I get a slightly
> different failure:
> 
>   ALLscripts/atomic/check-atomics.sh
>   scripts/atomic/check-atomics.sh: line 16: 
>   scripts/atomic/gen-atomic-instrumented.sh: Permission denied
>   warning: include/asm-generic/atomic-instrumented.h is out-of-date.
>   scripts/atomic/check-atomics.sh: line 16: 
>   scripts/atomic/gen-atomic-long.sh: Permission denied
>   warning: include/asm-generic/atomic-long.h is out-of-date.
>   scripts/atomic/check-atomics.sh: line 16: 
>   scripts/atomic/gen-atomic-fallback.sh: Permission denied
>   warning: include/linux/atomic-fallback.h is out-of-date.
> 
> I've sent a patch [1] to fix this.
> 
> Thanks,
> Mark.
> 
> [1] https://lkml.kernel.org/r/20181101112654.55898-1-mark.rutl...@arm.com

Re: [tip:locking/core 5/6] /bin/bash: scripts/atomic/check-atomics.sh: No such file or directory

[Damian Tometzki]

Hello Mark,

i got now the error:
/bin/bash: scripts/atomic/check-atomics.sh: No such file or directory
make[2]: *** [/home/damian/kernel/linux/./Kbuild:86: old-atomics] Fehler 127
make[1]: *** [/home/damian/kernel/linux/Makefile:1112: prepare0] Fehler 2

Best regards
Damian




On Do, 01. Nov 11:29, Mark Rutland wrote:
> On Thu, Nov 01, 2018 at 06:16:22PM +0800, kbuild test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> > locking/core
> > head:   30bc7baa9de81efc0584b9290ce8040a1130f156
> > commit: 85f8507192fbfb4ad2ac01de879cb50045f4247f [5/6] locking/atomics: 
> > Check generated headers are up-to-date
> > config: i386-tinyconfig (attached as .config)
> > compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> > reproduce:
> > git checkout 85f8507192fbfb4ad2ac01de879cb50045f4247f
> > # save the attached .config to linux build tree
> > make ARCH=i386 
> > 
> > All errors (new ones prefixed by >>):
> > 
> > >> /bin/bash: scripts/atomic/check-atomics.sh: No such file or directory
> >make[2]: *** [old-atomics] Error 127
> >make[2]: Target '__build' not remade because of errors.
> >make[1]: *** [prepare0] Error 2
> >make[1]: Target 'prepare' not remade because of errors.
> >make: *** [sub-make] Error 2
> 
> It looks like we accidentally dropped execute permissions from the
> scripts when picking them from the list. Locally I get a slightly
> different failure:
> 
>   ALLscripts/atomic/check-atomics.sh
>   scripts/atomic/check-atomics.sh: line 16: 
>   scripts/atomic/gen-atomic-instrumented.sh: Permission denied
>   warning: include/asm-generic/atomic-instrumented.h is out-of-date.
>   scripts/atomic/check-atomics.sh: line 16: 
>   scripts/atomic/gen-atomic-long.sh: Permission denied
>   warning: include/asm-generic/atomic-long.h is out-of-date.
>   scripts/atomic/check-atomics.sh: line 16: 
>   scripts/atomic/gen-atomic-fallback.sh: Permission denied
>   warning: include/linux/atomic-fallback.h is out-of-date.
> 
> I've sent a patch [1] to fix this.
> 
> Thanks,
> Mark.
> 
> [1] https://lkml.kernel.org/r/20181101112654.55898-1-mark.rutl...@arm.com

Re: linux-next: Tree for Oct 29

[Damian Tometzki]

On Mo, 29. Okt 17:02, Stephen Rothwell wrote:

> Hi all,
>
Hello Stephen,

on the site isnt available the new linux-next ?
Only the old one. 

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

> Changes since 20181019:
> 
> Linus' tree gained 2 build failures for which I reverted a commit and
> added a fix patch.
> 
> The arm-soc tree gained conflicts against Linus' tree.
> 
> The vfs tree gained conflicts against the ceph and nfsd trees.
> 
> The pm tree gained conflicts against Linus' and the i2c trees.
> 
> The drivers-x86 tree gained a conflict against Linus' tree.
> 
> Non-merge commits (relative to Linus' tree): 4593
>  4462 files changed, 276395 insertions(+), 77168 deletions(-)
> 
> 
> 
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one.  You should use "git fetch" and checkout or reset to the new
> master.
> 
> You can see which trees have been included by looking in the Next/Trees
> file in the source.  There are also quilt-import.log and merge.log
> files in the Next directory.  Between each merge, the tree was built
> with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
> multi_v7_defconfig for arm and a native build of tools/perf. After
> the final fixups (if any), I do an x86_64 modules_install followed by
> builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
> ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
> and sparc64 defconfig. And finally, a simple boot test of the powerpc
> pseries_le_defconfig kernel in qemu (with and without kvm enabled).
> 
> Below is a summary of the state of the merge.
> 
> I am currently merging 291 trees (counting Linus' and 66 trees of bug
> fix patches pending for the current merge release).
> 
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
> 
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
> 
> Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
> Gortmaker for triage and bug fixes.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> $ git checkout master
> $ git reset --hard stable
> Merging origin/master (746bb4ed6d62 Merge tag 'vla-v4.20-rc1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux)
> Merging fixes/master (eb81bfb224ce Merge branch 'for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
> Applying: Revert "bridge: do not add port to router list when receives query 
> with source 0.0.0.0"
> Applying: drivers: net: include linux/ip.h for iphdr
> Merging kbuild-current/fixes (5318321d367c samples: disable CONFIG_SAMPLES 
> for UML)
> Merging arc-current/for-curr (56d02dd9e794 ARC: IOC: panic if kernel was 
> started with previously enabled IOC)
> Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() 
> offset check)
> Merging arm64-fixes/for-next/fixes (ca2b497253ad arm64: perf: Reject 
> stand-alone CHAIN events for PMUv3)
> Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and 
> m68k_pgtable_cachemode)
> Merging powerpc-fixes/fixes (ac1788cc7da4 powerpc/numa: Skip onlining a 
> offline node in kdump path)
> Merging sparc/master (345671ea0f92 Merge branch 'akpm' (patches from Andrew))
> Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
> Merging net/master (ece23711dd95 net: Properly unlink GRO packets on 
> overflow.)
> Merging bpf/master (d8fd9e106fbc bpf: fix wrong helper enablement in cgroup 
> local storage)
> Merging ipsec/master (6788fac82001 Merge 
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf)
> Merging netfilter/master (5a8de47b3c25 netfilter: bridge: define INT_MIN & 
> INT_MAX in userspace)
> Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic 
> updates of non-anonymous set)
> Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD 
> queue size)
> Merging mac80211/master (8d0be26c781a mac80211_hwsim: fix module init error 
> paths for netlink)
> Merging rdma-fixes/for-rc (a3671a4f973e RDMA/ucma: Fix Spectre v1 
> vulnerability)
> Merging sound-current/for-linus (aedef16a63d5 ALSA: dice: fix to wait for 
> releases of all ALSA character devices)
> Merging sound-asoc-fixes/for-linus (eafb621d62c7 Merge branch 'asoc-4.19' 
> into asoc-linus)
> Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8)
> Merging regulator-fixes/for-linus (84df9525b0c2 Linux 4.19)
> Merging spi-fixes/for-linus (599eb81f4118 Merge branch 'spi-4.19' into 
> 

Re: linux-next: Tree for Oct 29

[Damian Tometzki]

On Mo, 29. Okt 17:02, Stephen Rothwell wrote:

> Hi all,
>
Hello Stephen,

on the site isnt available the new linux-next ?
Only the old one. 

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

> Changes since 20181019:
> 
> Linus' tree gained 2 build failures for which I reverted a commit and
> added a fix patch.
> 
> The arm-soc tree gained conflicts against Linus' tree.
> 
> The vfs tree gained conflicts against the ceph and nfsd trees.
> 
> The pm tree gained conflicts against Linus' and the i2c trees.
> 
> The drivers-x86 tree gained a conflict against Linus' tree.
> 
> Non-merge commits (relative to Linus' tree): 4593
>  4462 files changed, 276395 insertions(+), 77168 deletions(-)
> 
> 
> 
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one.  You should use "git fetch" and checkout or reset to the new
> master.
> 
> You can see which trees have been included by looking in the Next/Trees
> file in the source.  There are also quilt-import.log and merge.log
> files in the Next directory.  Between each merge, the tree was built
> with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
> multi_v7_defconfig for arm and a native build of tools/perf. After
> the final fixups (if any), I do an x86_64 modules_install followed by
> builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
> ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
> and sparc64 defconfig. And finally, a simple boot test of the powerpc
> pseries_le_defconfig kernel in qemu (with and without kvm enabled).
> 
> Below is a summary of the state of the merge.
> 
> I am currently merging 291 trees (counting Linus' and 66 trees of bug
> fix patches pending for the current merge release).
> 
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
> 
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
> 
> Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
> Gortmaker for triage and bug fixes.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> $ git checkout master
> $ git reset --hard stable
> Merging origin/master (746bb4ed6d62 Merge tag 'vla-v4.20-rc1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux)
> Merging fixes/master (eb81bfb224ce Merge branch 'for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
> Applying: Revert "bridge: do not add port to router list when receives query 
> with source 0.0.0.0"
> Applying: drivers: net: include linux/ip.h for iphdr
> Merging kbuild-current/fixes (5318321d367c samples: disable CONFIG_SAMPLES 
> for UML)
> Merging arc-current/for-curr (56d02dd9e794 ARC: IOC: panic if kernel was 
> started with previously enabled IOC)
> Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() 
> offset check)
> Merging arm64-fixes/for-next/fixes (ca2b497253ad arm64: perf: Reject 
> stand-alone CHAIN events for PMUv3)
> Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and 
> m68k_pgtable_cachemode)
> Merging powerpc-fixes/fixes (ac1788cc7da4 powerpc/numa: Skip onlining a 
> offline node in kdump path)
> Merging sparc/master (345671ea0f92 Merge branch 'akpm' (patches from Andrew))
> Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
> Merging net/master (ece23711dd95 net: Properly unlink GRO packets on 
> overflow.)
> Merging bpf/master (d8fd9e106fbc bpf: fix wrong helper enablement in cgroup 
> local storage)
> Merging ipsec/master (6788fac82001 Merge 
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf)
> Merging netfilter/master (5a8de47b3c25 netfilter: bridge: define INT_MIN & 
> INT_MAX in userspace)
> Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic 
> updates of non-anonymous set)
> Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD 
> queue size)
> Merging mac80211/master (8d0be26c781a mac80211_hwsim: fix module init error 
> paths for netlink)
> Merging rdma-fixes/for-rc (a3671a4f973e RDMA/ucma: Fix Spectre v1 
> vulnerability)
> Merging sound-current/for-linus (aedef16a63d5 ALSA: dice: fix to wait for 
> releases of all ALSA character devices)
> Merging sound-asoc-fixes/for-linus (eafb621d62c7 Merge branch 'asoc-4.19' 
> into asoc-linus)
> Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8)
> Merging regulator-fixes/for-linus (84df9525b0c2 Linux 4.19)
> Merging spi-fixes/for-linus (599eb81f4118 Merge branch 'spi-4.19' into 
> 

Re: Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'

[Damian Tometzki]

Hello together,

after commit "Merge tag 'char-misc-4.17-rc3' 
d8a332730e757129e70675679f2b2a03f1ecf65e my virtualbox with Ubuntu 16.04 no 
longer works correctly.
The focus on a window for example "terminal window" only works very delayed. Or 
a move of the window with the mouse isnt possible. 
I reverted the commit 'd8a332730e757129e70675679f2b2a03f1ecf65e' and now works 
all normal. 

Best regards 
Damian

Re: Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'

[Damian Tometzki]

Hello together,

after commit "Merge tag 'char-misc-4.17-rc3' 
d8a332730e757129e70675679f2b2a03f1ecf65e my virtualbox with Ubuntu 16.04 no 
longer works correctly.
The focus on a window for example "terminal window" only works very delayed. Or 
a move of the window with the mouse isnt possible. 
I reverted the commit 'd8a332730e757129e70675679f2b2a03f1ecf65e' and now works 
all normal. 

Best regards 
Damian

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

[Damian Tometzki]

On Wed, 13. Dec 12:07, Paul Menzel wrote:
> Dear Damian,
> 
> 
> On 12/13/17 12:00, Damian Tometzki wrote:
> 
> >Hexdump was already installed in the System.
> >
> >I commented out this step.
> Please try to reproduce it from a clean environment (`git clean -dfx`, save
> your .config before), and then please give more details.

After cleaning the environment with  'git clean -dfx' the build was 
successfully. 
Thanks for you help
 
> 
> 
> Kind regards,
> 
> Paul

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

[Damian Tometzki]

On Wed, 13. Dec 12:07, Paul Menzel wrote:
> Dear Damian,
> 
> 
> On 12/13/17 12:00, Damian Tometzki wrote:
> 
> >Hexdump was already installed in the System.
> >
> >I commented out this step.
> Please try to reproduce it from a clean environment (`git clean -dfx`, save
> your .config before), and then please give more details.

After cleaning the environment with  'git clean -dfx' the build was 
successfully. 
Thanks for you help
 
> 
> 
> Kind regards,
> 
> Paul

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

[Damian Tometzki]

Hello Paul,

with the cleanup the Build was succesfully. 

Thanks für you help. 

VG Damian Tometzki
Itelligence AG
+41 79 304 2745



> Am 13.12.2017 um 12:07 schrieb Paul Menzel 
> <pmenzel+linux-wirel...@molgen.mpg.de>:
> 
> Dear Damian,
> 
> 
>> On 12/13/17 12:00, Damian Tometzki wrote:
>> 
>> Hexdump was already installed in the System.
>> I commented out this step.
> Please try to reproduce it from a clean environment (`git clean -dfx`, save 
> your .config before), and then please give more details.
> 
> 
> Kind regards,
> 
> Paul

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

[Damian Tometzki]

Hello Paul,

with the cleanup the Build was succesfully. 

Thanks für you help. 

VG Damian Tometzki
Itelligence AG
+41 79 304 2745



> Am 13.12.2017 um 12:07 schrieb Paul Menzel 
> :
> 
> Dear Damian,
> 
> 
>> On 12/13/17 12:00, Damian Tometzki wrote:
>> 
>> Hexdump was already installed in the System.
>> I commented out this step.
> Please try to reproduce it from a clean environment (`git clean -dfx`, save 
> your .config before), and then please give more details.
> 
> 
> Kind regards,
> 
> Paul

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

[Damian Tometzki]

Hello Paul,

Hexdump was already installed in the System. 

I commented out this step. 

VG Damian Tometzki
Itelligence AG
+41 79 304 2745



> Am 13.12.2017 um 10:16 schrieb Paul Menzel 
> <pmenzel+linux-wirel...@molgen.mpg.de>:
> 
> Dear Damian,
> 
> 
>> On 12/13/17 08:53, Damian Tometzki wrote:
>> 
>> I got. the same Build error.
> 
> So first you didn’t have hexdump installed, and then after installing it you 
> got it? Removing the generated file fixed the build?
> 
> 
> Kind regards,
> 
> Paul

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

[Damian Tometzki]

Hello Paul,

Hexdump was already installed in the System. 

I commented out this step. 

VG Damian Tometzki
Itelligence AG
+41 79 304 2745



> Am 13.12.2017 um 10:16 schrieb Paul Menzel 
> :
> 
> Dear Damian,
> 
> 
>> On 12/13/17 08:53, Damian Tometzki wrote:
>> 
>> I got. the same Build error.
> 
> So first you didn’t have hexdump installed, and then after installing it you 
> got it? Removing the generated file fixed the build?
> 
> 
> Kind regards,
> 
> Paul

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

[Damian Tometzki]

Hello Johannes,

I got. the same Build error. 


VG Damian Tometzki





> Am 05.12.2017 um 11:03 schrieb Johannes Berg <johan...@sipsolutions.net>:
> 
>> On Tue, 2017-12-05 at 11:01 +0100, Paul Menzel wrote:
>> 
>> 
>> ```
>> $ git describe
>> v4.15-rc2-79-gfd6d2e506ce6
>> $ git log --oneline -1
>> fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux
>> $ time ARCH=i386 make deb-pkg -j50
>> […]
>> net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
>>  const u8 shipped_regdb_certs[] = {
>>  ^
>> […]
>> $ more net/wireless/shipped-certs.c
>> #include "reg.h"
>> const u8 shipped_regdb_certs[] = {
>> ```
> 
> Ah, here we go - you probably don't have "hexdump" installed on this
> system?
> 
> I thought about doing hexdump in posix shell/awk/sed/whatever
> instead... maybe I should do that.
> 
> johannes

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

[Damian Tometzki]

Hello Johannes,

I got. the same Build error. 


VG Damian Tometzki





> Am 05.12.2017 um 11:03 schrieb Johannes Berg :
> 
>> On Tue, 2017-12-05 at 11:01 +0100, Paul Menzel wrote:
>> 
>> 
>> ```
>> $ git describe
>> v4.15-rc2-79-gfd6d2e506ce6
>> $ git log --oneline -1
>> fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux
>> $ time ARCH=i386 make deb-pkg -j50
>> […]
>> net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
>>  const u8 shipped_regdb_certs[] = {
>>  ^
>> […]
>> $ more net/wireless/shipped-certs.c
>> #include "reg.h"
>> const u8 shipped_regdb_certs[] = {
>> ```
> 
> Ah, here we go - you probably don't have "hexdump" installed on this
> system?
> 
> I thought about doing hexdump in posix shell/awk/sed/whatever
> instead... maybe I should do that.
> 
> johannes

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Damian Tometzki]

Hello all,

i'am new in the community. For me the intention of the document is clear but is 
very spongy written. 
It leaves a lot of interpretations and unclear to me. 
Who is the community and who is we ? The names in the document ? In my opinion, 
the list is incomplete or is that the community ?
And what are with all the other people's where contribute to the community. 
Many of the people's in the document work in a company which also has the 
interest in further development.

Nevertheless, I will also try to make my contribution as a private person and 
in  my free time after work. 
Even if the entry is not made easy if one is not working with the well-known 
company. 

-Damian- 



signature.asc
Description: PGP signature

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Damian Tometzki]

Hello all,

i'am new in the community. For me the intention of the document is clear but is 
very spongy written. 
It leaves a lot of interpretations and unclear to me. 
Who is the community and who is we ? The names in the document ? In my opinion, 
the list is incomplete or is that the community ?
And what are with all the other people's where contribute to the community. 
Many of the people's in the document work in a company which also has the 
interest in further development.

Nevertheless, I will also try to make my contribution as a private person and 
in  my free time after work. 
Even if the entry is not made easy if one is not working with the well-known 
company. 

-Damian- 



signature.asc
Description: PGP signature

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Damian Tometzki]

Hello all,

i'am new in the community. For me the intention of the document is clear but is 
very spongy written.
It leaves a lot of interpretations and unclear to me.
Who is the community and who is we ? The names in the document ? In my opinion, 
the list is incomplete or is that the community ?
And what are with all the other people's where contribute to the community. 
Many of the people's in the document work in a company which also has the 
interest in further development.

Nevertheless, I will also try to make my contribution as a private person and 
in  my free time after work.
Even if the entry is not made easy if one is not working with the well-known 
company.

-Damian-

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Damian Tometzki]

Hello all,

i'am new in the community. For me the intention of the document is clear but is 
very spongy written.
It leaves a lot of interpretations and unclear to me.
Who is the community and who is we ? The names in the document ? In my opinion, 
the list is incomplete or is that the community ?
And what are with all the other people's where contribute to the community. 
Many of the people's in the document work in a company which also has the 
interest in further development.

Nevertheless, I will also try to make my contribution as a private person and 
in  my free time after work.
Even if the entry is not made easy if one is not working with the well-known 
company.

-Damian-

Re: [PATCH for linux-next] mm/page-writeback.c: make changes of dirty_writeback_centisecs take effect immediately

[Damian Tometzki]

On Sat, 14. Oct 16:38, Yafang Shao wrote:
> This patch is the followup of the prvious patch:
> [writeback: schedule periodic writeback with sysctl].
> 
> There's another issue to fix.
> For example,
> - When the tunable was set to one hour and is reset to one second, the
>   new setting will not take effect for up to one hour.
> 
> Kicking the flusher threads immediately fixes it.
> 
> Cc: Jens Axboe 
> Cc: Jan Kara 
> Cc: Andrew Morton 
> Signed-off-by: Yafang Shao 
> ---
>  mm/page-writeback.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index 3969e69..768fe4e 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -1978,7 +1978,16 @@ int dirty_writeback_centisecs_handler(struct ctl_table 
> *table, int write,
>   int ret;
>  
>   ret = proc_dointvec(table, write, buffer, length, ppos);
> - if (!ret && !old_interval && dirty_writeback_interval)
> +
> + /*
> +  * Writing 0 to dirty_writeback_interval will disable periodic writeback
> +  * and a different non-zero value will wakeup the writeback threads.
> +  * wb_wakeup_delayed() would be more appropriate, but it's a pain to
> +  * iterate over all bdis and wbs.
> +  * The reason we do this is to make the change take effect immediately.
> +  */
> + if (!ret && write && dirty_writeback_interval &&
> + dirty_writeback_interval != old_interval)
>   wakeup_flusher_threads(WB_REASON_PERIODIC);
Is that call right ? The call need two arguments ?
--> wakeup_flusher_threads(0,WB_REASON_PERIODIC);

best regards
Damian

>  
>   return ret;
> -- 
> 1.8.3.1
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [PATCH for linux-next] mm/page-writeback.c: make changes of dirty_writeback_centisecs take effect immediately

[Damian Tometzki]

On Sat, 14. Oct 16:38, Yafang Shao wrote:
> This patch is the followup of the prvious patch:
> [writeback: schedule periodic writeback with sysctl].
> 
> There's another issue to fix.
> For example,
> - When the tunable was set to one hour and is reset to one second, the
>   new setting will not take effect for up to one hour.
> 
> Kicking the flusher threads immediately fixes it.
> 
> Cc: Jens Axboe 
> Cc: Jan Kara 
> Cc: Andrew Morton 
> Signed-off-by: Yafang Shao 
> ---
>  mm/page-writeback.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index 3969e69..768fe4e 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -1978,7 +1978,16 @@ int dirty_writeback_centisecs_handler(struct ctl_table 
> *table, int write,
>   int ret;
>  
>   ret = proc_dointvec(table, write, buffer, length, ppos);
> - if (!ret && !old_interval && dirty_writeback_interval)
> +
> + /*
> +  * Writing 0 to dirty_writeback_interval will disable periodic writeback
> +  * and a different non-zero value will wakeup the writeback threads.
> +  * wb_wakeup_delayed() would be more appropriate, but it's a pain to
> +  * iterate over all bdis and wbs.
> +  * The reason we do this is to make the change take effect immediately.
> +  */
> + if (!ret && write && dirty_writeback_interval &&
> + dirty_writeback_interval != old_interval)
>   wakeup_flusher_threads(WB_REASON_PERIODIC);
Is that call right ? The call need two arguments ?
--> wakeup_flusher_threads(0,WB_REASON_PERIODIC);

best regards
Damian

>  
>   return ret;
> -- 
> 1.8.3.1
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: How to verify linux-next

[Damian Tometzki]

Am Sonntag, den 01.10.2017, 21:58 +0530 schrieb Pintu Kumar:
> On Sat, Sep 30, 2017 at 10:55 AM, Theodore Ts'o 
> wrote:
> > 
> > On Sat, Sep 30, 2017 at 09:28:09AM +0530, Pintu Kumar wrote:
> > > 
> > > I need to submit a patch to mainline which should be verified
> > > against
> > > linux-next tree with latest API.
> > If you want to verify a patch that you intend to submit upstream,
> > my
> > suggestion is to *not* use linux-next, but rather use the latest
> > tagged -rc from Linus's tree.  So for example, you might want to
> > use
> > v4.14-rc2 as your base, and then apply your patch on top of v4.14-
> > rc2.
> > And then test v4.14-rc2.  That way you don't need to worry about
> > debugging problems that might be caused by code in other people's
> > development trees.
> > 
> > If you know which subsystem tree your commit is going to be sent
> > to,
> > you might use as your base the current development branch of that
> > subsystem tree.  But in general, it's fine to use something like
> > v4.14-rc2; if the subsystem maintainer you plan to be submitting
> > your
> > patch has other preference, he or she will let you know, or take
> > care
> > of rebasing your patch onto his subsystme tree.
> > 
> > > 
> > > My patch is related to some test utility based on client/server
> > > model.
> > > So, I need 2 terminal, one for server and one for client.
> > That implies you're running the commands to run the test by
> > hand.  In
> > the ideal world, tests should be automated, even those that are
> > using
> > client/server so that tests can be run unattended, over and over
> > again.
> > 
> > For example, here's an example of test involving a client and a
> > server
> > in xfstests:
> > 
> > https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/g
> > eneric/131
> > 
> > See?  No terminal required, and certainly not two terminals!
> > 
> > Remember, it's important not just to run one test, because the risk
> > is
> > that fixing one bug might cause a test regression somewhere
> > else.  So
> > when I "validate" a kernel, I'm running thousands of tests, just to
> > test the ext4 file system.  For each bug that we fix, we try to add
> > a
> > new automated test, so we can be sure that some future change
> > doesn't
> > cause a bug to reappear.  And if you're running hundreds or
> > thousands
> > of tests, you certainly aren't going to be wanting to manually set
> > up
> > each test by using putty to login to the VM using ssh!
> > 
> > > 
> > > 1) How to resolve linux-next build error with ubuntu virtual box
> > > 5.1.28
> > Virtual box is not relevant.  What is relevant is the kernel config
> > file you are using, and what compiler version / distro are you
> > using
> > to build the kernel.  And as I said, you're better off using
> > something
> > like v4.14-rc2 instead of linux-next.
> > 
> Ok thank you so much for your reply.
> Now I am able to boot with v4.14-rc2. But now I am facing another
> problem.
> Now, I am not able to connect to internet from virtual box.
> When I switch back to the default 4.10 the internet works normally.
> I think the dlclient stopped working.
> I am getting continuous logs related to apparmor like this:
> apparmor="DENIED" comm=dhclient
> apparmor="DENIED" comm=cups-browsed
> 
> With 4.10, I tried installing apparmor-utils and then reboot with
> 4.14-rc2, but it did not help.
> Any suggestions on this?

Hello,

i resolved the issue with:
sudo /etc/init.d/apparmor stop

Damian

> 
> 
> > 
> > - Ted

Re: How to verify linux-next

[Damian Tometzki]

Am Sonntag, den 01.10.2017, 21:58 +0530 schrieb Pintu Kumar:
> On Sat, Sep 30, 2017 at 10:55 AM, Theodore Ts'o 
> wrote:
> > 
> > On Sat, Sep 30, 2017 at 09:28:09AM +0530, Pintu Kumar wrote:
> > > 
> > > I need to submit a patch to mainline which should be verified
> > > against
> > > linux-next tree with latest API.
> > If you want to verify a patch that you intend to submit upstream,
> > my
> > suggestion is to *not* use linux-next, but rather use the latest
> > tagged -rc from Linus's tree.  So for example, you might want to
> > use
> > v4.14-rc2 as your base, and then apply your patch on top of v4.14-
> > rc2.
> > And then test v4.14-rc2.  That way you don't need to worry about
> > debugging problems that might be caused by code in other people's
> > development trees.
> > 
> > If you know which subsystem tree your commit is going to be sent
> > to,
> > you might use as your base the current development branch of that
> > subsystem tree.  But in general, it's fine to use something like
> > v4.14-rc2; if the subsystem maintainer you plan to be submitting
> > your
> > patch has other preference, he or she will let you know, or take
> > care
> > of rebasing your patch onto his subsystme tree.
> > 
> > > 
> > > My patch is related to some test utility based on client/server
> > > model.
> > > So, I need 2 terminal, one for server and one for client.
> > That implies you're running the commands to run the test by
> > hand.  In
> > the ideal world, tests should be automated, even those that are
> > using
> > client/server so that tests can be run unattended, over and over
> > again.
> > 
> > For example, here's an example of test involving a client and a
> > server
> > in xfstests:
> > 
> > https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/g
> > eneric/131
> > 
> > See?  No terminal required, and certainly not two terminals!
> > 
> > Remember, it's important not just to run one test, because the risk
> > is
> > that fixing one bug might cause a test regression somewhere
> > else.  So
> > when I "validate" a kernel, I'm running thousands of tests, just to
> > test the ext4 file system.  For each bug that we fix, we try to add
> > a
> > new automated test, so we can be sure that some future change
> > doesn't
> > cause a bug to reappear.  And if you're running hundreds or
> > thousands
> > of tests, you certainly aren't going to be wanting to manually set
> > up
> > each test by using putty to login to the VM using ssh!
> > 
> > > 
> > > 1) How to resolve linux-next build error with ubuntu virtual box
> > > 5.1.28
> > Virtual box is not relevant.  What is relevant is the kernel config
> > file you are using, and what compiler version / distro are you
> > using
> > to build the kernel.  And as I said, you're better off using
> > something
> > like v4.14-rc2 instead of linux-next.
> > 
> Ok thank you so much for your reply.
> Now I am able to boot with v4.14-rc2. But now I am facing another
> problem.
> Now, I am not able to connect to internet from virtual box.
> When I switch back to the default 4.10 the internet works normally.
> I think the dlclient stopped working.
> I am getting continuous logs related to apparmor like this:
> apparmor="DENIED" comm=dhclient
> apparmor="DENIED" comm=cups-browsed
> 
> With 4.10, I tried installing apparmor-utils and then reboot with
> 4.14-rc2, but it did not help.
> Any suggestions on this?

Hello,

i resolved the issue with:
sudo /etc/init.d/apparmor stop

Damian

> 
> 
> > 
> > - Ted

Re: [PATCH v16 0/5] Virtio-balloon Enhancement

[Damian Tometzki]

Hello,

where i can found the patch in git.kernel.org ?


Am Samstag, den 30.09.2017, 12:05 +0800 schrieb Wei Wang:
> This patch series enhances the existing virtio-balloon with the
> following
> new features:
> 1) fast ballooning: transfer ballooned pages between the guest and
> host in
> chunks using sgs, instead of one array each time; and
> 2) free page block reporting: a new virtqueue to report guest free
> pages
> to the host.
> 
> The second feature can be used to accelerate live migration of VMs.
> Here
> are some details:
> 
> Live migration needs to transfer the VM's memory from the source
> machine
> to the destination round by round. For the 1st round, all the VM's
> memory
> is transferred. From the 2nd round, only the pieces of memory that
> were
> written by the guest (after the 1st round) are transferred. One
> method
> that is popularly used by the hypervisor to track which part of
> memory is
> written is to write-protect all the guest memory.
> 
> The second feature enables the optimization of the 1st round memory
> transfer - the hypervisor can skip the transfer of guest free pages
> in the
> 1st round. It is not concerned that the memory pages are used after
> they
> are given to the hypervisor as a hint of the free pages, because they
> will
> be tracked by the hypervisor and transferred in the next round if
> they are
> used and written.
> 
> Change Log:
> v15->v16:
> 1) mm: stop reporting the free pfn range if the callback returns
> false;
> 2) mm: move some implementaion of walk_free_mem_block into a function
> to
> make the code layout looks better;
> 3) xbitmap: added some optimizations suggested by Matthew, please
> refer to
> the ChangLog in the xbitmap patch for details.
> 4) xbitmap: added a test suite
> 5) virtio-balloon: bail out with a warning when virtqueue_add_inbuf
> returns
> an error
> 6) virtio-balloon: some small code re-arrangement, e.g. detachinf
> used buf
> from the vq before adding a new buf
> 
> v14->v15:
> 1) mm: make the report callback return a bool value - returning 1 to
> stop
> walking through the free page list.
> 2) virtio-balloon: batching sgs of balloon pages till the vq is full
> 3) virtio-balloon: create a new workqueue, rather than using the
> default
> system_wq, to queue the free page reporting work item.
> 4) virtio-balloon: add a ctrl_vq to be a central control plane which
> will
> handle all the future control related commands between the host and
> guest.
> Add free page report as the first feature controlled under ctrl_vq,
> and
> the free_page_vq is a data plane vq dedicated to the transmission of
> free
> page blocks.
> 
> v13->v14:
> 1) xbitmap: move the code from lib/radix-tree.c to lib/xbitmap.c.
> 2) xbitmap: consolidate the implementation of xb_bit_set/clear/test
> into
> one xb_bit_ops.
> 3) xbitmap: add documents for the exported APIs.
> 4) mm: rewrite the function to walk through free page blocks.
> 5) virtio-balloon: when reporting a free page blcok to the device, if
> the
> vq is full (less likey to happen in practice), just skip reporting
> this
> block, instead of busywaiting till an entry gets released.
> 6) virtio-balloon: fail the probe function if adding the signal buf
> in
> init_vqs fails.
> 
> v12->v13:
> 1) mm: use a callback function to handle the the free page blocks
> from the
> report function. This avoids exposing the zone internal to a kernel
> module.
> 2) virtio-balloon: send balloon pages or a free page block using a
> single
> sg each time. This has the benefits of simpler implementation with no
> new
> APIs.
> 3) virtio-balloon: the free_page_vq is used to report free pages only
> (no
> multiple usages interleaving)
> 4) virtio-balloon: Balloon pages and free page blocks are sent via
> input
> sgs, and the completion signal to the host is sent via an output sg.
> 
> v11->v12:
> 1) xbitmap: use the xbitmap from Matthew Wilcox to record ballooned
> pages.
> 2) virtio-ring: enable the driver to build up a desc chain using
> vring
> desc.
> 3) virtio-ring: Add locking to the existing START_USE() and END_USE()
> macro to lock/unlock the vq when a vq operation starts/ends.
> 4) virtio-ring: add virtqueue_kick_sync() and virtqueue_kick_async()
> 5) virtio-balloon: describe chunks of ballooned pages and free pages
> blocks directly using one or more chains of desc from the vq.
> 
> v10->v11:
> 1) virtio_balloon: use vring_desc to describe a chunk;
> 2) virtio_ring: support to add an indirect desc table to virtqueue;
> 3)  virtio_balloon: use cmdq to report guest memory statistics.
> 
> v9->v10:
> 1) mm: put report_unused_page_block() under CONFIG_VIRTIO_BALLOON;
> 2) virtio-balloon: add virtballoon_validate();
> 3) virtio-balloon: msg format change;
> 4) virtio-balloon: move miscq handling to a task on
> system_freezable_wq;
> 5) virtio-balloon: code cleanup.
> 
> v8->v9:
> 1) Split the two new features, VIRTIO_BALLOON_F_BALLOON_CHUNKS and
> VIRTIO_BALLOON_F_MISC_VQ, which were mixed together in the previous
> 

Re: [PATCH v16 0/5] Virtio-balloon Enhancement

[Damian Tometzki]

Hello,

where i can found the patch in git.kernel.org ?


Am Samstag, den 30.09.2017, 12:05 +0800 schrieb Wei Wang:
> This patch series enhances the existing virtio-balloon with the
> following
> new features:
> 1) fast ballooning: transfer ballooned pages between the guest and
> host in
> chunks using sgs, instead of one array each time; and
> 2) free page block reporting: a new virtqueue to report guest free
> pages
> to the host.
> 
> The second feature can be used to accelerate live migration of VMs.
> Here
> are some details:
> 
> Live migration needs to transfer the VM's memory from the source
> machine
> to the destination round by round. For the 1st round, all the VM's
> memory
> is transferred. From the 2nd round, only the pieces of memory that
> were
> written by the guest (after the 1st round) are transferred. One
> method
> that is popularly used by the hypervisor to track which part of
> memory is
> written is to write-protect all the guest memory.
> 
> The second feature enables the optimization of the 1st round memory
> transfer - the hypervisor can skip the transfer of guest free pages
> in the
> 1st round. It is not concerned that the memory pages are used after
> they
> are given to the hypervisor as a hint of the free pages, because they
> will
> be tracked by the hypervisor and transferred in the next round if
> they are
> used and written.
> 
> Change Log:
> v15->v16:
> 1) mm: stop reporting the free pfn range if the callback returns
> false;
> 2) mm: move some implementaion of walk_free_mem_block into a function
> to
> make the code layout looks better;
> 3) xbitmap: added some optimizations suggested by Matthew, please
> refer to
> the ChangLog in the xbitmap patch for details.
> 4) xbitmap: added a test suite
> 5) virtio-balloon: bail out with a warning when virtqueue_add_inbuf
> returns
> an error
> 6) virtio-balloon: some small code re-arrangement, e.g. detachinf
> used buf
> from the vq before adding a new buf
> 
> v14->v15:
> 1) mm: make the report callback return a bool value - returning 1 to
> stop
> walking through the free page list.
> 2) virtio-balloon: batching sgs of balloon pages till the vq is full
> 3) virtio-balloon: create a new workqueue, rather than using the
> default
> system_wq, to queue the free page reporting work item.
> 4) virtio-balloon: add a ctrl_vq to be a central control plane which
> will
> handle all the future control related commands between the host and
> guest.
> Add free page report as the first feature controlled under ctrl_vq,
> and
> the free_page_vq is a data plane vq dedicated to the transmission of
> free
> page blocks.
> 
> v13->v14:
> 1) xbitmap: move the code from lib/radix-tree.c to lib/xbitmap.c.
> 2) xbitmap: consolidate the implementation of xb_bit_set/clear/test
> into
> one xb_bit_ops.
> 3) xbitmap: add documents for the exported APIs.
> 4) mm: rewrite the function to walk through free page blocks.
> 5) virtio-balloon: when reporting a free page blcok to the device, if
> the
> vq is full (less likey to happen in practice), just skip reporting
> this
> block, instead of busywaiting till an entry gets released.
> 6) virtio-balloon: fail the probe function if adding the signal buf
> in
> init_vqs fails.
> 
> v12->v13:
> 1) mm: use a callback function to handle the the free page blocks
> from the
> report function. This avoids exposing the zone internal to a kernel
> module.
> 2) virtio-balloon: send balloon pages or a free page block using a
> single
> sg each time. This has the benefits of simpler implementation with no
> new
> APIs.
> 3) virtio-balloon: the free_page_vq is used to report free pages only
> (no
> multiple usages interleaving)
> 4) virtio-balloon: Balloon pages and free page blocks are sent via
> input
> sgs, and the completion signal to the host is sent via an output sg.
> 
> v11->v12:
> 1) xbitmap: use the xbitmap from Matthew Wilcox to record ballooned
> pages.
> 2) virtio-ring: enable the driver to build up a desc chain using
> vring
> desc.
> 3) virtio-ring: Add locking to the existing START_USE() and END_USE()
> macro to lock/unlock the vq when a vq operation starts/ends.
> 4) virtio-ring: add virtqueue_kick_sync() and virtqueue_kick_async()
> 5) virtio-balloon: describe chunks of ballooned pages and free pages
> blocks directly using one or more chains of desc from the vq.
> 
> v10->v11:
> 1) virtio_balloon: use vring_desc to describe a chunk;
> 2) virtio_ring: support to add an indirect desc table to virtqueue;
> 3)  virtio_balloon: use cmdq to report guest memory statistics.
> 
> v9->v10:
> 1) mm: put report_unused_page_block() under CONFIG_VIRTIO_BALLOON;
> 2) virtio-balloon: add virtballoon_validate();
> 3) virtio-balloon: msg format change;
> 4) virtio-balloon: move miscq handling to a task on
> system_freezable_wq;
> 5) virtio-balloon: code cleanup.
> 
> v8->v9:
> 1) Split the two new features, VIRTIO_BALLOON_F_BALLOON_CHUNKS and
> VIRTIO_BALLOON_F_MISC_VQ, which were mixed together in the previous
> 

Re: [PATCH v16 0/5] Virtio-balloon Enhancement

[Damian Tometzki]

Hello,

where i can found the patch in git.kernel.org ?

Best regards
Damian


Am Samstag, den 30.09.2017, 12:05 +0800 schrieb Wei Wang:
> This patch series enhances the existing virtio-balloon with the
> following
> new features:
> 1) fast ballooning: transfer ballooned pages between the guest and
> host in
> chunks using sgs, instead of one array each time; and
> 2) free page block reporting: a new virtqueue to report guest free
> pages
> to the host.
> 
> The second feature can be used to accelerate live migration of VMs.
> Here
> are some details:
> 
> Live migration needs to transfer the VM's memory from the source
> machine
> to the destination round by round. For the 1st round, all the VM's
> memory
> is transferred. From the 2nd round, only the pieces of memory that
> were
> written by the guest (after the 1st round) are transferred. One
> method
> that is popularly used by the hypervisor to track which part of
> memory is
> written is to write-protect all the guest memory.
> 
> The second feature enables the optimization of the 1st round memory
> transfer - the hypervisor can skip the transfer of guest free pages
> in the
> 1st round. It is not concerned that the memory pages are used after
> they
> are given to the hypervisor as a hint of the free pages, because they
> will
> be tracked by the hypervisor and transferred in the next round if
> they are
> used and written.
> 
> Change Log:
> v15->v16:
> 1) mm: stop reporting the free pfn range if the callback returns
> false;
> 2) mm: move some implementaion of walk_free_mem_block into a function
> to
> make the code layout looks better;
> 3) xbitmap: added some optimizations suggested by Matthew, please
> refer to
> the ChangLog in the xbitmap patch for details.
> 4) xbitmap: added a test suite
> 5) virtio-balloon: bail out with a warning when virtqueue_add_inbuf
> returns
> an error
> 6) virtio-balloon: some small code re-arrangement, e.g. detachinf
> used buf
> from the vq before adding a new buf
> 
> v14->v15:
> 1) mm: make the report callback return a bool value - returning 1 to
> stop
> walking through the free page list.
> 2) virtio-balloon: batching sgs of balloon pages till the vq is full
> 3) virtio-balloon: create a new workqueue, rather than using the
> default
> system_wq, to queue the free page reporting work item.
> 4) virtio-balloon: add a ctrl_vq to be a central control plane which
> will
> handle all the future control related commands between the host and
> guest.
> Add free page report as the first feature controlled under ctrl_vq,
> and
> the free_page_vq is a data plane vq dedicated to the transmission of
> free
> page blocks.
> 
> v13->v14:
> 1) xbitmap: move the code from lib/radix-tree.c to lib/xbitmap.c.
> 2) xbitmap: consolidate the implementation of xb_bit_set/clear/test
> into
> one xb_bit_ops.
> 3) xbitmap: add documents for the exported APIs.
> 4) mm: rewrite the function to walk through free page blocks.
> 5) virtio-balloon: when reporting a free page blcok to the device, if
> the
> vq is full (less likey to happen in practice), just skip reporting
> this
> block, instead of busywaiting till an entry gets released.
> 6) virtio-balloon: fail the probe function if adding the signal buf
> in
> init_vqs fails.
> 
> v12->v13:
> 1) mm: use a callback function to handle the the free page blocks
> from the
> report function. This avoids exposing the zone internal to a kernel
> module.
> 2) virtio-balloon: send balloon pages or a free page block using a
> single
> sg each time. This has the benefits of simpler implementation with no
> new
> APIs.
> 3) virtio-balloon: the free_page_vq is used to report free pages only
> (no
> multiple usages interleaving)
> 4) virtio-balloon: Balloon pages and free page blocks are sent via
> input
> sgs, and the completion signal to the host is sent via an output sg.
> 
> v11->v12:
> 1) xbitmap: use the xbitmap from Matthew Wilcox to record ballooned
> pages.
> 2) virtio-ring: enable the driver to build up a desc chain using
> vring
> desc.
> 3) virtio-ring: Add locking to the existing START_USE() and END_USE()
> macro to lock/unlock the vq when a vq operation starts/ends.
> 4) virtio-ring: add virtqueue_kick_sync() and virtqueue_kick_async()
> 5) virtio-balloon: describe chunks of ballooned pages and free pages
> blocks directly using one or more chains of desc from the vq.
> 
> v10->v11:
> 1) virtio_balloon: use vring_desc to describe a chunk;
> 2) virtio_ring: support to add an indirect desc table to virtqueue;
> 3)  virtio_balloon: use cmdq to report guest memory statistics.
> 
> v9->v10:
> 1) mm: put report_unused_page_block() under CONFIG_VIRTIO_BALLOON;
> 2) virtio-balloon: add virtballoon_validate();
> 3) virtio-balloon: msg format change;
> 4) virtio-balloon: move miscq handling to a task on
> system_freezable_wq;
> 5) virtio-balloon: code cleanup.
> 
> v8->v9:
> 1) Split the two new features, VIRTIO_BALLOON_F_BALLOON_CHUNKS and
> VIRTIO_BALLOON_F_MISC_VQ, which were mixed together 

Re: [PATCH v16 0/5] Virtio-balloon Enhancement

[Damian Tometzki]

Hello,

where i can found the patch in git.kernel.org ?

Best regards
Damian


Am Samstag, den 30.09.2017, 12:05 +0800 schrieb Wei Wang:
> This patch series enhances the existing virtio-balloon with the
> following
> new features:
> 1) fast ballooning: transfer ballooned pages between the guest and
> host in
> chunks using sgs, instead of one array each time; and
> 2) free page block reporting: a new virtqueue to report guest free
> pages
> to the host.
> 
> The second feature can be used to accelerate live migration of VMs.
> Here
> are some details:
> 
> Live migration needs to transfer the VM's memory from the source
> machine
> to the destination round by round. For the 1st round, all the VM's
> memory
> is transferred. From the 2nd round, only the pieces of memory that
> were
> written by the guest (after the 1st round) are transferred. One
> method
> that is popularly used by the hypervisor to track which part of
> memory is
> written is to write-protect all the guest memory.
> 
> The second feature enables the optimization of the 1st round memory
> transfer - the hypervisor can skip the transfer of guest free pages
> in the
> 1st round. It is not concerned that the memory pages are used after
> they
> are given to the hypervisor as a hint of the free pages, because they
> will
> be tracked by the hypervisor and transferred in the next round if
> they are
> used and written.
> 
> Change Log:
> v15->v16:
> 1) mm: stop reporting the free pfn range if the callback returns
> false;
> 2) mm: move some implementaion of walk_free_mem_block into a function
> to
> make the code layout looks better;
> 3) xbitmap: added some optimizations suggested by Matthew, please
> refer to
> the ChangLog in the xbitmap patch for details.
> 4) xbitmap: added a test suite
> 5) virtio-balloon: bail out with a warning when virtqueue_add_inbuf
> returns
> an error
> 6) virtio-balloon: some small code re-arrangement, e.g. detachinf
> used buf
> from the vq before adding a new buf
> 
> v14->v15:
> 1) mm: make the report callback return a bool value - returning 1 to
> stop
> walking through the free page list.
> 2) virtio-balloon: batching sgs of balloon pages till the vq is full
> 3) virtio-balloon: create a new workqueue, rather than using the
> default
> system_wq, to queue the free page reporting work item.
> 4) virtio-balloon: add a ctrl_vq to be a central control plane which
> will
> handle all the future control related commands between the host and
> guest.
> Add free page report as the first feature controlled under ctrl_vq,
> and
> the free_page_vq is a data plane vq dedicated to the transmission of
> free
> page blocks.
> 
> v13->v14:
> 1) xbitmap: move the code from lib/radix-tree.c to lib/xbitmap.c.
> 2) xbitmap: consolidate the implementation of xb_bit_set/clear/test
> into
> one xb_bit_ops.
> 3) xbitmap: add documents for the exported APIs.
> 4) mm: rewrite the function to walk through free page blocks.
> 5) virtio-balloon: when reporting a free page blcok to the device, if
> the
> vq is full (less likey to happen in practice), just skip reporting
> this
> block, instead of busywaiting till an entry gets released.
> 6) virtio-balloon: fail the probe function if adding the signal buf
> in
> init_vqs fails.
> 
> v12->v13:
> 1) mm: use a callback function to handle the the free page blocks
> from the
> report function. This avoids exposing the zone internal to a kernel
> module.
> 2) virtio-balloon: send balloon pages or a free page block using a
> single
> sg each time. This has the benefits of simpler implementation with no
> new
> APIs.
> 3) virtio-balloon: the free_page_vq is used to report free pages only
> (no
> multiple usages interleaving)
> 4) virtio-balloon: Balloon pages and free page blocks are sent via
> input
> sgs, and the completion signal to the host is sent via an output sg.
> 
> v11->v12:
> 1) xbitmap: use the xbitmap from Matthew Wilcox to record ballooned
> pages.
> 2) virtio-ring: enable the driver to build up a desc chain using
> vring
> desc.
> 3) virtio-ring: Add locking to the existing START_USE() and END_USE()
> macro to lock/unlock the vq when a vq operation starts/ends.
> 4) virtio-ring: add virtqueue_kick_sync() and virtqueue_kick_async()
> 5) virtio-balloon: describe chunks of ballooned pages and free pages
> blocks directly using one or more chains of desc from the vq.
> 
> v10->v11:
> 1) virtio_balloon: use vring_desc to describe a chunk;
> 2) virtio_ring: support to add an indirect desc table to virtqueue;
> 3)  virtio_balloon: use cmdq to report guest memory statistics.
> 
> v9->v10:
> 1) mm: put report_unused_page_block() under CONFIG_VIRTIO_BALLOON;
> 2) virtio-balloon: add virtballoon_validate();
> 3) virtio-balloon: msg format change;
> 4) virtio-balloon: move miscq handling to a task on
> system_freezable_wq;
> 5) virtio-balloon: code cleanup.
> 
> v8->v9:
> 1) Split the two new features, VIRTIO_BALLOON_F_BALLOON_CHUNKS and
> VIRTIO_BALLOON_F_MISC_VQ, which were mixed together 

Re: How to verify linux-next

[Damian Tometzki]

Hello,

i can tell you ubuntu 16.04 works under virtualbox 5.1.28 with the
current linux-next kernel

My maschine:
Host: Windows 10
Guest: Ubuntu 16.04

Am Freitag, den 29.09.2017, 08:41 -0400 schrieb
valdis.kletni...@vt.edu:
> On Fri, 29 Sep 2017 16:08:07 +0530, Pintu Kumar said:
> 
> > 
> > I have a general question.
> > How do we normally verify linux-next tree?
> The same exact way you "verify" any other Linux kernel, for whatever
> definition of "verify" you plan to use.
> 
> > 
> > 1) For Oracle virtual box 5.1.26 with ubuntu-32 bit, the linux-next
> > kernel is not booting.
> Does an Ubuntu kernel boot correctly under VirtualBox?  If not, fix
> that issue first.  Also, "is not booting" isn't detailed enough for
> anybody
> to make even a guess as to what's wrong.
> 
> Also, note that 5.1.28 is out.

Re: How to verify linux-next

[Damian Tometzki]

Hello,

i can tell you ubuntu 16.04 works under virtualbox 5.1.28 with the
current linux-next kernel

My maschine:
Host: Windows 10
Guest: Ubuntu 16.04

Am Freitag, den 29.09.2017, 08:41 -0400 schrieb
valdis.kletni...@vt.edu:
> On Fri, 29 Sep 2017 16:08:07 +0530, Pintu Kumar said:
> 
> > 
> > I have a general question.
> > How do we normally verify linux-next tree?
> The same exact way you "verify" any other Linux kernel, for whatever
> definition of "verify" you plan to use.
> 
> > 
> > 1) For Oracle virtual box 5.1.26 with ubuntu-32 bit, the linux-next
> > kernel is not booting.
> Does an Ubuntu kernel boot correctly under VirtualBox?  If not, fix
> that issue first.  Also, "is not booting" isn't detailed enough for
> anybody
> to make even a guess as to what's wrong.
> 
> Also, note that 5.1.28 is out.

Re: How to verify linux-next

[Damian Tometzki]

Hello,

Ubuntu 16.04 with current linux-next Kernel workson virtualbox 5.1.28

Host: Windows 10
Guest: Ubuntu 16.04

Best regards
Damian


Am Freitag, den 29.09.2017, 08:41 -0400 schrieb
valdis.kletni...@vt.edu:
> On Fri, 29 Sep 2017 16:08:07 +0530, Pintu Kumar said:
> 
> > 
> > I have a general question.
> > How do we normally verify linux-next tree?
> The same exact way you "verify" any other Linux kernel, for whatever
> definition of "verify" you plan to use.
> 
> > 
> > 1) For Oracle virtual box 5.1.26 with ubuntu-32 bit, the linux-next
> > kernel is not booting.
> Does an Ubuntu kernel boot correctly under VirtualBox?  If not, fix
> that issue first.  Also, "is not booting" isn't detailed enough for
> anybody
> to make even a guess as to what's wrong.
> 
> Also, note that 5.1.28 is out.

Re: How to verify linux-next

[Damian Tometzki]

Hello,

Ubuntu 16.04 with current linux-next Kernel workson virtualbox 5.1.28

Host: Windows 10
Guest: Ubuntu 16.04

Best regards
Damian


Am Freitag, den 29.09.2017, 08:41 -0400 schrieb
valdis.kletni...@vt.edu:
> On Fri, 29 Sep 2017 16:08:07 +0530, Pintu Kumar said:
> 
> > 
> > I have a general question.
> > How do we normally verify linux-next tree?
> The same exact way you "verify" any other Linux kernel, for whatever
> definition of "verify" you plan to use.
> 
> > 
> > 1) For Oracle virtual box 5.1.26 with ubuntu-32 bit, the linux-next
> > kernel is not booting.
> Does an Ubuntu kernel boot correctly under VirtualBox?  If not, fix
> that issue first.  Also, "is not booting" isn't detailed enough for
> anybody
> to make even a guess as to what's wrong.
> 
> Also, note that 5.1.28 is out.