1. 25 Jan, 2020 1 commit
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input · d5d359b0
      Linus Torvalds authored
      Pull input fixes from Dmitry Torokhov:
      
       - add sanity checks to USB endpoints in various dirvers
      
       - max77650-onkey was missing an OF table which was preventing module
         autoloading
      
       - a revert and a different fix for F54 handling in Synaptics dirver
      
       - a fixup for handling register in pm8xxx vibrator driver
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
        Input: pm8xxx-vib - fix handling of separate enable register
        Input: keyspan-remote - fix control-message timeouts
        Input: max77650-onkey - add of_match table
        Input: rmi_f54 - read from FIFO in 32 byte blocks
        Revert "Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers"
        Input: sur40 - fix interface sanity checks
        Input: gtco - drop redundant variable reinit
        Input: gtco - fix extra-descriptor debug message
        Input: gtco - fix endpoint sanity check
        Input: aiptek - use descriptors of current altsetting
        Input: aiptek - fix endpoint sanity check
        Input: pegasus_notetaker - fix endpoint sanity check
        Input: sun4i-ts - add a check for devm_thermal_zone_of_sensor_register
        Input: evdev - convert kzalloc()/vzalloc() to kvzalloc()
      d5d359b0
  2. 24 Jan, 2020 7 commits
  3. 23 Jan, 2020 11 commits
    • Dave Airlie's avatar
      Merge tag 'amd-drm-fixes-5.5-2020-01-23' of... · 49412f66
      Dave Airlie authored
      Merge tag 'amd-drm-fixes-5.5-2020-01-23' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
      
      amd-drm-fixes-5.5-2020-01-23:
      
      amdgpu:
      - remove the experimental flag from renoir
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      From: Alex Deucher <alexdeucher@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200123191424.3849-1-alexander.deucher@amd.com
      49412f66
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2020-01-23' of... · b5293714
      Dave Airlie authored
      Merge tag 'drm-intel-fixes-2020-01-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
      
      - Avoid overflow with huge userptr objects
      - uAPI fix to correctly handle negative values in
        engine->uabi_class/instance (cc: stable)
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200123135045.GA12584@jlahtine-desk.ger.corp.intel.com
      b5293714
    • Linus Torvalds's avatar
      Merge tag 'xarray-5.5' of git://git.infradead.org/users/willy/linux-dax · 4703d911
      Linus Torvalds authored
      Pull XArray fixes from Matthew Wilcox:
       "Primarily bugfixes, mostly around handling index wrap-around
        correctly.
      
        A couple of doc fixes and adding missing APIs.
      
        I had an oops live on stage at linux.conf.au this year, and it turned
        out to be a bug in xas_find() which I can't prove isn't triggerable in
        the current codebase. Then in looking for the bug, I spotted two more
        bugs.
      
        The bots have had a few days to chew on this with no problems
        reported, and it passes the test-suite (which now has more tests to
        make sure these problems don't come back)"
      
      * tag 'xarray-5.5' of git://git.infradead.org/users/willy/linux-dax:
        XArray: Add xa_for_each_range
        XArray: Fix xas_find returning too many entries
        XArray: Fix xa_find_after with multi-index entries
        XArray: Fix infinite loop with entry at ULONG_MAX
        XArray: Add wrappers for nested spinlocks
        XArray: Improve documentation of search marks
        XArray: Fix xas_pause at ULONG_MAX
      4703d911
    • Linus Torvalds's avatar
      Merge tag 'trace-v5.5-rc6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · 34597c85
      Linus Torvalds authored
      Pull tracing fixes from Steven Rostedt:
       "Various tracing fixes:
      
         - Fix a function comparison warning for a xen trace event macro
      
         - Fix a double perf_event linking to a trace_uprobe_filter for
           multiple events
      
         - Fix suspicious RCU warnings in trace event code for using
           list_for_each_entry_rcu() when the "_rcu" portion wasn't needed.
      
         - Fix a bug in the histogram code when using the same variable
      
         - Fix a NULL pointer dereference when tracefs lockdown enabled and
           calling trace_set_default_clock()
      
         - A fix to a bug found with the double perf_event linking patch"
      
      * tag 'trace-v5.5-rc6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing/uprobe: Fix to make trace_uprobe_filter alignment safe
        tracing: Do not set trace clock if tracefs lockdown is in effect
        tracing: Fix histogram code when expression has same var as value
        tracing: trigger: Replace unneeded RCU-list traversals
        tracing/uprobe: Fix double perf_event linking on multiprobe uprobe
        tracing: xen: Ordered comparison of function pointers
      34597c85
    • Linus Torvalds's avatar
      Merge tag 'ceph-for-5.5-rc8' of https://github.com/ceph/ceph-client · fa0a4e3b
      Linus Torvalds authored
      Pull ceph fix from Ilya Dryomov:
       "A fix for a potential use-after-free from Jeff, marked for stable"
      
      * tag 'ceph-for-5.5-rc8' of https://github.com/ceph/ceph-client:
        ceph: hold extra reference to r_parent over life of request
      fa0a4e3b
    • Linus Torvalds's avatar
      Merge tag 'pm-5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 3a83c8c8
      Linus Torvalds authored
      Pull power management fix from Rafael Wysocki:
       "Prevent the kernel from crashing during resume from hibernation if
        free pages contain leftover data from the restore kernel and
        init_on_free is set (Alexander Potapenko)"
      
      * tag 'pm-5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        PM: hibernate: fix crashes with init_on_free=1
      3a83c8c8
    • Linus Torvalds's avatar
      Merge tag 'pci-v5.5-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci · a572582b
      Linus Torvalds authored
      Pull PCI fix from Bjorn Helgaas:
       "Mark ATS as broken on AMD Navi14 GPU rev 0xc5 (Alex Deucher)"
      
      * tag 'pci-v5.5-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
        PCI: Mark AMD Navi14 GPU rev 0xc5 ATS as broken
      a572582b
    • Linus Torvalds's avatar
      readdir: make user_access_begin() use the real access range · 3c2659bd
      Linus Torvalds authored
      In commit 9f79b78e ("Convert filldir[64]() from __put_user() to
      unsafe_put_user()") I changed filldir to not do individual __put_user()
      accesses, but instead use unsafe_put_user() surrounded by the proper
      user_access_begin/end() pair.
      
      That make them enormously faster on modern x86, where the STAC/CLAC
      games make individual user accesses fairly heavy-weight.
      
      However, the user_access_begin() range was not really the exact right
      one, since filldir() has the unfortunate problem that it needs to not
      only fill out the new directory entry, it also needs to fix up the
      previous one to contain the proper file offset.
      
      It's unfortunate, but the "d_off" field in "struct dirent" is _not_ the
      file offset of the directory entry itself - it's the offset of the next
      one.  So we end up backfilling the offset in the previous entry as we
      walk along.
      
      But since x86 didn't really care about the exact range, and used to be
      the only architecture that did anything fancy in user_access_begin() to
      begin with, the filldir[64]() changes did something lazy, and even
      commented on it:
      
      	/*
      	 * Note! This range-checks 'previous' (which may be NULL).
      	 * The real range was checked in getdents
      	 */
      	if (!user_access_begin(dirent, sizeof(*dirent)))
      		goto efault;
      
      and it all worked fine.
      
      But now 32-bit ppc is starting to also implement user_access_begin(),
      and the fact that we faked the range to only be the (possibly not even
      valid) previous directory entry becomes a problem, because ppc32 will
      actually be using the range that is passed in for more than just "check
      that it's user space".
      
      This is a complete rewrite of Christophe's original patch.
      
      By saving off the record length of the previous entry instead of a
      pointer to it in the filldir data structures, we can simplify the range
      check and the writing of the previous entry d_off field.  No need for
      any conditionals in the user accesses themselves, although we retain the
      conditional EINTR checking for the "was this the first directory entry"
      signal handling latency logic.
      
      Fixes: 9f79b78e ("Convert filldir[64]() from __put_user() to unsafe_put_user()")
      Link: https://lore.kernel.org/lkml/a02d3426f93f7eb04960a4d9140902d278cab0bb.1579697910.git.christophe.leroy@c-s.fr/
      Link: https://lore.kernel.org/lkml/408c90c4068b00ea8f1c41cca45b84ec23d4946b.1579783936.git.christophe.leroy@c-s.fr/Reported-and-tested-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3c2659bd
    • Linus Torvalds's avatar
      readdir: be more conservative with directory entry names · 2c6b7bcd
      Linus Torvalds authored
      Commit 8a23eb80 ("Make filldir[64]() verify the directory entry
      filename is valid") added some minimal validity checks on the directory
      entries passed to filldir[64]().  But they really were pretty minimal.
      
      This fleshes out at least the name length check: we used to disallow
      zero-length names, but really, negative lengths or oevr-long names
      aren't ok either.  Both could happen if there is some filesystem
      corruption going on.
      
      Now, most filesystems tend to use just an "unsigned char" or similar for
      the length of a directory entry name, so even with a corrupt filesystem
      you should never see anything odd like that.  But since we then use the
      name length to create the directory entry record length, let's make sure
      it actually is half-way sensible.
      
      Note how POSIX states that the size of a path component is limited by
      NAME_MAX, but we actually use PATH_MAX for the check here.  That's
      because while NAME_MAX is generally the correct maximum name length
      (it's 255, for the same old "name length is usually just a byte on
      disk"), there's nothing in the VFS layer that really cares.
      
      So the real limitation at a VFS layer is the total pathname length you
      can pass as a filename: PATH_MAX.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2c6b7bcd
    • Alex Deucher's avatar
      drm/amdgpu: remove the experimental flag for renoir · 23fe1390
      Alex Deucher authored
      Should work properly with the latest sbios on 5.5 and newer
      kernels.
      Reviewed-by: default avatarHawking Zhang <Hawking.Zhang@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      23fe1390
    • Aneesh Kumar K.V's avatar
      powerpc/mm/hash: Fix sharing context ids between kernel & userspace · 5d2e5dd5
      Aneesh Kumar K.V authored
      Commit 0034d395 ("powerpc/mm/hash64: Map all the kernel regions in
      the same 0xc range") has a bug in the definition of MIN_USER_CONTEXT.
      
      The result is that the context id used for the vmemmap and the lowest
      context id handed out to userspace are the same. The context id is
      essentially the process identifier as far as the first stage of the
      MMU translation is concerned.
      
      This can result in multiple SLB entries with the same VSID (Virtual
      Segment ID), accessible to the kernel and some random userspace
      process that happens to get the overlapping id, which is not expected
      eg:
      
        07 c00c000008000000 40066bdea7000500  1T  ESID=   c00c00  VSID=      66bdea7 LLP:100
        12 0002000008000000 40066bdea7000d80  1T  ESID=      200  VSID=      66bdea7 LLP:100
      
      Even though the user process and the kernel use the same VSID, the
      permissions in the hash page table prevent the user process from
      reading or writing to any kernel mappings.
      
      It can also lead to SLB entries with different base page size
      encodings (LLP), eg:
      
        05 c00c000008000000 00006bde0053b500 256M ESID=c00c00000  VSID=    6bde0053b LLP:100
        09 0000000008000000 00006bde0053bc80 256M ESID=        0  VSID=    6bde0053b LLP:  0
      
      Such SLB entries can result in machine checks, eg. as seen on a G5:
      
        Oops: Machine check, sig: 7 [#1]
        BE PAGE SIZE=64K MU-Hash SMP NR_CPUS=4 NUMA Power Mac
        NIP: c00000000026f248 LR: c000000000295e58 CTR: 0000000000000000
        REGS: c0000000erfd3d70 TRAP: 0200 Tainted: G M (5.5.0-rcl-gcc-8.2.0-00010-g228b667d8ea1)
        MSR: 9000000000109032 <SF,HV,EE,ME,IR,DR,RI> CR: 24282048 XER: 00000000
        DAR: c00c000000612c80 DSISR: 00000400 IRQMASK: 0
        ...
        NIP [c00000000026f248] .kmem_cache_free+0x58/0x140
        LR  [c088000008295e58] .putname 8x88/0xa
        Call Trace:
          .putname+0xB8/0xa
          .filename_lookup.part.76+0xbe/0x160
          .do_faccessat+0xe0/0x380
          system_call+0x5c/ex68
      
      This happens with 256MB segments and 64K pages, as the duplicate VSID
      is hit with the first vmemmap segment and the first user segment, and
      older 32-bit userspace maps things in the first user segment.
      
      On other CPUs a machine check is not seen. Instead the userspace
      process can get stuck continuously faulting, with the fault never
      properly serviced, due to the kernel not understanding that there is
      already a HPTE for the address but with inaccessible permissions.
      
      On machines with 1T segments we've not seen the bug hit other than by
      deliberately exercising it. That seems to be just a matter of luck
      though, due to the typical layout of the user virtual address space
      and the ranges of vmemmap that are typically populated.
      
      To fix it we add 2 to MIN_USER_CONTEXT. This ensures the lowest
      context given to userspace doesn't overlap with the VMEMMAP context,
      or with the context for INVALID_REGION_ID.
      
      Fixes: 0034d395 ("powerpc/mm/hash64: Map all the kernel regions in the same 0xc range")
      Cc: stable@vger.kernel.org # v5.2+
      Reported-by: default avatarChristian Marillat <marillat@debian.org>
      Reported-by: default avatarRomain Dolbeau <romain@dolbeau.org>
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      [mpe: Account for INVALID_REGION_ID, mostly rewrite change log]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20200123102547.11623-1-mpe@ellerman.id.au
      5d2e5dd5
  4. 22 Jan, 2020 13 commits
  5. 21 Jan, 2020 6 commits
  6. 20 Jan, 2020 2 commits
    • Masami Ichikawa's avatar
      tracing: Do not set trace clock if tracefs lockdown is in effect · bf24daac
      Masami Ichikawa authored
      When trace_clock option is not set and unstable clcok detected,
      tracing_set_default_clock() sets trace_clock(ThinkPad A285 is one of
      case). In that case, if lockdown is in effect, null pointer
      dereference error happens in ring_buffer_set_clock().
      
      Link: http://lkml.kernel.org/r/20200116131236.3866925-1-masami256@gmail.com
      
      Cc: stable@vger.kernel.org
      Fixes: 17911ff3 ("tracing: Add locked_down checks to the open calls of files created for tracefs")
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1788488Signed-off-by: default avatarMasami Ichikawa <masami256@gmail.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      bf24daac
    • Steven Rostedt (VMware)'s avatar
      tracing: Fix histogram code when expression has same var as value · 8bcebc77
      Steven Rostedt (VMware) authored
      While working on a tool to convert SQL syntex into the histogram language of
      the kernel, I discovered the following bug:
      
       # echo 'first u64 start_time u64 end_time pid_t pid u64 delta' >> synthetic_events
       # echo 'hist:keys=pid:start=common_timestamp' > events/sched/sched_waking/trigger
       # echo 'hist:keys=next_pid:delta=common_timestamp-$start,start2=$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' > events/sched/sched_switch/trigger
      
      Would not display any histograms in the sched_switch histogram side.
      
      But if I were to swap the location of
      
        "delta=common_timestamp-$start" with "start2=$start"
      
      Such that the last line had:
      
       # echo 'hist:keys=next_pid:start2=$start,delta=common_timestamp-$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' > events/sched/sched_switch/trigger
      
      The histogram works as expected.
      
      What I found out is that the expressions clear out the value once it is
      resolved. As the variables are resolved in the order listed, when
      processing:
      
        delta=common_timestamp-$start
      
      The $start is cleared. When it gets to "start2=$start", it errors out with
      "unresolved symbol" (which is silent as this happens at the location of the
      trace), and the histogram is dropped.
      
      When processing the histogram for variable references, instead of adding a
      new reference for a variable used twice, use the same reference. That way,
      not only is it more efficient, but the order will no longer matter in
      processing of the variables.
      
      From Tom Zanussi:
      
       "Just to clarify some more about what the problem was is that without
        your patch, we would have two separate references to the same variable,
        and during resolve_var_refs(), they'd both want to be resolved
        separately, so in this case, since the first reference to start wasn't
        part of an expression, it wouldn't get the read-once flag set, so would
        be read normally, and then the second reference would do the read-once
        read and also be read but using read-once.  So everything worked and
        you didn't see a problem:
      
         from: start2=$start,delta=common_timestamp-$start
      
        In the second case, when you switched them around, the first reference
        would be resolved by doing the read-once, and following that the second
        reference would try to resolve and see that the variable had already
        been read, so failed as unset, which caused it to short-circuit out and
        not do the trigger action to generate the synthetic event:
      
         to: delta=common_timestamp-$start,start2=$start
      
        With your patch, we only have the single resolution which happens
        correctly the one time it's resolved, so this can't happen."
      
      Link: https://lore.kernel.org/r/20200116154216.58ca08eb@gandalf.local.home
      
      Cc: stable@vger.kernel.org
      Fixes: 067fe038 ("tracing: Add variable reference handling to hist triggers")
      Reviewed-by: default avatarTom Zanuss <zanussi@kernel.org>
      Tested-by: default avatarTom Zanussi <zanussi@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      8bcebc77