1. 07 Sep, 2017 1 commit
  2. 05 Sep, 2017 1 commit
  3. 04 Sep, 2017 1 commit
    • Meng Xu's avatar
      libnvdimm, nfit: move the check on nd_reserved2 to the endpoint · 9edcad53
      Meng Xu authored
      Delay the check of nd_reserved2 to the actual endpoint (acpi_nfit_ctl)
      that uses it, as a prevention of a potential double-fetch bug.
      
      While examining the kernel source code, I found a dangerous operation that
      could turn into a double-fetch situation (a race condition bug) where
      the same userspace memory region are fetched twice into kernel with sanity
      checks after the first fetch while missing checks after the second fetch.
      
      In the case of _IOC_NR(ioctl_cmd) == ND_CMD_CALL:
      
      1. The first fetch happens in line 935 copy_from_user(&pkg, p, sizeof(pkg)
      
      2. subsequently `pkg.nd_reserved2` is asserted to be all zeroes
      (line 984 to 986).
      
      3. The second fetch happens in line 1022 copy_from_user(buf, p, buf_len)
      
      4. Given that `p` can be fully controlled in userspace, an attacker can
      race condition to override the header part of `p`, say,
      `((struct nd_cmd_pkg *)p)->nd_reserved2` to arbitrary value
      (say nine 0xFFFFFFFF for `nd_reserved2`) after the first fetch but before the
      second fetch. The changed value will be copied to `buf`.
      
      5. There is no checks on the second fetches until the use of it in
      line 1034: nd_cmd_clear_to_send(nvdimm_bus, nvdimm, cmd, buf) and
      line 1038: nd_desc->ndctl(nd_desc, nvdimm, cmd, buf, buf_len, &cmd_rc)
      which means that the assumed relation, `p->nd_reserved2` are all zeroes might
      not hold after the second fetch. And once the control goes to these functions
      we lose the context to assert the assumed relation.
      
      6. Based on my manual analysis, `p->nd_reserved2` is not used in function
      `nd_cmd_clear_to_send` and potential implementations of `nd_desc->ndctl`
      so there is no working exploit against it right now. However, this could
      easily turns to an exploitable one if careless developers start to use
      `p->nd_reserved2` later and assume that they are all zeroes.
      
      Move the validation of the nd_reserved2 field to the ->ndctl()
      implementation where it has a stable buffer to evaluate.
      Signed-off-by: default avatarMeng Xu <mengxu.gatech@gmail.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      9edcad53
  4. 03 Sep, 2017 1 commit
    • Dan Williams's avatar
      dax: fix FS_DAX=n BLOCK=y compilation · 26f2f4de
      Dan Williams authored
      The 0day kbuild robot reports:
      
      >> drivers//dax/super.c:64:20: error: redefinition of 'fs_dax_get_by_bdev'
          struct dax_device *fs_dax_get_by_bdev(struct block_device *bdev)
                             ^~~~~~~~~~~~~~~~~~
         In file included from drivers//dax/super.c:22:0:
         include/linux/dax.h:76:34: note: previous definition of 'fs_dax_get_by_bdev' was here
          static inline struct dax_device *fs_dax_get_by_bdev(struct block_device *bdev)
                                           ^~~~~~~~~~~~~~~~~~
      
      Protect the definition of fs_dax_get_by_bdev() in drivers/dax/super.c
      with an ifdef.
      
      Fixes: 78f35473 ("dax: introduce a fs_dax_get_by_bdev() helper")
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Darrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      26f2f4de
  5. 31 Aug, 2017 13 commits
    • Dan Williams's avatar
      8f98ae0c
    • Dan Williams's avatar
      libnvdimm: fix integer overflow static analysis warning · 58738c49
      Dan Williams authored
      Dan reports:
          The patch 62232e45: "libnvdimm: control (ioctl) messages for
          nvdimm_bus and nvdimm devices" from Jun 8, 2015, leads to the
          following static checker warning:
      
                  drivers/nvdimm/bus.c:1018 __nd_ioctl()
                  warn: integer overflows 'buf_len'
      
          From a casual review, this seems like it might be a real bug.  On
          the first iteration we load some data into in_env[].  On the second
          iteration we read a use controlled "in_size" from nd_cmd_in_size().
          It can go up to UINT_MAX - 1.  A high number means we will fill the
          whole in_env[] buffer.  But we potentially keep looping and adding
          more to in_len so now it can be any value.
      
          It simple enough to change, but it feels weird that we keep looping
          even though in_env is totally full.  Shouldn't we just return an
          error if we don't have space for desc->in_num.
      
      We keep looping because the size of the total input is allowed to be
      bigger than the 'envelope' which is a subset of the payload that tells
      us how much data to expect. For safety explicitly check that buf_len
      does not overflow which is what the checker flagged.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 62232e45: "libnvdimm: control (ioctl) messages for nvdimm_bus..."
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      58738c49
    • Robin Murphy's avatar
      libnvdimm, nd_blk: remove mmio_flush_range() · 5deb67f7
      Robin Murphy authored
      mmio_flush_range() suffers from a lack of clearly-defined semantics,
      and is somewhat ambiguous to port to other architectures where the
      scope of the writeback implied by "flush" and ordering might matter,
      but MMIO would tend to imply non-cacheable anyway. Per the rationale
      in 67a3e8fe ("nd_blk: change aperture mapping from WC to WB"), the
      only existing use is actually to invalidate clean cache lines for
      ARCH_MEMREMAP_PMEM type mappings *without* writeback. Since the recent
      cleanup of the pmem API, that also now happens to be the exact purpose
      of arch_invalidate_pmem(), which would be a far more well-defined tool
      for the job.
      
      Rather than risk potentially inconsistent implementations of
      mmio_flush_range() for the sake of one callsite, streamline things by
      removing it entirely and instead move the ARCH_MEMREMAP_PMEM related
      definitions up to the libnvdimm level, so they can be shared by NFIT
      as well. This allows NFIT to be enabled for arm64.
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      5deb67f7
    • Vishal Verma's avatar
      libnvdimm, btt: rework error clearing · d9b83c75
      Vishal Verma authored
      Clearing errors or badblocks during a BTT write requires sending an ACPI
      DSM, which means potentially sleeping. Since a BTT IO happens in atomic
      context (preemption disabled, spinlocks may be held), we cannot perform
      error clearing in the course of an IO. Due to this error clearing for
      BTT IOs has hitherto been disabled.
      
      In this patch we move error clearing out of the atomic section, and thus
      re-enable error clearing with BTTs. When we are about to add a block to
      the free list, we check if it was previously marked as an error, and if
      it was, we add it to the freelist, but also set a flag that says error
      clearing will be required. We then drop the lane (ending the atomic
      context), and send a zero buffer so that the error can be cleared. The
      error flag in the free list is protected by the nd 'lane', and is set
      only be a thread while it holds that lane. When the error is cleared,
      the flag is cleared, but while holding a mutex for that freelist index.
      
      When writing, we check for two things -
      1/ If the freelist mutex is held or if the error flag is set. If so,
      this is an error block that is being (or about to be) cleared.
      2/ If the block is a known badblock based on nsio->bb
      
      The second check is required because the BTT map error flag for a map
      entry only gets set when an error LBA is read. If we write to a new
      location that may not have the map error flag set, but still might be in
      the region's badblock list, we can trigger an EIO on the write, which is
      undesirable and completely avoidable.
      
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Cc: Toshi Kani <toshi.kani@hpe.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      d9b83c75
    • Vishal Verma's avatar
      libnvdimm: fix potential deadlock while clearing errors · 0930a750
      Vishal Verma authored
      With the ACPI NFIT 'DSM' methods, acpi can be called from IO paths.
      Specifically, the DSM to clear media errors is called during writes, so
      that we can provide a writes-fix-errors model.
      
      However it is easy to imagine a scenario like:
       -> write through the nvdimm driver
         -> acpi allocation
           -> writeback, causes more IO through the nvdimm driver
             -> deadlock
      
      Fix this by using memalloc_noio_{save,restore}, which sets the GFP_NOIO
      flag for the current scope when issuing commands/IOs that are expected
      to clear errors.
      
      Cc: <linux-acpi@vger.kernel.org>
      Cc: <linux-nvdimm@lists.01.org>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      0930a750
    • Vishal Verma's avatar
      libnvdimm, btt: cache sector_size in arena_info · 75892004
      Vishal Verma authored
      In preparation for the error clearing rework, add sector_size in the
      arena_info struct.
      Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      75892004
    • Vishal Verma's avatar
      libnvdimm, btt: ensure that flags were also unchanged during a map_read · 1398199d
      Vishal Verma authored
      In btt_map_read, we read the map twice to make sure that the map entry
      didn't change after we added it to the read tracking table. In
      anticipation of expanding the use of the error bit, also make sure that
      the error and zero flags are constant across the two map reads.
      Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      1398199d
    • Vishal Verma's avatar
      libnvdimm, btt: refactor map entry operations with macros · 0595d539
      Vishal Verma authored
      Add helpers for converting a raw map entry to just the block number, or
      either of the 'e' or 'z' flags in preparation for actually using the
      error flag to mark blocks with media errors.
      Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      0595d539
    • Vishal Verma's avatar
      libnvdimm, btt: fix a missed NVDIMM_IO_ATOMIC case in the write path · 1db1f3ce
      Vishal Verma authored
      The IO context conversion for rw_bytes missed a case in the BTT write
      path (btt_map_write) which should've been marked as atomic.
      
      In reality this should not cause a problem, because map writes are to
      small for nsio_rw_bytes to attempt error clearing, but it should be
      fixed for posterity.
      
      Add a might_sleep() in the non-atomic section of nsio_rw_bytes so that
      things like the nfit unit tests, which don't actually sleep, can catch
      bugs like this.
      
      Cc: Dan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      1db1f3ce
    • Dan Williams's avatar
      libnvdimm, nfit: export an 'ecc_unit_size' sysfs attribute · a15797f4
      Dan Williams authored
      When the nfit driver initializes it runs an ARS (Address Range Scrub)
      operation across every pmem range. Part of that process involves
      determining the ARS capabilities of a given address range. One of the
      capabilities that is reported is the 'Clear Uncorrectable Error Range
      Length Unit Size' (see: ACPI 6.2 section 9.20.7.4 Function Index 1 -
      Query ARS Capabilities). This property is of interest to userspace
      software as it indicates the boundary at which the NVDIMM may need to
      perform read-modify-write cycles to maintain ECC blocks.
      
      Cc: Vishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      a15797f4
    • Dan Williams's avatar
      ext4: perform dax_device lookup at mount · 5e405595
      Dan Williams authored
      The ->iomap_begin() operation is a hot path, so cache the
      fs_dax_get_by_host() result at mount time to avoid the incurring the
      hash lookup overhead on a per-i/o basis.
      
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Andreas Dilger <adilger.kernel@dilger.ca>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Reported-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      5e405595
    • Dan Williams's avatar
      ext2: perform dax_device lookup at mount · 8cf037a8
      Dan Williams authored
      The ->iomap_begin() operation is a hot path, so cache the
      fs_dax_get_by_host() result at mount time to avoid the incurring the
      hash lookup overhead on a per-i/o basis.
      
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Andreas Dilger <adilger.kernel@dilger.ca>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Reported-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      8cf037a8
    • Dan Williams's avatar
      xfs: perform dax_device lookup at mount · 486aff5e
      Dan Williams authored
      The ->iomap_begin() operation is a hot path, so cache the
      fs_dax_get_by_host() result at mount time to avoid the incurring the
      hash lookup overhead on a per-i/o basis.
      Reported-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      486aff5e
  6. 30 Aug, 2017 3 commits
  7. 20 Aug, 2017 8 commits
    • Linus Torvalds's avatar
      Linux 4.13-rc6 · 14ccee78
      Linus Torvalds authored
      14ccee78
    • Linus Torvalds's avatar
      Sanitize 'move_pages()' permission checks · 197e7e52
      Linus Torvalds authored
      The 'move_paghes()' system call was introduced long long ago with the
      same permission checks as for sending a signal (except using
      CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability).
      
      That turns out to not be a great choice - while the system call really
      only moves physical page allocations around (and you need other
      capabilities to do a lot of it), you can check the return value to map
      out some the virtual address choices and defeat ASLR of a binary that
      still shares your uid.
      
      So change the access checks to the more common 'ptrace_may_access()'
      model instead.
      
      This tightens the access checks for the uid, and also effectively
      changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that
      anybody really _uses_ this legacy system call any more (we hav ebetter
      NUMA placement models these days), so I expect nobody to notice.
      
      Famous last words.
      Reported-by: default avatarOtto Ebeling <otto.ebeling@iki.fi>
      Acked-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      197e7e52
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 7f680d7e
      Linus Torvalds authored
      Pull x86 fixes from Thomas Gleixner:
       "Another pile of small fixes and updates for x86:
      
         - Plug a hole in the SMAP implementation which misses to clear AC on
           NMI entry
      
         - Fix the norandmaps/ADDR_NO_RANDOMIZE logic so the command line
           parameter works correctly again
      
         - Use the proper accessor in the startup64 code for next_early_pgt to
           prevent accessing of invalid addresses and faulting in the early
           boot code.
      
         - Prevent CPU hotplug lock recursion in the MTRR code
      
         - Unbreak CPU0 hotplugging
      
         - Rename overly long CPUID bits which got introduced in this cycle
      
         - Two commits which mark data 'const' and restrict the scope of data
           and functions to file scope by making them 'static'"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86: Constify attribute_group structures
        x86/boot/64/clang: Use fixup_pointer() to access 'next_early_pgt'
        x86/elf: Remove the unnecessary ADDR_NO_RANDOMIZE checks
        x86: Fix norandmaps/ADDR_NO_RANDOMIZE
        x86/mtrr: Prevent CPU hotplug lock recursion
        x86: Mark various structures and functions as 'static'
        x86/cpufeature, kvm/svm: Rename (shorten) the new "virtualized VMSAVE/VMLOAD" CPUID flag
        x86/smpboot: Unbreak CPU0 hotplug
        x86/asm/64: Clear AC on NMI entries
      7f680d7e
    • Linus Torvalds's avatar
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 2615a38f
      Linus Torvalds authored
      Pull timer fixes from Thomas Gleixner:
       "A few small fixes for timer drivers:
      
         - Prevent infinite recursion in the arm architected timer driver with
           ftrace
      
         - Propagate error codes to the caller in case of failure in EM STI
           driver
      
         - Adjust a bogus loop iteration in the arm architected timer driver
      
         - Add a missing Kconfig dependency to the pistachio clocksource to
           prevent build failures
      
         - Correctly check for IS_ERR() instead of NULL in the shared timer-of
           code"
      
      * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        clocksource/drivers/arm_arch_timer: Avoid infinite recursion when ftrace is enabled
        clocksource/drivers/Kconfig: Fix CLKSRC_PISTACHIO dependencies
        clocksource/drivers/timer-of: Checking for IS_ERR() instead of NULL
        clocksource/drivers/em_sti: Fix error return codes in em_sti_probe()
        clocksource/drivers/arm_arch_timer: Fix mem frame loop initialization
      2615a38f
    • Linus Torvalds's avatar
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · e46db8d2
      Linus Torvalds authored
      Pull perf fixes from Thomas Gleixner:
       "Two fixes for the perf subsystem:
      
         - Fix an inconsistency of RDPMC mm struct tagging across exec() which
           causes RDPMC to fault.
      
         - Correct the timestamp mechanics across IOC_DISABLE/ENABLE which
           causes incorrect timestamps and total time calculations"
      
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf/core: Fix time on IOC_ENABLE
        perf/x86: Fix RDPMC vs. mm_struct tracking
      e46db8d2
    • Linus Torvalds's avatar
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 9dae41a2
      Linus Torvalds authored
      Pull irq fixes from Thomas Gleixner:
       "A pile of smallish changes all over the place:
      
         - Add a missing ISB in the GIC V1 driver
      
         - Remove an ACPI version check in the GIC V3 ITS driver
      
         - Add the missing irq_pm_shutdown function for BRCMSTB-L2 to avoid
           spurious wakeups
      
         - Remove the artifical limitation of ITS instances to the number of
           NUMA nodes which prevents utilizing the ITS hardware correctly
      
         - Prevent a infinite parsing loop in the GIC-V3 ITS/MSI code
      
         - Honour the force affinity argument in the GIC-V3 driver which is
           required to make perf work correctly
      
         - Correctly report allocation failures in GIC-V2/V3 to avoid using
           half allocated and initialized interrupts.
      
         - Fixup checks against nr_cpu_ids in the generic IPI code"
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        genirq/ipi: Fixup checks against nr_cpu_ids
        genirq: Restore trigger settings in irq_modify_status()
        MAINTAINERS: Remove Jason Cooper's irqchip git tree
        irqchip/gic-v3-its-platform-msi: Fix msi-parent parsing loop
        irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES
        irqchip: brcmstb-l2: Define an irq_pm_shutdown function
        irqchip/gic: Ensure we have an ISB between ack and ->handle_irq
        irqchip/gic-v3-its: Remove ACPICA version check for ACPI NUMA
        irqchip/gic-v3: Honor forced affinity setting
        irqchip/gic-v3: Report failures in gic_irq_domain_alloc
        irqchip/gic-v2: Report failures in gic_irq_domain_alloc
        irqchip/atmel-aic: Remove root argument from ->fixup() prototype
        irqchip/atmel-aic: Fix unbalanced refcount in aic_common_rtc_irq_fixup()
        irqchip/atmel-aic: Fix unbalanced of_node_put() in aic_common_irq_fixup()
      9dae41a2
    • Linus Torvalds's avatar
      Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · e18a5ebc
      Linus Torvalds authored
      Pull watchdog fix from Thomas Gleixner:
       "A fix for the hardlockup watchdog to prevent false positives with
        extreme Turbo-Modes which make the perf/NMI watchdog fire faster than
        the hrtimer which is used to verify.
      
        Slightly larger than the minimal fix, which just would increase the
        hrtimer frequency, but comes with extra overhead of more watchdog
        timer interrupts and thread wakeups for all users.
      
        With this change we restrict the overhead to the extreme Turbo-Mode
        systems"
      
      * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        kernel/watchdog: Prevent false positives with turbo modes
      e18a5ebc
    • Alexey Dobriyan's avatar
      genirq/ipi: Fixup checks against nr_cpu_ids · 8fbbe2d7
      Alexey Dobriyan authored
      Valid CPU ids are [0, nr_cpu_ids-1] inclusive.
      
      Fixes: 3b8e29a8 ("genirq: Implement ipi_send_mask/single()")
      Fixes: f9bce791 ("genirq: Add a new function to get IPI reverse mapping")
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20170819095751.GB27864@avx2
      8fbbe2d7
  8. 18 Aug, 2017 12 commits
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · 58d4e450
      Linus Torvalds authored
      Merge misc fixes from Andrew Morton:
       "14 fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        mm: revert x86_64 and arm64 ELF_ET_DYN_BASE base changes
        mm/vmalloc.c: don't unconditonally use __GFP_HIGHMEM
        mm/mempolicy: fix use after free when calling get_mempolicy
        mm/cma_debug.c: fix stack corruption due to sprintf usage
        signal: don't remove SIGNAL_UNKILLABLE for traced tasks.
        mm, oom: fix potential data corruption when oom_reaper races with writer
        mm: fix double mmap_sem unlock on MMF_UNSTABLE enforced SIGBUS
        slub: fix per memcg cache leak on css offline
        mm: discard memblock data later
        test_kmod: fix description for -s -and -c parameters
        kmod: fix wait on recursive loop
        wait: add wait_event_killable_timeout()
        kernel/watchdog: fix Kconfig constraints for perf hardlockup watchdog
        mm: memcontrol: fix NULL pointer crash in test_clear_page_writeback()
      58d4e450
    • Kees Cook's avatar
      mm: revert x86_64 and arm64 ELF_ET_DYN_BASE base changes · c715b72c
      Kees Cook authored
      Moving the x86_64 and arm64 PIE base from 0x555555554000 to 0x000100000000
      broke AddressSanitizer.  This is a partial revert of:
      
        eab09532 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
        02445990 ("arm64: move ELF_ET_DYN_BASE to 4GB / 4MB")
      
      The AddressSanitizer tool has hard-coded expectations about where
      executable mappings are loaded.
      
      The motivation for changing the PIE base in the above commits was to
      avoid the Stack-Clash CVEs that allowed executable mappings to get too
      close to heap and stack.  This was mainly a problem on 32-bit, but the
      64-bit bases were moved too, in an effort to proactively protect those
      systems (proofs of concept do exist that show 64-bit collisions, but
      other recent changes to fix stack accounting and setuid behaviors will
      minimize the impact).
      
      The new 32-bit PIE base is fine for ASan (since it matches the ET_EXEC
      base), so only the 64-bit PIE base needs to be reverted to let x86 and
      arm64 ASan binaries run again.  Future changes to the 64-bit PIE base on
      these architectures can be made optional once a more dynamic method for
      dealing with AddressSanitizer is found.  (e.g.  always loading PIE into
      the mmap region for marked binaries.)
      
      Link: http://lkml.kernel.org/r/20170807201542.GA21271@beast
      Fixes: eab09532 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
      Fixes: 02445990 ("arm64: move ELF_ET_DYN_BASE to 4GB / 4MB")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reported-by: default avatarKostya Serebryany <kcc@google.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c715b72c
    • Laura Abbott's avatar
      mm/vmalloc.c: don't unconditonally use __GFP_HIGHMEM · 704b862f
      Laura Abbott authored
      Commit 19809c2d ("mm, vmalloc: use __GFP_HIGHMEM implicitly") added
      use of __GFP_HIGHMEM for allocations.  vmalloc_32 may use
      GFP_DMA/GFP_DMA32 which does not play nice with __GFP_HIGHMEM and will
      trigger a BUG in gfp_zone.
      
      Only add __GFP_HIGHMEM if we aren't using GFP_DMA/GFP_DMA32.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1482249
      Link: http://lkml.kernel.org/r/20170816220705.31374-1-labbott@redhat.com
      Fixes: 19809c2d ("mm, vmalloc: use __GFP_HIGHMEM implicitly")
      Signed-off-by: default avatarLaura Abbott <labbott@redhat.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      704b862f
    • zhong jiang's avatar
      mm/mempolicy: fix use after free when calling get_mempolicy · 73223e4e
      zhong jiang authored
      I hit a use after free issue when executing trinity and repoduced it
      with KASAN enabled.  The related call trace is as follows.
      
        BUG: KASan: use after free in SyS_get_mempolicy+0x3c8/0x960 at addr ffff8801f582d766
        Read of size 2 by task syz-executor1/798
      
        INFO: Allocated in mpol_new.part.2+0x74/0x160 age=3 cpu=1 pid=799
           __slab_alloc+0x768/0x970
           kmem_cache_alloc+0x2e7/0x450
           mpol_new.part.2+0x74/0x160
           mpol_new+0x66/0x80
           SyS_mbind+0x267/0x9f0
           system_call_fastpath+0x16/0x1b
        INFO: Freed in __mpol_put+0x2b/0x40 age=4 cpu=1 pid=799
           __slab_free+0x495/0x8e0
           kmem_cache_free+0x2f3/0x4c0
           __mpol_put+0x2b/0x40
           SyS_mbind+0x383/0x9f0
           system_call_fastpath+0x16/0x1b
        INFO: Slab 0xffffea0009cb8dc0 objects=23 used=8 fp=0xffff8801f582de40 flags=0x200000000004080
        INFO: Object 0xffff8801f582d760 @offset=5984 fp=0xffff8801f582d600
      
        Bytes b4 ffff8801f582d750: ae 01 ff ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a  ........ZZZZZZZZ
        Object ffff8801f582d760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
        Object ffff8801f582d770: 6b 6b 6b 6b 6b 6b 6b a5                          kkkkkkk.
        Redzone ffff8801f582d778: bb bb bb bb bb bb bb bb                          ........
        Padding ffff8801f582d8b8: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ
        Memory state around the buggy address:
        ffff8801f582d600: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffff8801f582d680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        >ffff8801f582d700: fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb fc
      
      !shared memory policy is not protected against parallel removal by other
      thread which is normally protected by the mmap_sem.  do_get_mempolicy,
      however, drops the lock midway while we can still access it later.
      
      Early premature up_read is a historical artifact from times when
      put_user was called in this path see https://lwn.net/Articles/124754/
      but that is gone since 8bccd85f ("[PATCH] Implement sys_* do_*
      layering in the memory policy layer.").  but when we have the the
      current mempolicy ref count model.  The issue was introduced
      accordingly.
      
      Fix the issue by removing the premature release.
      
      Link: http://lkml.kernel.org/r/1502950924-27521-1-git-send-email-zhongjiang@huawei.comSigned-off-by: default avatarzhong jiang <zhongjiang@huawei.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: <stable@vger.kernel.org>	[2.6+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      73223e4e
    • Prakash Gupta's avatar
      mm/cma_debug.c: fix stack corruption due to sprintf usage · da094e42
      Prakash Gupta authored
      name[] in cma_debugfs_add_one() can only accommodate 16 chars including
      NULL to store sprintf output.  It's common for cma device name to be
      larger than 15 chars.  This can cause stack corrpution.  If the gcc
      stack protector is turned on, this can cause a panic due to stack
      corruption.
      
      Below is one example trace:
      
        Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
        ffffff8e69a75730
        Call trace:
           dump_backtrace+0x0/0x2c4
           show_stack+0x20/0x28
           dump_stack+0xb8/0xf4
           panic+0x154/0x2b0
           print_tainted+0x0/0xc0
           cma_debugfs_init+0x274/0x290
           do_one_initcall+0x5c/0x168
           kernel_init_freeable+0x1c8/0x280
      
      Fix the short sprintf buffer in cma_debugfs_add_one() by using
      scnprintf() instead of sprintf().
      
      Link: http://lkml.kernel.org/r/1502446217-21840-1-git-send-email-guptap@codeaurora.org
      Fixes: f318dd08 ("cma: Store a name in the cma structure")
      Signed-off-by: default avatarPrakash Gupta <guptap@codeaurora.org>
      Acked-by: default avatarLaura Abbott <labbott@redhat.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      da094e42
    • Jamie Iles's avatar
      signal: don't remove SIGNAL_UNKILLABLE for traced tasks. · eb61b591
      Jamie Iles authored
      When forcing a signal, SIGNAL_UNKILLABLE is removed to prevent recursive
      faults, but this is undesirable when tracing.  For example, debugging an
      init process (whether global or namespace), hitting a breakpoint and
      SIGTRAP will force SIGTRAP and then remove SIGNAL_UNKILLABLE.
      Everything continues fine, but then once debugging has finished, the
      init process is left killable which is unlikely what the user expects,
      resulting in either an accidentally killed init or an init that stops
      reaping zombies.
      
      Link: http://lkml.kernel.org/r/20170815112806.10728-1-jamie.iles@oracle.comSigned-off-by: default avatarJamie Iles <jamie.iles@oracle.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      eb61b591
    • Michal Hocko's avatar
      mm, oom: fix potential data corruption when oom_reaper races with writer · 6b31d595
      Michal Hocko authored
      Wenwei Tao has noticed that our current assumption that the oom victim
      is dying and never doing any visible changes after it dies, and so the
      oom_reaper can tear it down, is not entirely true.
      
      __task_will_free_mem consider a task dying when SIGNAL_GROUP_EXIT is set
      but do_group_exit sends SIGKILL to all threads _after_ the flag is set.
      So there is a race window when some threads won't have
      fatal_signal_pending while the oom_reaper could start unmapping the
      address space.  Moreover some paths might not check for fatal signals
      before each PF/g-u-p/copy_from_user.
      
      We already have a protection for oom_reaper vs.  PF races by checking
      MMF_UNSTABLE.  This has been, however, checked only for kernel threads
      (use_mm users) which can outlive the oom victim.  A simple fix would be
      to extend the current check in handle_mm_fault for all tasks but that
      wouldn't be sufficient because the current check assumes that a kernel
      thread would bail out after EFAULT from get_user*/copy_from_user and
      never re-read the same address which would succeed because the PF path
      has established page tables already.  This seems to be the case for the
      only existing use_mm user currently (virtio driver) but it is rather
      fragile in general.
      
      This is even more fragile in general for more complex paths such as
      generic_perform_write which can re-read the same address more times
      (e.g.  iov_iter_copy_from_user_atomic to fail and then
      iov_iter_fault_in_readable on retry).
      
      Therefore we have to implement MMF_UNSTABLE protection in a robust way
      and never make a potentially corrupted content visible.  That requires
      to hook deeper into the PF path and check for the flag _every time_
      before a pte for anonymous memory is established (that means all
      !VM_SHARED mappings).
      
      The corruption can be triggered artificially
      (http://lkml.kernel.org/r/201708040646.v746kkhC024636@www262.sakura.ne.jp)
      but there doesn't seem to be any real life bug report.  The race window
      should be quite tight to trigger most of the time.
      
      Link: http://lkml.kernel.org/r/20170807113839.16695-3-mhocko@kernel.org
      Fixes: aac45363 ("mm, oom: introduce oom reaper")
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reported-by: default avatarWenwei Tao <wenwei.tww@alibaba-inc.com>
      Tested-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
      Cc: Andrea Argangeli <andrea@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6b31d595
    • Michal Hocko's avatar
      mm: fix double mmap_sem unlock on MMF_UNSTABLE enforced SIGBUS · 5b53a6ea
      Michal Hocko authored
      Tetsuo Handa has noticed that MMF_UNSTABLE SIGBUS path in
      handle_mm_fault causes a lockdep splat
      
        Out of memory: Kill process 1056 (a.out) score 603 or sacrifice child
        Killed process 1056 (a.out) total-vm:4268108kB, anon-rss:2246048kB, file-rss:0kB, shmem-rss:0kB
        a.out (1169) used greatest stack depth: 11664 bytes left
        DEBUG_LOCKS_WARN_ON(depth <= 0)
        ------------[ cut here ]------------
        WARNING: CPU: 6 PID: 1339 at kernel/locking/lockdep.c:3617 lock_release+0x172/0x1e0
        CPU: 6 PID: 1339 Comm: a.out Not tainted 4.13.0-rc3-next-20170803+ #142
        Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
        RIP: 0010:lock_release+0x172/0x1e0
        Call Trace:
           up_read+0x1a/0x40
           __do_page_fault+0x28e/0x4c0
           do_page_fault+0x30/0x80
           page_fault+0x28/0x30
      
      The reason is that the page fault path might have dropped the mmap_sem
      and returned with VM_FAULT_RETRY.  MMF_UNSTABLE check however rewrites
      the error path to VM_FAULT_SIGBUS and we always expect mmap_sem taken in
      that path.  Fix this by taking mmap_sem when VM_FAULT_RETRY is held in
      the MMF_UNSTABLE path.
      
      We cannot simply add VM_FAULT_SIGBUS to the existing error code because
      all arch specific page fault handlers and g-u-p would have to learn a
      new error code combination.
      
      Link: http://lkml.kernel.org/r/20170807113839.16695-2-mhocko@kernel.org
      Fixes: 3f70dc38 ("mm: make sure that kthreads will not refault oom reaped memory")
      Reported-by: default avatarTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Andrea Argangeli <andrea@kernel.org>
      Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Wenwei Tao <wenwei.tww@alibaba-inc.com>
      Cc: <stable@vger.kernel.org>	[4.9+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5b53a6ea
    • Vladimir Davydov's avatar
      slub: fix per memcg cache leak on css offline · f6ba4880
      Vladimir Davydov authored
      To avoid a possible deadlock, sysfs_slab_remove() schedules an
      asynchronous work to delete sysfs entries corresponding to the kmem
      cache.  To ensure the cache isn't freed before the work function is
      called, it takes a reference to the cache kobject.  The reference is
      supposed to be released by the work function.
      
      However, the work function (sysfs_slab_remove_workfn()) does nothing in
      case the cache sysfs entry has already been deleted, leaking the kobject
      and the corresponding cache.
      
      This may happen on a per memcg cache destruction, because sysfs entries
      of a per memcg cache are deleted on memcg offline if the cache is empty
      (see __kmemcg_cache_deactivate()).
      
      The kmemleak report looks like this:
      
        unreferenced object 0xffff9f798a79f540 (size 32):
          comm "kworker/1:4", pid 15416, jiffies 4307432429 (age 28687.554s)
          hex dump (first 32 bytes):
            6b 6d 61 6c 6c 6f 63 2d 31 36 28 31 35 39 39 3a  kmalloc-16(1599:
            6e 65 77 72 6f 6f 74 29 00 23 6b c0 ff ff ff ff  newroot).#k.....
          backtrace:
             kmemleak_alloc+0x4a/0xa0
             __kmalloc_track_caller+0x148/0x2c0
             kvasprintf+0x66/0xd0
             kasprintf+0x49/0x70
             memcg_create_kmem_cache+0xe6/0x160
             memcg_kmem_cache_create_func+0x20/0x110
             process_one_work+0x205/0x5d0
             worker_thread+0x4e/0x3a0
             kthread+0x109/0x140
             ret_from_fork+0x2a/0x40
        unreferenced object 0xffff9f79b6136840 (size 416):
          comm "kworker/1:4", pid 15416, jiffies 4307432429 (age 28687.573s)
          hex dump (first 32 bytes):
            40 fb 80 c2 3e 33 00 00 00 00 00 40 00 00 00 00  @...>3.....@....
            00 00 00 00 00 00 00 00 10 00 00 00 10 00 00 00  ................
          backtrace:
             kmemleak_alloc+0x4a/0xa0
             kmem_cache_alloc+0x128/0x280
             create_cache+0x3b/0x1e0
             memcg_create_kmem_cache+0x118/0x160
             memcg_kmem_cache_create_func+0x20/0x110
             process_one_work+0x205/0x5d0
             worker_thread+0x4e/0x3a0
             kthread+0x109/0x140
             ret_from_fork+0x2a/0x40
      
      Fix the leak by adding the missing call to kobject_put() to
      sysfs_slab_remove_workfn().
      
      Link: http://lkml.kernel.org/r/20170812181134.25027-1-vdavydov.dev@gmail.com
      Fixes: 3b7b3140 ("slub: make sysfs file removal asynchronous")
      Signed-off-by: default avatarVladimir Davydov <vdavydov.dev@gmail.com>
      Reported-by: default avatarAndrei Vagin <avagin@gmail.com>
      Tested-by: default avatarAndrei Vagin <avagin@gmail.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: <stable@vger.kernel.org>	[4.12.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f6ba4880
    • Pavel Tatashin's avatar
      mm: discard memblock data later · 3010f876
      Pavel Tatashin authored
      There is existing use after free bug when deferred struct pages are
      enabled:
      
      The memblock_add() allocates memory for the memory array if more than
      128 entries are needed.  See comment in e820__memblock_setup():
      
        * The bootstrap memblock region count maximum is 128 entries
        * (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
        * than that - so allow memblock resizing.
      
      This memblock memory is freed here:
              free_low_memory_core_early()
      
      We access the freed memblock.memory later in boot when deferred pages
      are initialized in this path:
      
              deferred_init_memmap()
                      for_each_mem_pfn_range()
                        __next_mem_pfn_range()
                          type = &memblock.memory;
      
      One possible explanation for why this use-after-free hasn't been hit
      before is that the limit of INIT_MEMBLOCK_REGIONS has never been
      exceeded at least on systems where deferred struct pages were enabled.
      
      Tested by reducing INIT_MEMBLOCK_REGIONS down to 4 from the current 128,
      and verifying in qemu that this code is getting excuted and that the
      freed pages are sane.
      
      Link: http://lkml.kernel.org/r/1502485554-318703-2-git-send-email-pasha.tatashin@oracle.com
      Fixes: 7e18adb4 ("mm: meminit: initialise remaining struct pages in parallel with kswapd")
      Signed-off-by: default avatarPavel Tatashin <pasha.tatashin@oracle.com>
      Reviewed-by: default avatarSteven Sistare <steven.sistare@oracle.com>
      Reviewed-by: default avatarDaniel Jordan <daniel.m.jordan@oracle.com>
      Reviewed-by: default avatarBob Picco <bob.picco@oracle.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3010f876
    • Luis R. Rodriguez's avatar
      test_kmod: fix description for -s -and -c parameters · 768dc4e4
      Luis R. Rodriguez authored
      The descriptions were reversed, correct this.
      
      Link: http://lkml.kernel.org/r/20170809234635.13443-4-mcgrof@kernel.org
      Fixes: 64b67120 ("test_sysctl: add generic script to expand on tests")
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Reported-by: default avatarDaniel Mentz <danielmentz@google.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: David Binderman <dcb314@hotmail.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jessica Yu <jeyu@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Matt Redfearn <matt.redfearn@imgetc.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Shuah Khan <shuah@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      768dc4e4
    • Luis R. Rodriguez's avatar
      kmod: fix wait on recursive loop · 2ba293c9
      Luis R. Rodriguez authored
      Recursive loops with module loading were previously handled in kmod by
      restricting the number of modprobe calls to 50 and if that limit was
      breached request_module() would return an error and a user would see the
      following on their kernel dmesg:
      
        request_module: runaway loop modprobe binfmt-464c
        Starting init:/sbin/init exists but couldn't execute it (error -8)
      
      This issue could happen for instance when a 64-bit kernel boots a 32-bit
      userspace on some architectures and has no 32-bit binary format
      hanlders.  This is visible, for instance, when a CONFIG_MODULES enabled
      64-bit MIPS kernel boots a into o32 root filesystem and the binfmt
      handler for o32 binaries is not built-in.
      
      After commit 6d7964a7 ("kmod: throttle kmod thread limit") we now
      don't have any visible signs of an error and the kernel just waits for
      the loop to end somehow.
      
      Although this *particular* recursive loop could also be addressed by
      doing a sanity check on search_binary_handler() and disallowing a
      modular binfmt to be required for modprobe, a generic solution for any
      recursive kernel kmod issues is still needed.
      
      This should catch these loops.  We can investigate each loop and address
      each one separately as they come in, this however puts a stop gap for
      them as before.
      
      Link: http://lkml.kernel.org/r/20170809234635.13443-3-mcgrof@kernel.org
      Fixes: 6d7964a7 ("kmod: throttle kmod thread limit")
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Reported-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Tested-by: default avatarMatt Redfearn <matt.redfearn@imgetc.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Daniel Mentz <danielmentz@google.com>
      Cc: David Binderman <dcb314@hotmail.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jessica Yu <jeyu@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Shuah Khan <shuah@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2ba293c9