09 Nov, 2017

1 commit

  • Commit 7744ccdbc16f0 ("x86/mm: Add Secure Memory Encryption (SME)
    support") as a side-effect made PAGE_KERNEL all of a sudden unavailable
    to modules which can't make use of EXPORT_SYMBOL_GPL() symbols.

    This is because once SME is enabled, sme_me_mask (which is introduced as
    EXPORT_SYMBOL_GPL) makes its way to PAGE_KERNEL through _PAGE_ENC,
    causing imminent build failure for all the modules which make use of all
    the EXPORT-SYMBOL()-exported API (such as vmap(), __vmalloc(),
    remap_pfn_range(), ...).

    Exporting (as EXPORT_SYMBOL()) interfaces (and having done so for ages)
    that take pgprot_t argument, while making it impossible to -- all of a
    sudden -- pass PAGE_KERNEL to it, feels rather incosistent.

    Restore the original behavior and make it possible to pass PAGE_KERNEL
    to all its EXPORT_SYMBOL() consumers.

    [ This is all so not wonderful. We shouldn't need that "sme_me_mask"
    access at all in all those places that really don't care about that
    level of detail, and just want _PAGE_KERNEL or whatever.

    We have some similar issues with _PAGE_CACHE_WP and _PAGE_NOCACHE,
    both of which hide a "cachemode2protval()" call, and which also ends
    up using another EXPORT_SYMBOL(), but at least that only triggers for
    the much more rare cases.

    Maybe we could move these dynamic page table bits to be generated much
    deeper down in the VM layer, instead of hiding them in the macros that
    everybody uses.

    So this all would merit some cleanup. But not today. - Linus ]

    Cc: Tom Lendacky
    Signed-off-by: Jiri Kosina
    Despised-by: Thomas Gleixner
    Signed-off-by: Linus Torvalds

    Jiri Kosina
     

07 Nov, 2017

1 commit


06 Nov, 2017

2 commits


05 Nov, 2017

5 commits

  • There have been some cases where external tooling (e.g., kpatch-build)
    creates a corrupt relocation which targets the wrong address. This is a
    silent failure which can corrupt memory in unexpected places.

    On x86, the bytes of data being overwritten by relocations are always
    initialized to zero beforehand. Use that knowledge to add sanity checks
    to detect such cases before they corrupt memory.

    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: jeyu@kernel.org
    Cc: live-patching@vger.kernel.org
    Link: http://lkml.kernel.org/r/37450d6c6225e54db107fba447ce9e56e5f758e9.1509713553.git.jpoimboe@redhat.com
    [ Restructured the messages, as it's unclear whether the relocation or the target is corrupted. ]
    Signed-off-by: Ingo Molnar

    Josh Poimboeuf
     
  • Pull ARM fixes from Russell King:

    - omit EFI memory map sorting, which was recently introduced, but
    caused problems with the decompressor due to additional sections
    being emitted.

    - avoid unaligned load fault-generating instructions in the
    decompressor by switching to a private unaligned implementation.

    - add a symbol into the decompressor to further debug non-boot
    situations (ld's documentation is extremely poor for how "." works,
    ld doesn't seem to follow its own documentation!)

    - parse endian information to sparse

    * 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
    ARM: add debug ".edata_real" symbol
    ARM: 8716/1: pass endianness info to sparse
    efi/libstub: arm: omit sorting of the UEFI memory map
    ARM: 8715/1: add a private asm/unaligned.h

    Linus Torvalds
     
  • Pull KVM fixes from Paolo Bonzini:
    "Fixes for interrupt controller emulation in ARM/ARM64 and x86, plus a
    one-liner x86 KVM guest fix"

    * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
    KVM: x86: Update APICv on APIC reset
    KVM: VMX: Do not fully reset PI descriptor on vCPU reset
    kvm: Return -ENODEV from update_persistent_clock
    KVM: arm/arm64: vgic-its: Check GITS_BASER Valid bit before saving tables
    KVM: arm/arm64: vgic-its: Check CBASER/BASER validity before enabling the ITS
    KVM: arm/arm64: vgic-its: Fix vgic_its_restore_collection_table returned value
    KVM: arm/arm64: vgic-its: Fix return value for device table restore
    arm/arm64: kvm: Disable branch profiling in HYP code
    arm/arm64: kvm: Move initialization completion message
    arm/arm64: KVM: set right LR register value for 32 bit guest when inject abort
    KVM: arm64: its: Fix missing dynamic allocation check in scan_its_table

    Linus Torvalds
     
  • Pull ARM SoC fixes from Arnd Bergmann:
    "Only two patches came in over the last two weeks: Uniphier USB support
    needs additional clocks enabled (on both 32-bit and 64-bit ARM), and a
    Marvell MVEBU stability issue has been fixed"

    * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
    ARM: dts: mvebu: pl310-cache disable double-linefill
    arm64: dts: uniphier: add STDMAC clock to EHCI nodes
    ARM: dts: uniphier: add STDMAC clock to EHCI nodes

    Linus Torvalds
     
  • Pull MIPS fixes from James Hogan:
    "A selection of important MIPS fixes for 4.14, and some MAINTAINERS /
    email address updates:

    Maintainership updates:
    - imgtec.com -> mips.com email addresses (this trivially updates
    comments in quite a few files, as well as MAINTAINERS)
    - Pistachio SoC maintainership update

    Fixes:
    - NI 169445 build (new platform in 4.14)
    - EVA regression (4.14)
    - SMP-CPS build & preemption regressions (4.14)
    - SMP/hotplug deadlock & race (deadlock reintroduced 4.13)
    - ebpf_jit error return (4.13)
    - SMP-CMP build regressions (4.11 and 4.14)
    - bad UASM microMIPS encoding (3.16)
    - CM definitions (3.15)"

    [ I had taken the email address updates separately, because I didn't
    expect James to send a pull request, so those got applied twice. - Linus]

    * tag 'mips_fixes_4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips:
    MIPS: Update email address for Marcin Nowakowski
    MIPS: smp-cmp: Fix vpe_id build error
    MAINTAINERS: Update Pistachio platform maintainers
    MIPS: smp-cmp: Use right include for task_struct
    MIPS: Update Goldfish RTC driver maintainer email address
    MIPS: Update RINT emulation maintainer email address
    MIPS: CPS: Fix use of current_cpu_data in preemptible code
    MIPS: SMP: Fix deadlock & online race
    MIPS: bpf: Fix a typo in build_one_insn()
    MIPS: microMIPS: Fix incorrect mask in insn_table_MM
    MIPS: Fix CM region target definitions
    MIPS: generic: Fix compilation error from include asm/mips-cpc.h
    MIPS: Fix exception entry when CONFIG_EVA enabled
    MIPS: generic: Fix NI 169445 its build
    Update MIPS email addresses

    Linus Torvalds
     

04 Nov, 2017

5 commits

  • This reverts commit 43858b4f25cf0adc5c2ca9cf5ce5fdf2532941e5.

    The reason I removed the leave_mm() calls in question is because the
    heuristic wasn't needed after that patch. With the original version
    of my PCID series, we never flushed a "lazy cpu" (i.e. a CPU running
    kernel thread) due a flush on the loaded mm.

    Unfortunately, that caused architectural issues, so now I've
    reinstated these flushes on non-PCID systems in:

    commit b956575bed91 ("x86/mm: Flush more aggressively in lazy TLB mode").

    That, in turn, gives us a power management and occasionally
    performance regression as compared to old kernels: a process that
    goes into a deep idle state on a given CPU and gets its mm flushed
    due to activity on a different CPU will wake the idle CPU.

    Reinstate the old ugly heuristic: if a CPU goes into ACPI C3 or an
    intel_idle state that is likely to cause a TLB flush gets its mm
    switched to init_mm before going idle.

    FWIW, this heuristic is lousy. Whether we should change CR3 before
    idle isn't a good hint except insofar as the performance hit is a bit
    lower if the TLB is getting flushed by the idle code anyway. What we
    really want to know is whether we anticipate being idle long enough
    that the mm is likely to be flushed before we wake up. This is more a
    matter of the expected latency than the idle state that gets chosen.
    This heuristic also completely fails on systems that don't know
    whether the TLB will be flushed (e.g. AMD systems?). OTOH it may be a
    bit obsolete anyway -- PCID systems don't presently benefit from this
    heuristic at all.

    We also shouldn't do this callback from innermost bit of the idle code
    due to the RCU nastiness it causes. All the information need is
    available before rcu_idle_enter() needs to happen.

    Signed-off-by: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Fixes: 43858b4f25cf "x86/mm: Stop calling leave_mm() in idle code"
    Link: http://lkml.kernel.org/r/c513bbd4e653747213e05bc7062de000bf0202a5.1509793738.git.luto@kernel.org
    Signed-off-by: Ingo Molnar

    Andy Lutomirski
     
  • Pull arch/tile fixes from Chris Metcalf:
    "Two one-line bug fixes"

    * git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
    arch/tile: Implement ->set_state_oneshot_stopped()
    tile: pass machine size to sparse

    Linus Torvalds
     
  • set_state_oneshot_stopped() is called by the clkevt core, when the
    next event is required at an expiry time of 'KTIME_MAX'. This normally
    happens with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes.

    This patch makes the clockevent device to stop on such an event, to
    avoid spurious interrupts, as explained by: commit 8fff52fd5093
    ("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state").

    Signed-off-by: Chris Metcalf

    Chris Metcalf
     
  • Pull powerpc fixes from Michael Ellerman:
    "Some more powerpc fixes for 4.14.

    This is bigger than I like to send at rc7, but that's at least partly
    because I didn't send any fixes last week. If it wasn't for the IMC
    driver, which is new and getting heavy testing, the diffstat would
    look a bit better. I've also added ftrace on big endian to my test
    suite, so we shouldn't break that again in future.

    - A fix to the handling of misaligned paste instructions (P9 only),
    where a change to a #define has caused the check for the
    instruction to always fail.

    - The preempt handling was unbalanced in the radix THP flush (P9
    only). Though we don't generally use preempt we want to keep it
    working as much as possible.

    - Two fixes for IMC (P9 only), one when booting with restricted
    number of CPUs and one in the error handling when initialisation
    fails due to firmware etc.

    - A revert to fix function_graph on big endian machines, and then a
    rework of the reverted patch to fix kprobes blacklist handling on
    big endian machines.

    Thanks to: Anju T Sudhakar, Guilherme G. Piccoli, Madhavan Srinivasan,
    Naveen N. Rao, Nicholas Piggin, Paul Mackerras"

    * tag 'powerpc-4.14-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
    powerpc/perf: Fix core-imc hotplug callback failure during imc initialization
    powerpc/kprobes: Dereference function pointers only if the address does not belong to kernel text
    Revert "powerpc64/elfv1: Only dereference function descriptor for non-text symbols"
    powerpc/64s/radix: Fix preempt imbalance in TLB flush
    powerpc: Fix check for copy/paste instructions in alignment handler
    powerpc/perf: Fix IMC allocation routine

    Linus Torvalds
     
  • MIPS will soon not be a part of Imagination Technologies, and as such
    many @imgtec.com email addresses will no longer be valid. This patch
    updates the addresses for those who:

    - Have 10 or more patches in mainline authored using an @imgtec.com
    email address, or any patches dated within the past year.

    - Are still with Imagination but leaving as part of the MIPS business
    unit, as determined from an internal email address list.

    - Haven't already updated their email address (ie. JamesH) or expressed
    a desire to be excluded (ie. Maciej).

    - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt &
    myself.

    New addresses are of the form firstname.lastname@mips.com, and all
    verified against an internal email address list. An entry is added to
    .mailmap for each person such that get_maintainer.pl will report the new
    addresses rather than @imgtec.com addresses which will soon be dead.

    Instances of the affected addresses throughout the tree are then
    mechanically replaced with the new @mips.com address.

    Signed-off-by: Paul Burton
    Cc: Deng-Cheng Zhu
    Cc: Deng-Cheng Zhu
    Acked-by: Dengcheng Zhu
    Cc: Matt Redfearn
    Cc: Matt Redfearn
    Acked-by: Matt Redfearn
    Cc: Andrew Morton
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Cc: trivial@kernel.org
    Signed-off-by: Linus Torvalds

    Paul Burton
     

03 Nov, 2017

12 commits

  • Commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for
    /proc/cpuinfo "cpu MHz"") is not sufficient to restore the previous
    behavior of "cpu MHz" in /proc/cpuinfo on x86 due to some changes
    made after the commit it has reverted.

    To address this, make the code in question use arch_freq_get_on_cpu()
    which also is used by cpufreq for reporting the current frequency of
    CPUs and since that function doesn't really depend on cpufreq in any
    way, drop the CONFIG_CPU_FREQ dependency for the object file
    containing it.

    Also refactor arch_freq_get_on_cpu() somewhat to avoid IPIs and
    return cached values right away if it is called very often over a
    short time (to prevent user space from triggering IPI storms through
    it).

    Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
    Cc: stable@kernel.org # 4.13 - together with 890da9cf0983
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Linus Torvalds

    Rafael J. Wysocki
     
  • struct sha1_ctx_mgr allocated in sha1_mb_mod_init() via kzalloc()
    and later passed in sha1_mb_flusher_mgr_flush_avx2() function where
    instructions vmovdqa used to access the struct. vmovdqa requires
    16-bytes aligned argument, but nothing guarantees that struct
    sha1_ctx_mgr will have that alignment. Unaligned vmovdqa will
    generate GP fault.

    Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment
    requirements.

    Fixes: 2249cbb53ead ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2")
    Signed-off-by: Andrey Ryabinin
    Cc:
    Signed-off-by: Herbert Xu

    Andrey Ryabinin
     
  • struct sha256_ctx_mgr allocated in sha256_mb_mod_init() via kzalloc()
    and later passed in sha256_mb_flusher_mgr_flush_avx2() function where
    instructions vmovdqa used to access the struct. vmovdqa requires
    16-bytes aligned argument, but nothing guarantees that struct
    sha256_ctx_mgr will have that alignment. Unaligned vmovdqa will
    generate GP fault.

    Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment
    requirements.

    Fixes: a377c6b1876e ("crypto: sha256-mb - submit/flush routines for AVX2")
    Reported-by: Josh Poimboeuf
    Signed-off-by: Andrey Ryabinin
    Cc:
    Acked-by: Tim Chen
    Signed-off-by: Herbert Xu

    Andrey Ryabinin
     
  • Call trace observed during boot:

    nest_capp0_imc performance monitor hardware support registered
    nest_capp1_imc performance monitor hardware support registered
    core_imc memory allocation for cpu 56 failed
    Unable to handle kernel paging request for data at address 0xffa400010
    Faulting instruction address: 0xc000000000bf3294
    0:mon> e
    cpu 0x0: Vector: 300 (Data Access) at [c000000ff38ff8d0]
    pc: c000000000bf3294: mutex_lock+0x34/0x90
    lr: c000000000bf3288: mutex_lock+0x28/0x90
    sp: c000000ff38ffb50
    msr: 9000000002009033
    dar: ffa400010
    dsisr: 80000
    current = 0xc000000ff383de00
    paca = 0xc000000007ae0000 softe: 0 irq_happened: 0x01
    pid = 13, comm = cpuhp/0
    Linux version 4.11.0-39.el7a.ppc64le (mockbuild@ppc-058.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) ) #1 SMP Tue Oct 3 07:42:44 EDT 2017
    0:mon> t
    [c000000ff38ffb80] c0000000002ddfac perf_pmu_migrate_context+0xac/0x470
    [c000000ff38ffc40] c00000000011385c ppc_core_imc_cpu_offline+0x1ac/0x1e0
    [c000000ff38ffc90] c000000000125758 cpuhp_invoke_callback+0x198/0x5d0
    [c000000ff38ffd00] c00000000012782c cpuhp_thread_fun+0x8c/0x3d0
    [c000000ff38ffd60] c0000000001678d0 smpboot_thread_fn+0x290/0x2a0
    [c000000ff38ffdc0] c00000000015ee78 kthread+0x168/0x1b0
    [c000000ff38ffe30] c00000000000b368 ret_from_kernel_thread+0x5c/0x74

    While registering the cpuhoplug callbacks for core-imc, if we fails
    in the cpuhotplug online path for any random core (either because opal call to
    initialize the core-imc counters fails or because memory allocation fails for
    that core), ppc_core_imc_cpu_offline() will get invoked for other cpus who
    successfully returned from cpuhotplug online path.

    But in the ppc_core_imc_cpu_offline() path we are trying to migrate the event
    context, when core-imc counters are not even initialized. Thus creating the
    above stack dump.

    Add a check to see if core-imc counters are enabled or not in the cpuhotplug
    offline path before migrating the context to handle this failing scenario.

    Fixes: 885dcd709ba9 ("powerpc/perf: Add nest IMC PMU support")
    Signed-off-by: Madhavan Srinivasan
    Signed-off-by: Anju T Sudhakar
    Signed-off-by: Michael Ellerman

    Madhavan Srinivasan
     
  • This reverts commit 51204e0639c49ada02fd823782ad673b6326d748.

    There wasn't really any good reason for it, and people are complaining
    (rightly) that it broke existing practice.

    Cc: Len Brown
    Cc: Thomas Gleixner
    Cc: Rafael J. Wysocki
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • Pull arm64 fix from Catalin Marinas:
    "Check addr_limit in arm64 __dump_instr()"

    * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
    arm64: ensure __dump_instr() checks addr_limit

    Linus Torvalds
     
  • It's possible for a user to deliberately trigger __dump_instr with a
    chosen kernel address.

    Let's avoid problems resulting from this by using get_user() rather than
    __get_user(), ensuring that we don't erroneously access kernel memory.

    Where we use __dump_instr() on kernel text, we already switch to
    KERNEL_DS, so this shouldn't adversely affect those cases.

    Fixes: 60ffc30d5652810d ("arm64: Exception handling")
    Cc: stable@vger.kernel.org
    Acked-by: Will Deacon
    Signed-off-by: Mark Rutland
    Signed-off-by: Catalin Marinas

    Mark Rutland
     
  • …/git/kvmarm/kvmarm into kvm-master

    KVM/ARM Fixes for v4.14

    - Fixes a number of issues with saving/restoring the ITS
    - Fixes a bug in KVM/ARM when branch profiling is enabled in Hyp mode
    - Fixes an emulation bug for 32-bit guests when injecting aborts
    - Fixes a failure to check if a kmalloc succeeds in the ITS emulation

    Paolo Bonzini
     
  • In kvm_apic_set_state() we update the hardware virtualized APIC after
    the full APIC state has been overwritten. Do the same, when the full
    APIC state has been reset in kvm_lapic_reset().

    This updates some hardware state that was previously forgotten, as
    far as I can tell. Also, this allows removing some APIC-related reset
    code from vmx_vcpu_reset().

    Signed-off-by: Jan H. Schönherr
    Signed-off-by: Paolo Bonzini

    Jan H. Schönherr
     
  • Parts of the posted interrupt descriptor configure host behavior,
    such as the notification vector and destination. Overwriting them
    with zero as done during vCPU reset breaks posted interrupts.
    KVM (re-)writes these fields on certain occasions and belatedly fixes
    the situation in many cases. However, if you have a guest configured
    with "idle=poll", for example, the fields might stay zero forever.

    Do not reset the full descriptor in vmx_vcpu_reset(). Instead,
    reset only the outstanding notifications and leave everything
    else untouched.

    Signed-off-by: Jan H. Schönherr
    Signed-off-by: Paolo Bonzini

    Jan H. Schönherr
     
  • kvm does not support setting the RTC, so the correct result is -ENODEV.
    Returning -1 will cause sync_cmos_clock to keep trying to set the RTC
    every second.

    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Paolo Bonzini

    Jason Gunthorpe
     
  • …el/git/gregkh/driver-core

    Pull initial SPDX identifiers from Greg KH:
    "License cleanup: add SPDX license identifiers to some files

    Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the
    'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally
    binding shorthand, which can be used instead of the full boiler plate
    text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart
    and Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset
    of the use cases:

    - file had no licensing information it it.

    - file was a */uapi/* one with no licensing information in it,

    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to
    license had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied
    to a file was done in a spreadsheet of side by side results from of
    the output of two independent scanners (ScanCode & Windriver)
    producing SPDX tag:value files created by Philippe Ombredanne.
    Philippe prepared the base worksheet, and did an initial spot review
    of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537
    files assessed. Kate Stewart did a file by file comparison of the
    scanner results in the spreadsheet to determine which SPDX license
    identifier(s) to be applied to the file. She confirmed any
    determination that was not immediately clear with lawyers working with
    the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:

    - Files considered eligible had to be source code files.

    - Make and config files were included as candidates if they contained
    >5 lines of source

    - File already had some variant of a license header in it (even if <5
    lines).

    All documentation files were explicitly excluded.

    The following heuristics were used to determine which SPDX license
    identifiers to apply.

    - when both scanners couldn't find any license traces, file was
    considered to have no license information in it, and the top level
    COPYING file license applied.

    For non */uapi/* files that summary was:

    SPDX license identifier # files
    ---------------------------------------------------|-------
    GPL-2.0 11139

    and resulted in the first patch in this series.

    If that file was a */uapi/* path one, it was "GPL-2.0 WITH
    Linux-syscall-note" otherwise it was "GPL-2.0". Results of that
    was:

    SPDX license identifier # files
    ---------------------------------------------------|-------
    GPL-2.0 WITH Linux-syscall-note 930

    and resulted in the second patch in this series.

    - if a file had some form of licensing information in it, and was one
    of the */uapi/* ones, it was denoted with the Linux-syscall-note if
    any GPL family license was found in the file or had no licensing in
    it (per prior point). Results summary:

    SPDX license identifier # files
    ---------------------------------------------------|------
    GPL-2.0 WITH Linux-syscall-note 270
    GPL-2.0+ WITH Linux-syscall-note 169
    ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
    ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
    LGPL-2.1+ WITH Linux-syscall-note 15
    GPL-1.0+ WITH Linux-syscall-note 14
    ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
    LGPL-2.0+ WITH Linux-syscall-note 4
    LGPL-2.1 WITH Linux-syscall-note 3
    ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
    ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

    and that resulted in the third patch in this series.

    - when the two scanners agreed on the detected license(s), that
    became the concluded license(s).

    - when there was disagreement between the two scanners (one detected
    a license but the other didn't, or they both detected different
    licenses) a manual inspection of the file occurred.

    - In most cases a manual inspection of the information in the file
    resulted in a clear resolution of the license that should apply
    (and which scanner probably needed to revisit its heuristics).

    - When it was not immediately clear, the license identifier was
    confirmed with lawyers working with the Linux Foundation.

    - If there was any question as to the appropriate license identifier,
    the file was flagged for further research and to be revisited later
    in time.

    In total, over 70 hours of logged manual review was done on the
    spreadsheet to determine the SPDX license identifiers to apply to the
    source files by Kate, Philippe, Thomas and, in some cases,
    confirmation by lawyers working with the Linux Foundation.

    Kate also obtained a third independent scan of the 4.13 code base from
    FOSSology, and compared selected files where the other two scanners
    disagreed against that SPDX file, to see if there was new insights.
    The Windriver scanner is based on an older version of FOSSology in
    part, so they are related.

    Thomas did random spot checks in about 500 files from the spreadsheets
    for the uapi headers and agreed with SPDX license identifier in the
    files he inspected. For the non-uapi files Thomas did random spot
    checks in about 15000 files.

    In initial set of patches against 4.14-rc6, 3 files were found to have
    copy/paste license identifier errors, and have been fixed to reflect
    the correct identifier.

    Additionally Philippe spent 10 hours this week doing a detailed manual
    inspection and review of the 12,461 patched files from the initial
    patch version early this week with:

    - a full scancode scan run, collecting the matched texts, detected
    license ids and scores

    - reviewing anything where there was a license detected (about 500+
    files) to ensure that the applied SPDX license was correct

    - reviewing anything where there was no detection but the patch
    license was not GPL-2.0 WITH Linux-syscall-note to ensure that the
    applied SPDX license was correct

    This produced a worksheet with 20 files needing minor correction. This
    worksheet was then exported into 3 different .csv files for the
    different types of files to be modified.

    These .csv files were then reviewed by Greg. Thomas wrote a script to
    parse the csv files and add the proper SPDX tag to the file, in the
    format that the file expected. This script was further refined by Greg
    based on the output to detect more types of files automatically and to
    distinguish between header and source .c files (which need different
    comment types.) Finally Greg ran the script using the .csv files to
    generate the patches.

    Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
    Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"

    * tag 'spdx_identifiers-4.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
    License cleanup: add SPDX license identifier to uapi header files with a license
    License cleanup: add SPDX license identifier to uapi header files with no license
    License cleanup: add SPDX GPL-2.0 license identifier to files with no license

    Linus Torvalds
     

02 Nov, 2017

10 commits

  • MIPS is no longer part of Imagination Technologies and my @imgtec.com
    address will soon stop working. Update any files containing my address
    as well as the .mailmap to point to my new @mips.com address.

    Signed-off-by: Marcin Nowakowski
    Patchwork: https://patchwork.linux-mips.org/patch/17579/
    Signed-off-by: James Hogan

    Marcin Nowakowski
     
  • Many user space API headers have licensing information, which is either
    incomplete, badly formatted or just a shorthand for referring to the
    license under which the file is supposed to be. This makes it hard for
    compliance tools to determine the correct license.

    Update these files with an SPDX license identifier. The identifier was
    chosen based on the license information in the file.

    GPL/LGPL licensed headers get the matching GPL/LGPL SPDX license
    identifier with the added 'WITH Linux-syscall-note' exception, which is
    the officially assigned exception identifier for the kernel syscall
    exception:

    NOTE! This copyright does *not* cover user programs that use kernel
    services by normal system calls - this is merely considered normal use
    of the kernel, and does *not* fall under the heading of "derived work".

    This exception makes it possible to include GPL headers into non GPL
    code, without confusing license compliance tools.

    Headers which have either explicit dual licensing or are just licensed
    under a non GPL license are updated with the corresponding SPDX
    identifier and the GPLv2 with syscall exception identifier. The format
    is:
    ((GPL-2.0 WITH Linux-syscall-note) OR SPDX-ID-OF-OTHER-LICENSE)

    SPDX license identifiers are a legally binding shorthand, which can be
    used instead of the full boiler plate text. The update does not remove
    existing license information as this has to be done on a case by case
    basis and the copyright holders might have to be consulted. This will
    happen in a separate step.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne. See the previous patch in this series for the
    methodology of how this patch was researched.

    Reviewed-by: Kate Stewart
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • Many user space API headers are missing licensing information, which
    makes it hard for compliance tools to determine the correct license.

    By default are files without license information under the default
    license of the kernel, which is GPLV2. Marking them GPLV2 would exclude
    them from being included in non GPLV2 code, which is obviously not
    intended. The user space API headers fall under the syscall exception
    which is in the kernels COPYING file:

    NOTE! This copyright does *not* cover user programs that use kernel
    services by normal system calls - this is merely considered normal use
    of the kernel, and does *not* fall under the heading of "derived work".

    otherwise syscall usage would not be possible.

    Update the files which contain no license information with an SPDX
    license identifier. The chosen identifier is 'GPL-2.0 WITH
    Linux-syscall-note' which is the officially assigned identifier for the
    Linux syscall exception. SPDX license identifiers are a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne. See the previous patch in this series for the
    methodology of how this patch was researched.

    Reviewed-by: Kate Stewart
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • Add an additional symbol to the decompressor image, which will allow
    future debugging of non-bootable problems similar to the one encountered
    with the EFI stub.

    Signed-off-by: Russell King

    Russell King
     
  • The smp-cmp build has been (further) broken since commit 856fbcee6099
    ("MIPS: Store core & VP IDs in GlobalNumber-style variable") in
    v4.14-rc1 like so:

    arch/mips/kernel/smp-cmp.c: In function ‘cmp_init_secondary’:
    arch/mips/kernel/smp-cmp.c:53:4: error: ‘struct cpuinfo_mips’ has no member named ‘vpe_id’
    c->vpe_id = (read_c0_tcbind() >> TCBIND_CURVPE_SHIFT) &
    ^

    Fix by replacing vpe_id with cpu_set_vpe_id().

    Fixes: 856fbcee6099 ("MIPS: Store core & VP IDs in GlobalNumber-style variable")
    Signed-off-by: James Hogan
    Reviewed-by: Paul Burton
    Cc: Ralf Baechle
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/17569/
    Signed-off-by: James Hogan

    James Hogan
     
  • When task_struct was moved, this MIPS code was neglected. Evidently
    nobody is using it anymore. This fixes this build error:

    In file included from ./arch/mips/include/asm/thread_info.h:15:0,
    from ./include/linux/thread_info.h:37,
    from ./include/asm-generic/current.h:4,
    from ./arch/mips/include/generated/asm/current.h:1,
    from ./include/linux/sched.h:11,
    from arch/mips/kernel/smp-cmp.c:22:
    arch/mips/kernel/smp-cmp.c: In function ‘cmp_boot_secondary’:
    ./arch/mips/include/asm/processor.h:384:41: error: implicit declaration
    of function ‘task_stack_page’ [-Werror=implicit-function-declaration]
    #define __KSTK_TOS(tsk) ((unsigned long)task_stack_page(tsk) + \
    ^
    arch/mips/kernel/smp-cmp.c:84:21: note: in expansion of macro ‘__KSTK_TOS’
    unsigned long sp = __KSTK_TOS(idle);
    ^~~~~~~~~~

    Fixes: f3ac60671954 ("sched/headers: Move task-stack related APIs from to ")
    Signed-off-by: Jason A. Donenfeld
    Cc: # 4.11+
    Patchwork: https://patchwork.linux-mips.org/patch/17522/
    Signed-off-by: James Hogan

    Jason A. Donenfeld
     
  • Commit 1ec9dd80bedc ("MIPS: CPS: Detect CPUs in secondary clusters")
    added a check in cps_boot_secondary() that the secondary being booted is
    in the same cluster as the CPU running this code. This check is
    performed using current_cpu_data without disabling preemption. As such
    when CONFIG_PREEMPT=y, a BUG is triggered:

    [ 57.991693] BUG: using smp_processor_id() in preemptible [00000000] code: hotplug/1749

    [ 58.063077] Call Trace:
    [ 58.065842] [] show_stack+0x84/0x114
    [ 58.070830] [] dump_stack+0xf8/0x140
    [ 58.075796] [] check_preemption_disabled+0xec/0x118
    [ 58.082204] [] cps_boot_secondary+0x84/0x44c
    [ 58.087935] [] __cpu_up+0x34/0x98
    [ 58.092624] [] bringup_cpu+0x38/0x114
    [ 58.097680] [] cpuhp_invoke_callback+0x168/0x8f0
    [ 58.103801] [] _cpu_up+0x154/0x1c8
    [ 58.108565] [] do_cpu_up+0x98/0xa8
    [ 58.113333] [] device_online+0x84/0xc0
    [ 58.118481] [] online_store+0x60/0x98
    [ 58.123562] [] kernfs_fop_write+0x158/0x1d4
    [ 58.129196] [] __vfs_write+0x4c/0x168
    [ 58.134247] [] vfs_write+0xe0/0x190
    [ 58.139095] [] SyS_write+0x68/0xc4
    [ 58.143854] [] syscall_common+0x34/0x58

    In reality we don't currently support running the kernel on CPUs not in
    cluster 0, so the answer to cpu_cluster(¤t_cpu_data) will always
    be 0, even if this task being preempted and continues running on a
    different CPU. Regardless, the BUG should not be triggered, so fix this
    by switching to raw_current_cpu_data. When multicluster support lands
    upstream this check will need removing or changing anyway.

    Fixes: 1ec9dd80bedc ("MIPS: CPS: Detect CPUs in secondary clusters")
    Signed-off-by: Matt Redfearn
    Reviewed-by: Paul Burton
    CC: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/17563/
    Signed-off-by: James Hogan

    Matt Redfearn
     
  • Jeremy reported a suspicious RCU usage warning in mcelog.

    /dev/mcelog is called in process context now as part of the notifier
    chain and doesn't need any of the fancy RCU and lockless accesses which
    it did in atomic context.

    Axe it all in favor of a simple mutex synchronization which cures the
    problem reported.

    Fixes: 5de97c9f6d85 ("x86/mce: Factor out and deprecate the /dev/mcelog driver")
    Reported-by: Jeremy Cline
    Signed-off-by: Borislav Petkov
    Signed-off-by: Thomas Gleixner
    Reviewed-and-tested-by: Tony Luck
    Cc: Andi Kleen
    Cc: linux-edac@vger.kernel.org
    Cc: Laura Abbott
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20171101164754.xzzmskl4ngrqc5br@pd.tnic
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1498969

    Borislav Petkov
     
  • ARM depends on the macros '__ARMEL__' & '__ARMEB__' being defined
    or not to correctly select or define endian-specific macros,
    structures or pieces of code.

    These macros are predefined by the compiler but sparse knows
    nothing about them and thus may pre-process files differently
    from what gcc would.

    Fix this by passing '-D__ARMEL__' or '-D__ARMEB__' to sparse,
    depending on the endianness of the kernel, like defined by GCC.

    Note: In most case it won't change anything since most ARMs use
    little-endian (but an allyesconfig would use big-endian!).

    To: Russell King

    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Luc Van Oostenryck
    Signed-off-by: Russell King

    Luc Van Oostenryck
     

01 Nov, 2017

4 commits

  • Syzkaller with KASAN has reported a use-after-free of vma->vm_flags in
    __do_page_fault() with the following reproducer:

    mmap(&(0x7f0000000000/0xfff000)=nil, 0xfff000, 0x3, 0x32, 0xffffffffffffffff, 0x0)
    mmap(&(0x7f0000011000/0x3000)=nil, 0x3000, 0x1, 0x32, 0xffffffffffffffff, 0x0)
    r0 = userfaultfd(0x0)
    ioctl$UFFDIO_API(r0, 0xc018aa3f, &(0x7f0000002000-0x18)={0xaa, 0x0, 0x0})
    ioctl$UFFDIO_REGISTER(r0, 0xc020aa00, &(0x7f0000019000)={{&(0x7f0000012000/0x2000)=nil, 0x2000}, 0x1, 0x0})
    r1 = gettid()
    syz_open_dev$evdev(&(0x7f0000013000-0x12)="2f6465762f696e7075742f6576656e742300", 0x0, 0x0)
    tkill(r1, 0x7)

    The vma should be pinned by mmap_sem, but handle_userfault() might (in a
    return to userspace scenario) release it and then acquire again, so when
    we return to __do_page_fault() (with other result than VM_FAULT_RETRY),
    the vma might be gone.

    Specifically, per Andrea the scenario is
    "A return to userland to repeat the page fault later with a
    VM_FAULT_NOPAGE retval (potentially after handling any pending signal
    during the return to userland). The return to userland is identified
    whenever FAULT_FLAG_USER|FAULT_FLAG_KILLABLE are both set in
    vmf->flags"

    However, since commit a3c4fb7c9c2e ("x86/mm: Fix fault error path using
    unsafe vma pointer") there is a vma_pkey() read of vma->vm_flags after
    that point, which can thus become use-after-free. Fix this by moving
    the read before calling handle_mm_fault().

    Reported-by: syzbot
    Reported-by: Dmitry Vyukov
    Suggested-by: Kirill A. Shutemov
    Fixes: 3c4fb7c9c2e ("x86/mm: Fix fault error path using unsafe vma pointer")
    Reviewed-by: Andrea Arcangeli
    Signed-off-by: Vlastimil Babka
    Signed-off-by: Linus Torvalds

    Vlastimil Babka
     
  • This makes the changes introduced in commit 83e840c770f2c5
    ("powerpc64/elfv1: Only dereference function descriptor for non-text
    symbols") to be specific to the kprobe subsystem.

    We previously changed ppc_function_entry() to always check the provided
    address to confirm if it needed to be dereferenced. This is actually
    only an issue for kprobe blacklisted asm labels (through use of
    _ASM_NOKPROBE_SYMBOL) and can cause other issues with ftrace. Also, the
    additional checks are not really necessary for our other uses.

    As such, move this check to the kprobes subsystem.

    Fixes: 83e840c770f2 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols")
    Cc: stable@vger.kernel.org # v4.13+
    Signed-off-by: Naveen N. Rao
    Signed-off-by: Michael Ellerman

    Naveen N. Rao
     
  • This reverts commit 83e840c770f2c5 ("powerpc64/elfv1: Only dereference
    function descriptor for non-text symbols").

    Chandan reported that on newer kernels, trying to enable function_graph
    tracer on ppc64 (BE) locks up the system with the following trace:

    Unable to handle kernel paging request for data at address 0x600000002fa30010
    Faulting instruction address: 0xc0000000001f1300
    Thread overran stack, or stack corrupted
    Oops: Kernel access of bad area, sig: 11 [#1]
    BE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries
    Modules linked in:
    CPU: 1 PID: 6586 Comm: bash Not tainted 4.14.0-rc3-00162-g6e51f1f-dirty #20
    task: c000000625c07200 task.stack: c000000625c07310
    NIP: c0000000001f1300 LR: c000000000121cac CTR: c000000000061af8
    REGS: c000000625c088c0 TRAP: 0380 Not tainted (4.14.0-rc3-00162-g6e51f1f-dirty)
    MSR: 8000000000001032 CR: 28002848 XER: 00000000
    CFAR: c0000000001f1320 SOFTE: 0
    ...
    NIP [c0000000001f1300] .__is_insn_slot_addr+0x30/0x90
    LR [c000000000121cac] .kernel_text_address+0x18c/0x1c0
    Call Trace:
    [c000000625c08b40] [c0000000001bd040] .is_module_text_address+0x20/0x40 (unreliable)
    [c000000625c08bc0] [c000000000121cac] .kernel_text_address+0x18c/0x1c0
    [c000000625c08c50] [c000000000061960] .prepare_ftrace_return+0x50/0x130
    [c000000625c08cf0] [c000000000061b10] .ftrace_graph_caller+0x14/0x34
    [c000000625c08d60] [c000000000121b40] .kernel_text_address+0x20/0x1c0
    [c000000625c08df0] [c000000000061960] .prepare_ftrace_return+0x50/0x130
    ...
    [c000000625c0ab30] [c000000000061960] .prepare_ftrace_return+0x50/0x130
    [c000000625c0abd0] [c000000000061b10] .ftrace_graph_caller+0x14/0x34
    [c000000625c0ac40] [c000000000121b40] .kernel_text_address+0x20/0x1c0
    [c000000625c0acd0] [c000000000061960] .prepare_ftrace_return+0x50/0x130
    [c000000625c0ad70] [c000000000061b10] .ftrace_graph_caller+0x14/0x34
    [c000000625c0ade0] [c000000000121b40] .kernel_text_address+0x20/0x1c0

    This is because ftrace is using ppc_function_entry() for obtaining the
    address of return_to_handler() in prepare_ftrace_return(). The call to
    kernel_text_address() itself gets traced and we end up in a recursive
    loop.

    Fixes: 83e840c770f2 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols")
    Cc: stable@vger.kernel.org # v4.13+
    Reported-by: Chandan Rajendra
    Signed-off-by: Naveen N. Rao
    Signed-off-by: Michael Ellerman

    Naveen N. Rao
     
  • Commit 6f542ebeaee0 ("MIPS: Fix race on setting and getting
    cpu_online_mask") effectively reverted commit 8f46cca1e6c06 ("MIPS: SMP:
    Fix possibility of deadlock when bringing CPUs online") and thus has
    reinstated the possibility of deadlock.

    The commit was based on testing of kernel v4.4, where the CPU hotplug
    core code issued a BUG() if the starting CPU is not marked online when
    the boot CPU returns from __cpu_up. The commit fixes this race (in
    v4.4), but re-introduces the deadlock situation.

    As noted in the commit message, upstream differs in this area. Commit
    8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up")
    adds a completion event in the CPU hotplug core code, making this race
    impossible. However, people were unhappy with relying on the core code
    to do the right thing.

    To address the issues both commits were trying to fix, add a second
    completion event in the MIPS smp hotplug path. It removes the
    possibility of a race, since the MIPS smp hotplug code now synchronises
    both the boot and secondary CPUs before they return to the hotplug core
    code. It also addresses the deadlock by ensuring that the secondary CPU
    is not marked online before it's counters are synchronised.

    This fix should also be backported to fix the race condition introduced
    by the backport of commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of
    deadlock when bringing CPUs online"), through really that race only
    existed before commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu
    bring itself fully up").

    Signed-off-by: Matt Redfearn
    Fixes: 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask")
    CC: Matija Glavinic Pecotic
    Cc: # v4.1+: 8f46cca1e6c0: "MIPS: SMP: Fix possibility of deadlock when bringing CPUs online"
    Cc: # v4.1+: a00eeede507c: "MIPS: SMP: Use a completion event to signal CPU up"
    Cc: # v4.1+: 6f542ebeaee0: "MIPS: Fix race on setting and getting cpu_online_mask"
    Cc: # v4.1+
    Patchwork: https://patchwork.linux-mips.org/patch/17376/
    Signed-off-by: James Hogan

    Matt Redfearn