1. 25 May, 2017 7 commits
    • Philippe Gerum's avatar
      ipipe-core-4.1.18-x86-9 · 24d9c42b
      Philippe Gerum authored
      24d9c42b
    • Philippe Gerum's avatar
      ipipe-core-4.1.18-powerpc-9 · af140f10
      Philippe Gerum authored
      af140f10
    • Philippe Gerum's avatar
      ipipe-core-4.1.18-blackfin-8 · 7afdc760
      Philippe Gerum authored
      7afdc760
    • Philippe Gerum's avatar
      ipipe-core-4.1.18-arm-10 · 1fb9c28e
      Philippe Gerum authored
      1fb9c28e
    • Philippe Gerum's avatar
      ipipe-core-4.1.18-arm64-8 · 7419ef0d
      Philippe Gerum authored
      7419ef0d
    • Philippe Gerum's avatar
      ipipe: do not attempt to preempt_schedule over the IRQ syncer · c6e43899
      Philippe Gerum authored
      Rescheduling over the IRQ log syncer is a source of infinite
      recursion, via preempt_schedule().
      
      Besides, rescheduling eagerly (if CONFIG_PREEMPT) after a virtual IRQ
      has been dispatched directly from the syncer is useless. If such virq
      was dispatched over a real IRQ context, the kernel exit code (entry.S)
      should notice the opportunity for preemption and reschedule. Likewise,
      if the virq was posted from a kernel context
      (e.g. ipipe_post_irq_root()), a rescheduling point will certainly be
      traversed before the kernel is exited or goes idle.
      c6e43899
    • Philippe Gerum's avatar
      ipipe/timer: apply minimum delay on close timer shot · 08cc334c
      Philippe Gerum authored
      When programming the timer, eagerly raising a timer IRQ by software
      via the pipeline for close shots (i.e. below the clock chip's minimum
      delay) may cause such event to happen too early for the co-kernel to
      actually deliver it to any handler, which in turn may trigger yet
      another request for programming the timer with too close a delay, and
      so on, until the current time eventually matches some pending event
      date.
      
      In such a case, the system may spend a lot of time trying to converge
      on a proper trigger date by looping into the clock event handling
      logic, delaying the co-kernel by the same amount.
      
      To fix this, always go through the clock hardware for programming a
      close shot with the minimum acceptable delay, which ensures that we
      won't receive the next timer event too early.
      08cc334c
  2. 21 May, 2017 1 commit
    • Philippe Gerum's avatar
      x86/ipipe: x86_64: fix stack overflow detection · 08bde997
      Philippe Gerum authored
      Due to the deferred IRQ dispatching model when the pipeline is active,
      the detection code may not assume that its runs over the preempted
      stack context, so regs->sp does not necessarily point at the current
      stack context anymore.
      
      Explicitly compare the current %rsp value against valid stack
      boundaries instead.
      
      This fixes spurious overflow detections when
      CONFIG_DEBUG_STACKOVERFLOW is enabled.
      08bde997
  3. 28 Feb, 2017 1 commit
    • Toshi Kani's avatar
      x86/mm: Fix vmalloc_fault() to handle large pages properly · 30974fdb
      Toshi Kani authored
      A kernel page fault oops with the callstack below was observed
      when a read syscall was made to a pmem device after a huge amount
      (>512GB) of vmalloc ranges was allocated by ioremap() on a x86_64
      system:
      
           BUG: unable to handle kernel paging request at ffff880840000ff8
           IP: vmalloc_fault+0x1be/0x300
           PGD c7f03a067 PUD 0
           Oops: 0000 [#1] SM
           Call Trace:
              __do_page_fault+0x285/0x3e0
              do_page_fault+0x2f/0x80
              ? put_prev_entity+0x35/0x7a0
              page_fault+0x28/0x30
              ? memcpy_erms+0x6/0x10
              ? schedule+0x35/0x80
              ? pmem_rw_bytes+0x6a/0x190 [nd_pmem]
              ? schedule_timeout+0x183/0x240
              btt_log_read+0x63/0x140 [nd_btt]
               :
              ? __symbol_put+0x60/0x60
              ? kernel_read+0x50/0x80
              SyS_finit_module+0xb9/0xf0
              entry_SYSCALL_64_fastpath+0x1a/0xa4
      
      Since v4.1, ioremap() supports large page (pud/pmd) mappings in
      x86_64 and PAE.  vmalloc_fault() however assumes that the vmalloc
      range is limited to pte mappings.
      
      vmalloc faults do not normally happen in ioremap'd ranges since
      ioremap() sets up the kernel page tables, which are shared by
      user processes.  pgd_ctor() sets the kernel's PGD entries to
      user's during fork().  When allocation of the vmalloc ranges
      crosses a 512GB boundary, ioremap() allocates a new pud table
      and updates the kernel PGD entry to point it.  If user process's
      PGD entry does not have this update yet, a read/write syscall
      to the range will cause a vmalloc fault, which hits the Oops
      above as it does not handle a large page properly.
      
      Following changes are made to vmalloc_fault().
      
      64-bit:
      
       - No change for the PGD sync operation as it handles large
         pages already.
       - Add pud_huge() and pmd_huge() to the validation code to
         handle large pages.
       - Change pud_page_vaddr() to pud_pfn() since an ioremap range
         is not directly mapped (while the if-statement still works
         with a bogus addr).
       - Change pmd_page() to pmd_pfn() since an ioremap range is not
         backed by struct page (while the if-statement still works
         with a bogus addr).
      
      32-bit:
       - No change for the sync operation since the index3 PGD entry
         covers the entire vmalloc range, which is always valid.
         (A separate change to sync PGD entry is necessary if this
          memory layout is changed regardless of the page size.)
       - Add pmd_huge() to the validation code to handle large pages.
         This is for completeness since vmalloc_fault() won't happen
         in ioremap'd ranges as its PGD entry is always valid.
      Reported-by: Henning Schild's avatarHenning Schild <henning.schild@siemens.com>
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Acked-by: default avatarBorislav Petkov <bp@alien8.de>
      Cc: <stable@vger.kernel.org> # 4.1+
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-mm@kvack.org
      Cc: linux-nvdimm@lists.01.org
      Link: http://lkml.kernel.org/r/1455758214-24623-1-git-send-email-toshi.kani@hpe.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      30974fdb
  4. 15 Feb, 2017 5 commits
  5. 13 Feb, 2017 2 commits
  6. 02 Feb, 2017 1 commit
    • Gunter Grau's avatar
      arm/ipipe: fix inaccurate RTC on 1 GHz bump · ea7e7b10
      Gunter Grau authored
      i.MX CPUs usually start with a lower CPU frequency and change to a
      higher frequency operating point at kernel start. It has been observed
      that when bumping e.g from 792 MHz to 996 MHz during boot, the Linux
      clock is counting faster than a RTC. Force the timekeeper to
      recalculate the clocksource after the bump. We achieve this by
      lowering the rating of the ipipe_tsc and lifting it up again.
      ea7e7b10
  7. 31 Dec, 2016 1 commit
  8. 25 Nov, 2016 1 commit
  9. 22 Nov, 2016 4 commits
    • Philippe Gerum's avatar
      arm64/ipipe: ignore inapplicable requests to set IRQ affinity · 2d56c541
      Philippe Gerum authored
      Generic client code does not necessarily know whether some IRQ can be
      given a CPU affinity (i.e. have a irq_set_affinity handler), but may
      have to try nevertheless.
      
      In addition, we filter out requests on pipeline-originated virtual
      IRQs, which have no chip descriptor either.
      2d56c541
    • Philippe Gerum's avatar
      x86/ipipe: ignore inapplicable requests to set IRQ affinity · 278a5013
      Philippe Gerum authored
      Generic client code does not necessarily know whether some IRQ can be
      given a CPU affinity (i.e. have a irq_set_affinity handler), but may
      have to try nevertheless.
      
      In addition, we filter out requests on pipeline-originated virtual
      IRQs, which have no chip descriptor either.
      278a5013
    • Philippe Gerum's avatar
      powerpc/ipipe: ignore inapplicable requests to set IRQ affinity · 91f329c7
      Philippe Gerum authored
      Generic client code does not necessarily know whether some IRQ can be
      given a CPU affinity (i.e. have a irq_set_affinity handler), but may
      have to try nevertheless.
      
      In addition, we filter out requests on pipeline-originated virtual
      IRQs, which have no chip descriptor either.
      91f329c7
    • Philippe Gerum's avatar
      arm/ipipe: ignore inapplicable requests to set IRQ affinity · 737829c7
      Philippe Gerum authored
      Generic client code does not necessarily know whether some IRQ can be
      given a CPU affinity (i.e. have a irq_set_affinity handler), but may
      have to try nevertheless.
      
      In addition, we filter out requests on pipeline-originated virtual
      IRQs, which have no chip descriptor either.
      737829c7
  10. 09 Sep, 2016 7 commits
  11. 08 Sep, 2016 1 commit
  12. 28 Aug, 2016 1 commit
  13. 17 Jul, 2016 5 commits
  14. 16 Jul, 2016 3 commits