1. 13 6月, 2016 19 次提交
  2. 10 6月, 2016 3 次提交
  3. 08 6月, 2016 8 次提交
    • B
      x86/cpu/AMD: Extend X86_FEATURE_TOPOEXT workaround to newer models · 96685a55
      Borislav Petkov 提交于
      We need to reenable the topology extensions CPUID leafs on newer models
      too, if BIOS has disabled them, as we rely on them to get proper compute
      unit topology.
      
      Make the printk a once thing, while at it.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      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: Peter Zijlstra <peterz@infradead.org>
      Cc: Rui Huang <ray.huang@amd.com>
      Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-hwmon@vger.kernel.org
      Link: http://lkml.kernel.org/r/1464775468-23355-1-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      96685a55
    • D
      x86/cpu/intel: Introduce macros for Intel family numbers · 970442c5
      Dave Hansen 提交于
      Problem:
      
      We have a boatload of open-coded family-6 model numbers.  Half of
      them have these model numbers in hex and the other half in
      decimal.  This makes grepping for them tons of fun, if you were
      to try.
      
      Solution:
      
      Consolidate all the magic numbers.  Put all the definitions in
      one header.
      
      The names here are closely derived from the comments describing
      the models from arch/x86/events/intel/core.c.  We could easily
      make them shorter by doing things like s/SANDYBRIDGE/SNB/, but
      they seemed fine even with the longer versions to me.
      
      Do not take any of these names too literally, like "DESKTOP"
      or "MOBILE".  These are all colloquial names and not precise
      descriptions of everywhere a given model will show up.
      Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Doug Thompson <dougthompson@xmission.com>
      Cc: Eduardo Valentin <edubezval@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
      Cc: Souvik Kumar Chakravarty <souvik.k.chakravarty@intel.com>
      Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Ulf Hansson <ulf.hansson@linaro.org>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Vishwanath Somayaji <vishwanath.somayaji@intel.com>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: jacob.jun.pan@intel.com
      Cc: linux-acpi@vger.kernel.org
      Cc: linux-edac@vger.kernel.org
      Cc: linux-mmc@vger.kernel.org
      Cc: linux-pm@vger.kernel.org
      Cc: platform-driver-x86@vger.kernel.org
      Link: http://lkml.kernel.org/r/20160603001927.F2A7D828@viggo.jf.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      970442c5
    • W
      arm64: mm: always take dirty state from new pte in ptep_set_access_flags · 0106d456
      Will Deacon 提交于
      Commit 66dbd6e6 ("arm64: Implement ptep_set_access_flags() for
      hardware AF/DBM") ensured that pte flags are updated atomically in the
      face of potential concurrent, hardware-assisted updates. However, Alex
      reports that:
      
       | This patch breaks swapping for me.
       | In the broken case, you'll see either systemd cpu time spike (because
       | it's stuck in a page fault loop) or the system hang (because the
       | application owning the screen is stuck in a page fault loop).
      
      It turns out that this is because the 'dirty' argument to
      ptep_set_access_flags is always 0 for read faults, and so we can't use
      it to set PTE_RDONLY. The failing sequence is:
      
        1. We put down a PTE_WRITE | PTE_DIRTY | PTE_AF pte
        2. Memory pressure -> pte_mkold(pte) -> clear PTE_AF
        3. A read faults due to the missing access flag
        4. ptep_set_access_flags is called with dirty = 0, due to the read fault
        5. pte is then made PTE_WRITE | PTE_DIRTY | PTE_AF | PTE_RDONLY (!)
        6. A write faults, but pte_write is true so we get stuck
      
      The solution is to check the new page table entry (as would be done by
      the generic, non-atomic definition of ptep_set_access_flags that just
      calls set_pte_at) to establish the dirty state.
      
      Cc: <stable@vger.kernel.org> # 4.3+
      Fixes: 66dbd6e6 ("arm64: Implement ptep_set_access_flags() for hardware AF/DBM")
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: NAlexander Graf <agraf@suse.de>
      Tested-by: NAlexander Graf <agraf@suse.de>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      0106d456
    • A
      powerpc/mm/hash: Compute the segment size correctly for ISA 3.0 · 3b6d1eb7
      Aneesh Kumar K.V 提交于
      PowerISA 3.0 encodes the segment size in the second half of hash page
      table entry. Update hpte_decode() accordingly.
      
      Fixes: 50de596d ("powerpc/mm/hash: Add support for Power9 Hash")
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      3b6d1eb7
    • A
      powerpc/mm/radix: Fix always false comparison against MMU_NO_CONTEXT · 9690c157
      Aneesh Kumar K.V 提交于
      In some of the radix TLB flush routines, we use a local to store the
      mm->context.id, AKA the PID.
      
      Currently we use an int, but the PID is unsigned long, so large values
      of PID will be truncated. In particular MMU_NO_CONTEXT is -1, which
      means all our comparisons against that value can never be true.
      
      This means we'll issue TLB flushes when we shouldn't on radix enabled
      machines.
      
      Fix it by using an unsigned long for the local. Discovered by Coverity.
      
      Fixes: 1a472c9d ("powerpc/mm/radix: Add tlbflush routines")
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Reviewed-by: NBalbir Singh <bsingharora@gmail.com>
      [mpe: Write change log]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      9690c157
    • M
      coredump: fix dumping through pipes · 1607f09c
      Mateusz Guzik 提交于
      The offset in the core file used to be tracked with ->written field of
      the coredump_params structure. The field was retired in favour of
      file->f_pos.
      
      However, ->f_pos is not maintained for pipes which leads to breakage.
      
      Restore explicit tracking of the offset in coredump_params. Introduce
      ->pos field for this purpose since ->written was already reused.
      
      Fixes: a0083939 ("get rid of coredump_params->written").
      Reported-by: NZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
      Signed-off-by: NMateusz Guzik <mguzik@redhat.com>
      Reviewed-by: NOmar Sandoval <osandov@fb.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1607f09c
    • M
      powerpc/pseries: Fix IBM_ARCH_VEC_NRCORES_OFFSET since POWER8NVL was added · 2c2a63e3
      Michael Ellerman 提交于
      The recent commit 7cc85103 ("powerpc/pseries: Add POWER8NVL support
      to ibm,client-architecture-support call") added a new PVR mask & value
      to the start of the ibm_architecture_vec[] array.
      
      However it missed the fact that further down in the array, we hard code
      the offset of one of the fields, and then at boot use that value to
      patch the value in the array. This means every update to the array must
      also update the #define, ugh.
      
      This means that on pseries machines we will misreport to firmware the
      number of cores we support, by a factor of threads_per_core.
      
      Fix it for now by updating the #define.
      
      Fixes: 7cc85103 ("powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support call")
      Cc: stable@vger.kernel.org # v4.0+
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      2c2a63e3
    • H
      x86, build: copy ldlinux.c32 to image.iso · 9c77679c
      H. Peter Anvin 提交于
      For newer versions of Syslinux, we need ldlinux.c32 in addition to
      isolinux.bin to reside on the boot disk, so if the latter is found,
      copy it, too, to the isoimage tree.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Linux Stable Tree <stable@vger.kernel.org>
      9c77679c
  4. 06 6月, 2016 3 次提交
  5. 05 6月, 2016 4 次提交
    • H
      58f1c654
    • H
      parisc: Fix pagefault crash in unaligned __get_user() call · 8b78f260
      Helge Deller 提交于
      One of the debian buildd servers had this crash in the syslog without
      any other information:
      
       Unaligned handler failed, ret = -2
       clock_adjtime (pid 22578): Unaligned data reference (code 28)
       CPU: 1 PID: 22578 Comm: clock_adjtime Tainted: G  E  4.5.0-2-parisc64-smp #1 Debian 4.5.4-1
       task: 000000007d9960f8 ti: 00000001bde7c000 task.ti: 00000001bde7c000
      
            YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
       PSW: 00001000000001001111100000001111 Tainted: G            E
       r00-03  000000ff0804f80f 00000001bde7c2b0 00000000402d2be8 00000001bde7c2b0
       r04-07  00000000409e1fd0 00000000fa6f7fff 00000001bde7c148 00000000fa6f7fff
       r08-11  0000000000000000 00000000ffffffff 00000000fac9bb7b 000000000002b4d4
       r12-15  000000000015241c 000000000015242c 000000000000002d 00000000fac9bb7b
       r16-19  0000000000028800 0000000000000001 0000000000000070 00000001bde7c218
       r20-23  0000000000000000 00000001bde7c210 0000000000000002 0000000000000000
       r24-27  0000000000000000 0000000000000000 00000001bde7c148 00000000409e1fd0
       r28-31  0000000000000001 00000001bde7c320 00000001bde7c350 00000001bde7c218
       sr00-03  0000000001200000 0000000001200000 0000000000000000 0000000001200000
       sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      
       IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000402d2e84 00000000402d2e88
        IIR: 0ca0d089    ISR: 0000000001200000  IOR: 00000000fa6f7fff
        CPU:        1   CR30: 00000001bde7c000 CR31: ffffffffffffffff
        ORIG_R28: 00000002369fe628
        IAOQ[0]: compat_get_timex+0x2dc/0x3c0
        IAOQ[1]: compat_get_timex+0x2e0/0x3c0
        RP(r2): compat_get_timex+0x40/0x3c0
       Backtrace:
        [<00000000402d4608>] compat_SyS_clock_adjtime+0x40/0xc0
        [<0000000040205024>] syscall_exit+0x0/0x14
      
      This means the userspace program clock_adjtime called the clock_adjtime()
      syscall and then crashed inside the compat_get_timex() function.
      Syscalls should never crash programs, but instead return EFAULT.
      
      The IIR register contains the executed instruction, which disassebles
      into "ldw 0(sr3,r5),r9".
      This load-word instruction is part of __get_user() which tried to read the word
      at %r5/IOR (0xfa6f7fff). This means the unaligned handler jumped in.  The
      unaligned handler is able to emulate all ldw instructions, but it fails if it
      fails to read the source e.g. because of page fault.
      
      The following program reproduces the problem:
      
      #define _GNU_SOURCE
      #include <unistd.h>
      #include <sys/syscall.h>
      #include <sys/mman.h>
      
      int main(void) {
              /* allocate 8k */
              char *ptr = mmap(NULL, 2*4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
              /* free second half (upper 4k) and make it invalid. */
              munmap(ptr+4096, 4096);
              /* syscall where first int is unaligned and clobbers into invalid memory region */
              /* syscall should return EFAULT */
              return syscall(__NR_clock_adjtime, 0, ptr+4095);
      }
      
      To fix this issue we simply need to check if the faulting instruction address
      is in the exception fixup table when the unaligned handler failed. If it
      is, call the fixup routine instead of crashing.
      
      While looking at the unaligned handler I found another issue as well: The
      target register should not be modified if the handler was unsuccessful.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org
      8b78f260
    • H
      parisc: Fix printk time during boot · 0032c088
      Helge Deller 提交于
      Avoid showing invalid printk time stamps during boot.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Reviewed-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      0032c088
    • M
      parisc: Fix backtrace on PA-RISC · be24a897
      Mikulas Patocka 提交于
      This patch fixes backtrace on PA-RISC
      
      There were several problems:
      
      1) The code that decodes instructions handles instructions that subtract
      from the stack pointer incorrectly. If the instruction subtracts the
      number X from the stack pointer the code increases the frame size by
      (0x100000000-X).  This results in invalid accesses to memory and
      recursive page faults.
      
      2) Because gcc reorders blocks, handling instructions that subtract from
      the frame pointer is incorrect. For example, this function
      	int f(int a)
      	{
      		if (__builtin_expect(a, 1))
      			return a;
      		g();
      		return a;
      	}
      is compiled in such a way, that the code that decreases the stack
      pointer for the first "return a" is placed before the code for "g" call.
      If we recognize this decrement, we mistakenly believe that the frame
      size for the "g" call is zero.
      
      To fix problems 1) and 2), the patch doesn't recognize instructions that
      decrease the stack pointer at all. To further safeguard the unwind code
      against nonsense values, we don't allow frame size larger than
      Total_frame_size.
      
      3) The backtrace is not locked. If stack dump races with module unload,
      invalid table can be accessed.
      
      This patch adds a spinlock when processing module tables.
      
      Note, that for correct backtrace, you need recent binutils.
      Binutils 2.18 from Debian 5 produce garbage unwind tables.
      Binutils 2.21 work better (it sometimes forgets function frames, but at
      least it doesn't generate garbage).
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      be24a897
  6. 03 6月, 2016 3 次提交
    • M
      arm64: fix alignment when RANDOMIZE_TEXT_OFFSET is enabled · aed7eb83
      Mark Rutland 提交于
      With ARM64_64K_PAGES and RANDOMIZE_TEXT_OFFSET enabled, we hit the
      following issue on the boot:
      
      kernel BUG at arch/arm64/mm/mmu.c:480!
      Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0 #310
      Hardware name: ARM Juno development board (r2) (DT)
      task: ffff000008d58a80 ti: ffff000008d30000 task.ti: ffff000008d30000
      PC is at map_kernel_segment+0x44/0xb0
      LR is at paging_init+0x84/0x5b0
      pc : [<ffff000008c450b4>] lr : [<ffff000008c451a4>] pstate: 600002c5
      
      Call trace:
      [<ffff000008c450b4>] map_kernel_segment+0x44/0xb0
      [<ffff000008c451a4>] paging_init+0x84/0x5b0
      [<ffff000008c42728>] setup_arch+0x198/0x534
      [<ffff000008c40848>] start_kernel+0x70/0x388
      [<ffff000008c401bc>] __primary_switched+0x30/0x74
      
      Commit 7eb90f2f ("arm64: cover the .head.text section in the .text
      segment mapping") removed the alignment between the .head.text and .text
      sections, and used the _text rather than the _stext interval for mapping
      the .text segment.
      
      Prior to this commit _stext was always section aligned and didn't cause
      any issue even when RANDOMIZE_TEXT_OFFSET was enabled. Since that
      alignment has been removed and _text is used to map the .text segment,
      we need ensure _text is always page aligned when RANDOMIZE_TEXT_OFFSET
      is enabled.
      
      This patch adds logic to TEXT_OFFSET fuzzing to ensure that the offset
      is always aligned to the kernel page size. To ensure this, we rely on
      the PAGE_SHIFT being available via Kconfig.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Reported-by: NSudeep Holla <sudeep.holla@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Fixes: 7eb90f2f ("arm64: cover the .head.text section in the .text segment mapping")
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      aed7eb83
    • M
      arm64: move {PAGE,CONT}_SHIFT into Kconfig · 030c4d24
      Mark Rutland 提交于
      In some cases (e.g. the awk for CONFIG_RANDOMIZE_TEXT_OFFSET) we would
      like to make use of PAGE_SHIFT outside of code that can include the
      usual header files.
      
      Add a new CONFIG_ARM64_PAGE_SHIFT for this, likewise with
      ARM64_CONT_SHIFT for consistency.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      030c4d24
    • M
      arm64: mm: dump: log span level · 48dd73c5
      Mark Rutland 提交于
      The page table dump code logs spans of entries at the same level
      (pgd/pud/pmd/pte) which have the same attributes. While we log the
      (decoded) attributes, we don't log the level, which leaves the output
      ambiguous and/or confusing in some cases.
      
      For example:
      
      0xffff800800000000-0xffff800980000000           6G       RW NX SHD AF        BLK UXN MEM/NORMAL
      
      If using 4K pages, this may describe a span of 6 1G block entries at the
      PGD/PUD level, or 3072 2M block entries at the PMD level.
      
      This patch adds the page table level to each output line, removing this
      ambiguity. For the example above, this will produce:
      
      0xffffffc800000000-0xffffffc980000000           6G PUD       RW NX SHD AF        BLK UXN MEM/NORMAL
      
      When 3 level tables are in use, and we use the asm-generic/nopud.h
      definitions, the dump code treats each entry in the PGD as a 1 element
      table at the PUD level, and logs spans as being PUDs, which can be
      confusing. To counteract this, the "PUD" mnemonic is replaced with "PGD"
      when CONFIG_PGTABLE_LEVELS <= 3. Likewise for "PMD" when
      CONFIG_PGTABLE_LEVELS <= 2.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Huang Shijie <shijie.huang@arm.com>
      Cc: Laura Abbott <labbott@fedoraproject.org>
      Cc: Steve Capper <steve.capper@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      48dd73c5