1. 25 Jan, 2020 4 commits
    • Linus Torvalds's avatar
      Merge tag 'for-5.5-rc8-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux · a075f23d
      Linus Torvalds authored
      Pull btrfs fix from David Sterba:
       "Here's a last minute fix for a regression introduced in this
        development cycle.
      
        There's a small chance of a silent corruption when device replace and
        NOCOW data writes happen at the same time in one block group. Metadata
        or COW data writes are unaffected.
      
        The extra fixup patch is there to silence an unnecessary warning"
      
      * tag 'for-5.5-rc8-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
        btrfs: dev-replace: remove warning for unknown return codes when finished
        btrfs: scrub: Require mandatory block group RO for dev-replace
      a075f23d
    • Linus Torvalds's avatar
      Merge tag 'pinctrl-v5.5-5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl · 93d1a05e
      Linus Torvalds authored
      Pull pin control fix from Linus Walleij:
       "A single fix for the Intel Sunrisepoint pin controller that makes the
        interrupts work properly on it"
      
      * tag 'pinctrl-v5.5-5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
        pinctrl: sunrisepoint: Add missing Interrupt Status register offset
      93d1a05e
    • David Sterba's avatar
      btrfs: dev-replace: remove warning for unknown return codes when finished · 4cea9037
      David Sterba authored
      The fstests btrfs/011 triggered a warning at the end of device replace,
      
        [ 1891.998975] BTRFS warning (device vdd): failed setting block group ro: -28
        [ 1892.038338] BTRFS error (device vdd): btrfs_scrub_dev(/dev/vdd, 1, /dev/vdb) failed -28
        [ 1892.059993] ------------[ cut here ]------------
        [ 1892.063032] WARNING: CPU: 2 PID: 2244 at fs/btrfs/dev-replace.c:506 btrfs_dev_replace_start.cold+0xf9/0x140 [btrfs]
        [ 1892.074346] CPU: 2 PID: 2244 Comm: btrfs Not tainted 5.5.0-rc7-default+ #942
        [ 1892.079956] RIP: 0010:btrfs_dev_replace_start.cold+0xf9/0x140 [btrfs]
      
        [ 1892.096576] RSP: 0018:ffffbb58c7b3fd10 EFLAGS: 00010286
        [ 1892.098311] RAX: 00000000ffffffe4 RBX: 0000000000000001 RCX: 8888888888888889
        [ 1892.100342] RDX: 0000000000000001 RSI: ffff9e889645f5d8 RDI: ffffffff92821080
        [ 1892.102291] RBP: ffff9e889645c000 R08: 000001b8878fe1f6 R09: 0000000000000000
        [ 1892.104239] R10: ffffbb58c7b3fd08 R11: 0000000000000000 R12: ffff9e88a0017000
        [ 1892.106434] R13: ffff9e889645f608 R14: ffff9e88794e1000 R15: ffff9e88a07b5200
        [ 1892.108642] FS:  00007fcaed3f18c0(0000) GS:ffff9e88bda00000(0000) knlGS:0000000000000000
        [ 1892.111558] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        [ 1892.113492] CR2: 00007f52509ff420 CR3: 00000000603dd002 CR4: 0000000000160ee0
      
        [ 1892.115814] Call Trace:
        [ 1892.116896]  btrfs_dev_replace_by_ioctl+0x35/0x60 [btrfs]
        [ 1892.118962]  btrfs_ioctl+0x1d62/0x2550 [btrfs]
      
      caused by the previous patch ("btrfs: scrub: Require mandatory block
      group RO for dev-replace"). Hitting ENOSPC is possible and could happen
      when the block group is set read-only, preventing NOCOW writes to the
      area that's being accessed by dev-replace.
      
      This has happend with scratch devices of size 12G but not with 5G and
      20G, so this is depends on timing and other activity on the filesystem.
      The whole replace operation is restartable, the space state should be
      examined by the user in any case.
      
      The error code is propagated back to the ioctl caller so the kernel
      warning is causing false alerts.
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      4cea9037
    • 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 8 commits
    • Linus Torvalds's avatar
      Merge tag 'iommu-fixes-v5.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu · 6381b442
      Linus Torvalds authored
      Pull iommu fixes from Joerg Roedel:
       "Two fixes:
      
         - Fix NULL-ptr dereference bug in Intel IOMMU driver
      
         - Properly save and restore AMD IOMMU performance counter registers
           when testing if they are writable"
      
      * tag 'iommu-fixes-v5.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
        iommu/amd: Fix IOMMU perf counter clobbering during init
        iommu/vt-d: Call __dmar_remove_one_dev_info with valid pointer
      6381b442
    • Linus Torvalds's avatar
      Merge tag 'powerpc-5.5-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux · 3c45d751
      Linus Torvalds authored
      Pull powerpc fixes from Michael Ellerman:
       "Some more powerpc fixes for 5.5:
      
         - Fix our hash MMU code to avoid having overlapping ids between user
           and kernel, which isn't as bad as it sounds but led to crashes on
           some machines.
      
         - A fix for the Power9 XIVE interrupt code, which could return the
           wrong interrupt state in obscure error conditions.
      
         - A minor Kconfig fix for the recently added CONFIG_PPC_UV code.
      
        Thanks to Aneesh Kumar K.V, Bharata B Rao, Cédric Le Goater, Frederic
        Barrat"
      
      * tag 'powerpc-5.5-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
        powerpc/mm/hash: Fix sharing context ids between kernel & userspace
        powerpc/xive: Discard ESB load value when interrupt is invalid
        powerpc: Ultravisor: Fix the dependencies for CONFIG_PPC_UV
      3c45d751
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2020-01-24' of git://anongit.freedesktop.org/drm/drm · 274adbff
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "This one has a core mst fix and two i915 fixes. amdgpu just enables
        some hw outside experimental.
      
        The panfrost fix is a little bigger than I'd like at this stage but it
        fixes a fairly fundamental problem with global shared buffers in that
        driver, and since it's confined to that driver and I've taken a look
        at it, I think it's fine to get into the tree now, so it can get
        stable propagated as well.
      
        core/mst:
         - Fix SST branch device handling
      
        amdgpu:
         - enable renoir outside experimental
      
        i915:
         - Avoid overflow with huge userptr objects
         - uAPI fix to correctly handle negative values in
           engine->uabi_class/instance (cc: stable)
      
        panfrost:
         - Fix mapping of globally visible BO's (Boris)"
      
      * tag 'drm-fixes-2020-01-24' of git://anongit.freedesktop.org/drm/drm:
        drm/amdgpu: remove the experimental flag for renoir
        drm/panfrost: Add the panfrost_gem_mapping concept
        drm/i915: Align engine->uabi_class/instance with i915_drm.h
        drm/i915/userptr: fix size calculation
        drm/dp_mst: Handle SST-only branch device case
      274adbff
    • Christophe Leroy's avatar
      lib: Reduce user_access_begin() boundaries in strncpy_from_user() and strnlen_user() · ab10ae1c
      Christophe Leroy authored
      The range passed to user_access_begin() by strncpy_from_user() and
      strnlen_user() starts at 'src' and goes up to the limit of userspace
      although reads will be limited by the 'count' param.
      
      On 32 bits powerpc (book3s/32) access has to be granted for each
      256Mbytes segment and the cost increases with the number of segments to
      unlock.
      
      Limit the range with 'count' param.
      
      Fixes: 594cc251 ("make 'user_access_begin()' do 'access_ok()'")
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ab10ae1c
    • Shuah Khan's avatar
      iommu/amd: Fix IOMMU perf counter clobbering during init · 8c17bbf6
      Shuah Khan authored
      init_iommu_perf_ctr() clobbers the register when it checks write access
      to IOMMU perf counters and fails to restore when they are writable.
      
      Add save and restore to fix it.
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      Fixes: 30861ddc ("perf/x86/amd: Add IOMMU Performance Counter resource management")
      Reviewed-by: default avatarSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
      Tested-by: default avatarSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      8c17bbf6
    • Jerry Snitselaar's avatar
      iommu/vt-d: Call __dmar_remove_one_dev_info with valid pointer · bf708cfb
      Jerry Snitselaar authored
      It is possible for archdata.iommu to be set to
      DEFER_DEVICE_DOMAIN_INFO or DUMMY_DEVICE_DOMAIN_INFO so check for
      those values before calling __dmar_remove_one_dev_info. Without a
      check it can result in a null pointer dereference. This has been seen
      while booting a kdump kernel on an HP dl380 gen9.
      
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Lu Baolu <baolu.lu@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: stable@vger.kernel.org # 5.3+
      Cc: linux-kernel@vger.kernel.org
      Fixes: ae23bfb6 ("iommu/vt-d: Detach domain before using a private one")
      Signed-off-by: default avatarJerry Snitselaar <jsnitsel@redhat.com>
      Acked-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      bf708cfb
    • Qu Wenruo's avatar
      btrfs: scrub: Require mandatory block group RO for dev-replace · 1bbb97b8
      Qu Wenruo authored
      [BUG]
      For dev-replace test cases with fsstress, like btrfs/06[45] btrfs/071,
      looped runs can lead to random failure, where scrub finds csum error.
      
      The possibility is not high, around 1/20 to 1/100, but it's causing data
      corruption.
      
      The bug is observable after commit b12de528 ("btrfs: scrub: Don't
      check free space before marking a block group RO")
      
      [CAUSE]
      Dev-replace has two source of writes:
      
      - Write duplication
        All writes to source device will also be duplicated to target device.
      
        Content:	Not yet persisted data/meta
      
      - Scrub copy
        Dev-replace reused scrub code to iterate through existing extents, and
        copy the verified data to target device.
      
        Content:	Previously persisted data and metadata
      
      The difference in contents makes the following race possible:
      	Regular Writer		|	Dev-replace
      -----------------------------------------------------------------
        ^                             |
        | Preallocate one data extent |
        | at bytenr X, len 1M		|
        v				|
        ^ Commit transaction		|
        | Now extent [X, X+1M) is in  |
        v commit root			|
       ================== Dev replace starts =========================
        				| ^
      				| | Scrub extent [X, X+1M)
      				| | Read [X, X+1M)
      				| | (The content are mostly garbage
      				| |  since it's preallocated)
        ^				| v
        | Write back happens for	|
        | extent [X, X+512K)		|
        | New data writes to both	|
        | source and target dev.	|
        v				|
      				| ^
      				| | Scrub writes back extent [X, X+1M)
      				| | to target device.
      				| | This will over write the new data in
      				| | [X, X+512K)
      				| v
      
      This race can only happen for nocow writes. Thus metadata and data cow
      writes are safe, as COW will never overwrite extents of previous
      transaction (in commit root).
      
      This behavior can be confirmed by disabling all fallocate related calls
      in fsstress (*), then all related tests can pass a 2000 run loop.
      
      *: FSSTRESS_AVOID="-f fallocate=0 -f allocsp=0 -f zero=0 -f insert=0 \
      		   -f collapse=0 -f punch=0 -f resvsp=0"
         I didn't expect resvsp ioctl will fallback to fallocate in VFS...
      
      [FIX]
      Make dev-replace to require mandatory block group RO, and wait for current
      nocow writes before calling scrub_chunk().
      
      This patch will mostly revert commit 76a8efa1 ("btrfs: Continue replace
      when set_block_ro failed") for dev-replace path.
      
      The side effect is, dev-replace can be more strict on avaialble space, but
      definitely worth to avoid data corruption.
      Reported-by: default avatarFilipe Manana <fdmanana@suse.com>
      Fixes: 76a8efa1 ("btrfs: Continue replace when set_block_ro failed")
      Fixes: b12de528 ("btrfs: scrub: Don't check free space before marking a block group RO")
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      1bbb97b8
    • Linus Torvalds's avatar
      Merge tag 'mmc-v5.5-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc · 838a860a
      Linus Torvalds authored
      Pull MMC fixes from Ulf Hansson:
       "A couple of MMC host fixes:
      
         - sdhci: Fix minimum clock rate for v3 controllers
      
         - sdhci-tegra: Fix SDR50 tuning override
      
         - sdhci_am654: Fixup tuning issues and support for CQHCI
      
         - sdhci_am654: Remove wrong write protect flag"
      
      * tag 'mmc-v5.5-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
        mmc: sdhci: fix minimum clock rate for v3 controller
        mmc: tegra: fix SDR50 tuning override
        mmc: sdhci_am654: Fix Command Queuing in AM65x
        mmc: sdhci_am654: Reset Command and Data line after tuning
        mmc: sdhci_am654: Remove Inverted Write Protect flag
      838a860a
  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 4 commits